Re: [gentoo-dev] State of Developement

[Daniel Mettler <mettlerd@icu.unizh.ch>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

george (et al.),

On Tuesday 27 August 2002 00:24, George Shapovalov wrote:
> original authors of the packages. It would be a life in heaven
> if everything installed via "./configure && make && make
> install". All packages would compile on any arch and glibc/gcc
> version and no weir dependencies were lost in docs and nothing
> would conflict...

ack.

> 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 
implicitly vulnerable to such issues as some troubles are 
"home-made by concept".

1) gentoo uses performance optimizations by default (which 
sometimes lead to non-deterministic, non-reproducible results 
which are particularly hard to track down and solve, e.g. 
parallel make)

2) gentoo users usually further tweak their systems (aggressive 
gcc flags, ...)

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.

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).

now i do not say that this is bad practice or a conceptually 
wrong, i just say that this implicitly means that gentoo is a 
"bleeding edge" distro and that this is gentoo's (and its 
community's) own decision (thus no self-pity, please ;)

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.

> changes were implemented in this new revision? Things will get
> better when we release 1.4, however I am afraid not by much.

well, it's some bad luck currently with these horrible gcc 2.95.3 
- -> gcc 3.1 -> gcc 3.2 changes. as the gcc devs have declared to 
take better care of backwards compatibility in the future, i 
hope things will stabilize.

> The point I am getting at here is that we should and can allow
> our users to take care of a large portion of non-crytical
> packages. What we need is: 1. Multiple stability levels or
> KEYWORDS

ack.

> 2. Streamlined ebuild processing - that automates submission
> of new ebuilds/versions and assigns them some kind of "new" or
> "user-test" keyword/level

ack.

> 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).

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.

> 4. Core group oversees and takes care of the
> core/crytical stuff and has *much* more time to work
> onportage/sysinit/other_more_distro_specifc_stuff Well, that
> would be one possible point of view on this :).

addendum regarding qa: perhaps a more process-oriented 
organization would help improving qa and take some pressure from 
core-devs? has this ever been evaluated? how is qa organized 
atm?

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?

> 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?

summa summarum:

1.) gentoo as a distro has its own strengths and weaknesses
2.) organization is a very important thing when managing software 
projects
3.) information flow from gentoo-core to gentoo-dev/-user and 
vice-versa is important

regards

dan

- -- 
      ...::: Daniel Mettler | http://www.numlock.ch :::....

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9as5ASLYjgrGjnWQRAsroAJ40C3TJCCZmVKy0zaYFD37jrA1kHACeJu1l
A9+Z8QG4R/T2Ywg1nPguzis=
=eC5U
-----END PGP SIGNATURE-----