Re: [gentoo-dev] State of Developement

[George Shapovalov]

Hi guys.

I'll answer this message, as I think this will cover some questions by Evan as 
well.

> > Well, you get the idea. Unfortunately this
> > is our imperfect word where everything tends to break and
> ack. nevertheless i'd like to add that gentoo is particularly and
> 1) gentoo uses performance optimizations by default (which
> 2) gentoo users usually further tweak their systems (aggressive
> 3) while better performance is desirable one must be aware (i
> think most gentooers are) that things tend to be less stable,
> less predictable the more aggressive and uncommon the
> performance optimizations are.
Well, this is what freedom is about. We cannot do much about this short of 
locking users to certain precompiled binaries, as debian does. You should 
think of gentoo more in terms of a meta-distribution with the ability to set 
or screw things next to only Linux From Scratch. Some breakage by the more 
advantrous types is inevitable, while on the other hand I saw reports by 
people running gentoo on servers without any problems (and of course they do 
not run the daily cron job of "emerge rsync &&emerge -u world" :) ).

> gentoo also uses the latest app releases which are less
> thouroughly tested by nature and consequences not entirely clear
> from the beginning (introduction of non-backwards-compatible
> changes, e.g. libvorbis).
Good point. Eventually this will be remedied by the stable profile which will 
lock packages to the approved stable versions for the most part. Please do 
not confuse with branches: there is no point in branching gentoo. It is far 
better to have a big general database and subset it (via profiles or KEYWORDS 
of what we have at present) on order to get the system tailored for the 
certain task. 
However bear in mind, that gentoo is a young distribution (guess why we are 
1.4 now and not say 7.5?). We are in early stages of implementing all these 
features.


> the same goes for greater flexibility which is fine but makes
> *any* testing approach pretty tough to unmanageable (see
> combinatorics ;). in real world, there will always be a
> trade-off between performance optimizations, flexibility and
> stability.
This is why we really depend on you - our users. We perform significant amount 
of testing before new packages or versions are incorporated into the tree 
(and this is a part of the reason new submissions take long time to be 
processed). However it is not possible to cover all possible combinations of 
architectures, package and compiler versions and combinations. More important 
packages get tested more, less important..., well, this is what this 
multistability user-driven ebuild processing concept is about: to let 
interested users help us and themselves simultaneously.


> > 3.Feedback system that collects user voices and moves ebuilds
> > to corresponding categories increasing or decreasing their
> > stability rating.
> ack. the barrier for giving feedback should be as low as possible
> and feedback should be given instantly. i.e. emerge should give
> the user an option to send a standardized bug-report by more or
> less just hitting enter when an ebuild fails (i think this has
> been discussed several times on this list already).
If you have some tight concept or a good idea, please contribute it. Answering 
to this thread or posting a comment to that bug I mentioned (and there are 
some more) are the ways to get your word to developers.
(This is a general remark, I see you do just that below. Thanks for that!)

> rule: you can always trash submitted, bad (useless) bug-reports
> but you can't get bug-reports that were not submitted.
> standardizing bug-reports should also help in improving their
> quality.
True. Also it should be kept in mind that the feedback system should be 
largely automatic and well balanced (so that popularity of the package does 
not influence its stability ratings too much for example).


> disclaimer: i do not know how gentoo-core is really organized (i
> do not think anybody outside of gentoo-core does). i think some
> more information about gentoo's internal organization, tasks,
> release schedules and targets for non-gentoo-core people would
> be very much appreciated and would enhance confidence,
> predictability and thus the coordination of own activities.
> gentoo-core still looks like some kind of a blackbox to me as
> what regards these points. is this really intended?
Good point. 
The intent is to have some place for "wild" discussions, which might 
potentially and unnecessarily upset users: "gentoo devs want to do this evil 
thing!" while it was merely a trial suggestion that was shot down quickly 
afterwards. Core devs are encouraged to take questions that require user 
feedback or general discussion to the gentoo-dev.


> > Please take a look at bug#1523 for much more details (though
> > bear in mind that some of that stuff is outdated by now).
>
> i've only skimed your proposal but it looks fine to me. is there
> any reason why gentoo-core has not approved it yet?
Well, its not that it has not been approved, its more the issue of difference 
between accepting some idea and implementing it :).
It does take quite some work and time to do things, especially that touch the 
core of the system and require updates to majority or all the ebuilds. We 
just recently had a large session of KEYWORD additions. This required all 
developers to retest and modify their ebuilds (or all the ebuilds they 
oversee). This is not over yet, but nearing completion, thus taking care of 
the larger part of step 1 (as in my previous message). Other parts of that 
proposal will have to be settled and implemented as well. Particularly a good 
discussion on the feedback/voting system may help to settle at least the 
design.

And thanks for the thoughts!

George