Re: [gentoo-dev] Re: aging ebuilds with unstable keywords - how can we help?

[Chris Gianelloni]

On Thu, 2006-07-27 at 10:00 +0100, Chris Bainbridge wrote:
> I would also like to see that (though maybe with some automated
> feedback from users systems as to which packages are installed / how
> often they are run). All that the current process ensures is that:

Any automated system will cause serious problems for the quality of the
distribution without several orders of magnitude of more powerful
hardware on our side.

> 1) thousands of packages will never be marked stable

Honestly, they shouldn't be stable.  In fact, likely, many shouldn't be
in the tree.  We have way too many packages that are used solely by a
small group of people sitting around the tree.  These would be better
served in official overlays, where they can be maintained by the
interested parties (including users), rather than in the tree.

> 2) Everyone running stable who wants some recent packages ends up with
> /etc/portage/package.keywords with hundreds of entries

People don't seem to understand that you cannot have your cake and eat
it, too.  I have no sympathy for these people.

If you want *stable* then you're going to have to wait until the package
has passed QA and the bugs have been resolved.  If you want *new* then
you simply have to deal with the bugs.

People seem to think that there's some magical solution to this.  There
is no solution other than more people actually *solving* the problems
that keep packages from making it to stable.  The packages that are
complained about the most are invariably large sets of packages, like
GNOME or KDE, that have hundreds of dependencies and take quite some
time to get into a condition that can be considered "stable" at all.

If you want things to make it to stable faster, then start supplying
patches.

> 3) Debugging user bugs when users have a mixed x86/~x86 system is a
> lot more complicated. Every system ends up being a unique combination
> of different packages and versions.

This isn't even an issue.  Every Gentoo system is a unique combination
of packages and versions, USE flags, CFLAGS, etc.

> 4) The user experience sucks  - see the forums/wiki... "to install
> this great sw you need the latest version of x, which depends on y,z,
> so copy paste this huge block in to /etc/portage/package.keywords."...
> then 2 weeks later some depend changes, and suddenly emerge -u world
> no longer works, and user has more problems to solve.

Honestly, the number of people out there giving shit advice is part of
the problem.  Rather than telling people to do this sort of thing, a
better solution would be to tell people how they can *help* instead of
how they can bypass the system, which ends up with clueless users filing
more bugs, which delays the stabilization longer.  Every user that
someone knowledgeable gets to use something they don't understand, is a
potential bug report slowing stabilization even more.

> The testing is supposed to be for the ebuild, not the package itself,
> so there's not much point in holding back packages with simple ebuilds
> from being stabilised. And the testing process isn't that extensive
> anyway - all it ensures is that the package builds and can be run on
> one particular arch testers system. No disrespect to the testers, but
> they can't be experts in every particular piece of software. How much
> code coverage does a typical ebuild really get when being tested?

First off, we have a level of expectation of stability to maintain.  If
all packages were done "right" then 90% of the ~arch packages in the
tree would be under package.mask, rather than ~arch.  Only packages in
~arch would be ones with no bugs open, to test the ebuild, so that they
can become stable.  As we all know, this isn't the case.  Developers all
over the place, including myself, have put in tons of packages that
aren't necessarily perfectly stable themselves.  We do this because our
users demand it.  We have reached a critical mass of users, where no
matter what we do, somebody is going to bitch and piss and moan because
we don't do things the way they would like.  There's nothing that we can
do about this except decide collectively what the best course of action
for our users would be and try to make things as high-quality as
possible.

Automatic stabilization is one of those things that would cause our
quality to go to hell.  Another thing is this.  If you don't like it,
fork.  You've got the code.  You're *more than welcome* to go around
making your own overlay/tree and marking whatever rubbish you feel like
as stable.  There's *nobody* stopping you from doing so.  However, many
of the Gentoo developers feel a stronger sense of duty to the users, and
would prefer not shove a bunch of crap down the pipe onto people's
computers.  There are a few of the developers that are followers of the
"ricer" philosophy, claiming that they don't mind a few bugs here and
there.  Well, the number of bugs in bugzilla shows that our users simply
don't agree.

> I'd say no bugs, 30 days, passes internal tests, being run by users =>
> stablise, for the majority of packages (obviously, there may be some
> exceptions...).

Luckily, you're not making the call.  ;]

The "majority" of packages are also the ones that need more extensive
testing.  Sure, we could probably stabilize a bunch of the fringe
packages that hardly anyone uses and it wouldn't affect anything.
Another problem is that we don't *know* what is being run by our users.
This is something that the Summer of Code project for a Gentoo Stats
project should at least help with, as it will give us an insight into
what is actually being used and what isn't.

Personally, I would love to see Gentoo splinter a bit more.  I would
love to see lots of packages removed from the tree entirely, and moved
out into overlays.  I wouldn't mind seeing the tree completely split
into the "ricer" and "stable" camps.  Let's call them "Gentoo
Enterprise" and "Gentoo X-Treme UberEdition" just to keep them
separate...

Seriously, folks.  If you think that packages should be available
faster, run ~arch.  Test the packages.  Report successes/failures to the
maintainers.  File stabilization bugs if your favorite package hasn't
had another bug in 30 days and you've been using it.  Basically, help
out, rather than sitting back and complaining.  Complaining helps
nobody.  Helping out helps everyone, yourself included.  We understand
that you might not be able to make a commitment, or even want to do so.
However, every single bug report that you file *is* helping out... and
every little bit helps.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux