1 |
Hi guys. |
2 |
|
3 |
I'll answer this message, as I think this will cover some questions by Evan as |
4 |
well. |
5 |
|
6 |
> > Well, you get the idea. Unfortunately this |
7 |
> > is our imperfect word where everything tends to break and |
8 |
> ack. nevertheless i'd like to add that gentoo is particularly and |
9 |
> 1) gentoo uses performance optimizations by default (which |
10 |
> 2) gentoo users usually further tweak their systems (aggressive |
11 |
> 3) while better performance is desirable one must be aware (i |
12 |
> think most gentooers are) that things tend to be less stable, |
13 |
> less predictable the more aggressive and uncommon the |
14 |
> performance optimizations are. |
15 |
Well, this is what freedom is about. We cannot do much about this short of |
16 |
locking users to certain precompiled binaries, as debian does. You should |
17 |
think of gentoo more in terms of a meta-distribution with the ability to set |
18 |
or screw things next to only Linux From Scratch. Some breakage by the more |
19 |
advantrous types is inevitable, while on the other hand I saw reports by |
20 |
people running gentoo on servers without any problems (and of course they do |
21 |
not run the daily cron job of "emerge rsync &&emerge -u world" :) ). |
22 |
|
23 |
> gentoo also uses the latest app releases which are less |
24 |
> thouroughly tested by nature and consequences not entirely clear |
25 |
> from the beginning (introduction of non-backwards-compatible |
26 |
> changes, e.g. libvorbis). |
27 |
Good point. Eventually this will be remedied by the stable profile which will |
28 |
lock packages to the approved stable versions for the most part. Please do |
29 |
not confuse with branches: there is no point in branching gentoo. It is far |
30 |
better to have a big general database and subset it (via profiles or KEYWORDS |
31 |
of what we have at present) on order to get the system tailored for the |
32 |
certain task. |
33 |
However bear in mind, that gentoo is a young distribution (guess why we are |
34 |
1.4 now and not say 7.5?). We are in early stages of implementing all these |
35 |
features. |
36 |
|
37 |
|
38 |
> the same goes for greater flexibility which is fine but makes |
39 |
> *any* testing approach pretty tough to unmanageable (see |
40 |
> combinatorics ;). in real world, there will always be a |
41 |
> trade-off between performance optimizations, flexibility and |
42 |
> stability. |
43 |
This is why we really depend on you - our users. We perform significant amount |
44 |
of testing before new packages or versions are incorporated into the tree |
45 |
(and this is a part of the reason new submissions take long time to be |
46 |
processed). However it is not possible to cover all possible combinations of |
47 |
architectures, package and compiler versions and combinations. More important |
48 |
packages get tested more, less important..., well, this is what this |
49 |
multistability user-driven ebuild processing concept is about: to let |
50 |
interested users help us and themselves simultaneously. |
51 |
|
52 |
|
53 |
> > 3.Feedback system that collects user voices and moves ebuilds |
54 |
> > to corresponding categories increasing or decreasing their |
55 |
> > stability rating. |
56 |
> ack. the barrier for giving feedback should be as low as possible |
57 |
> and feedback should be given instantly. i.e. emerge should give |
58 |
> the user an option to send a standardized bug-report by more or |
59 |
> less just hitting enter when an ebuild fails (i think this has |
60 |
> been discussed several times on this list already). |
61 |
If you have some tight concept or a good idea, please contribute it. Answering |
62 |
to this thread or posting a comment to that bug I mentioned (and there are |
63 |
some more) are the ways to get your word to developers. |
64 |
(This is a general remark, I see you do just that below. Thanks for that!) |
65 |
|
66 |
> rule: you can always trash submitted, bad (useless) bug-reports |
67 |
> but you can't get bug-reports that were not submitted. |
68 |
> standardizing bug-reports should also help in improving their |
69 |
> quality. |
70 |
True. Also it should be kept in mind that the feedback system should be |
71 |
largely automatic and well balanced (so that popularity of the package does |
72 |
not influence its stability ratings too much for example). |
73 |
|
74 |
|
75 |
> disclaimer: i do not know how gentoo-core is really organized (i |
76 |
> do not think anybody outside of gentoo-core does). i think some |
77 |
> more information about gentoo's internal organization, tasks, |
78 |
> release schedules and targets for non-gentoo-core people would |
79 |
> be very much appreciated and would enhance confidence, |
80 |
> predictability and thus the coordination of own activities. |
81 |
> gentoo-core still looks like some kind of a blackbox to me as |
82 |
> what regards these points. is this really intended? |
83 |
Good point. |
84 |
The intent is to have some place for "wild" discussions, which might |
85 |
potentially and unnecessarily upset users: "gentoo devs want to do this evil |
86 |
thing!" while it was merely a trial suggestion that was shot down quickly |
87 |
afterwards. Core devs are encouraged to take questions that require user |
88 |
feedback or general discussion to the gentoo-dev. |
89 |
|
90 |
|
91 |
> > Please take a look at bug#1523 for much more details (though |
92 |
> > bear in mind that some of that stuff is outdated by now). |
93 |
> |
94 |
> i've only skimed your proposal but it looks fine to me. is there |
95 |
> any reason why gentoo-core has not approved it yet? |
96 |
Well, its not that it has not been approved, its more the issue of difference |
97 |
between accepting some idea and implementing it :). |
98 |
It does take quite some work and time to do things, especially that touch the |
99 |
core of the system and require updates to majority or all the ebuilds. We |
100 |
just recently had a large session of KEYWORD additions. This required all |
101 |
developers to retest and modify their ebuilds (or all the ebuilds they |
102 |
oversee). This is not over yet, but nearing completion, thus taking care of |
103 |
the larger part of step 1 (as in my previous message). Other parts of that |
104 |
proposal will have to be settled and implemented as well. Particularly a good |
105 |
discussion on the feedback/voting system may help to settle at least the |
106 |
design. |
107 |
|
108 |
And thanks for the thoughts! |
109 |
|
110 |
George |