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

[Chris Bainbridge]

On 27/07/06, Stefan Schweizer <genstef@g.o> wrote:
>
> The problem is in the system. Unless you are a developer _and_ part of the
> arch team you cannot do anything but file a bug and wait and wait and wait
> until a member of the arch team decides to test the package again for his
> own and mark it stable.
>
> So with the current system the arch teams cannot cover all the packages. I
> would say for your litle pet package to get stable you have little chances.
> And you would not want it stable anyway, because stable marking usually
> lacks behind the bugs of the package. That means you most certainly will
> hit the bugs and a month later when someone has filed a bug _and_ the
> package herd or developer has said yes _and_ a developer from the arch team
> has tested it the bug will be stable, too.
>
> As a better system I would like to see packages stable automatically after
> 30 days and no bugs. But this is probably not going to happen with gentoo
> so I just stay away from stable and put ACCEPT_KEYWORDS in my make.conf

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:

1) thousands of packages will never be marked stable

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

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.

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.

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?

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...).
-- 
gentoo-dev@g.o mailing list