Re: [gentoo-dev] Proposal for how to handle stable ebuilds

[Matti Bickel <mabi@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 1977 bytes --]

Tobias Scherbaum <dertobi123@gentoo.org> wrote:
> Mark Loeser wrote:
> > Removing Stable Ebuilds
> > 
> > If an ebuild meets the time criteria above, and there are no technical issues
> > preventing stabilization, then the maintainer MAY choose to delete an older
> > version even if it is the most recent stable version for a particular arch.
> 
> What if this would break deps or it's a very common package for example
> belonging to the set of system packages?

Then the maintainer moans and does nothing. I guess that's where the
"MAY" part from above comes in. Policy should not be an excuse to stop
thinking. And if i break a user system when i drop my stable keywords,
IMHO i'm violating the 'work as pleasently and efficiently as possible'
bit of our philosophy.

It isn't that we have arch teams denying ebuilds their blessing because
they're evil. Maybe they're overworked, maybe they even have a real
life. Or maybe they have stated that your ebuild has QA issues (as
Ferris did), which should be noted and fixed by the maintainer.

So bottom-line: i'm very much in favour of your solution to question #1.
And i'd like to stress the "automatic" bit. Yes, we can get access to
tinderboxes. But last i looked, this involved tracking down the person
responsible for it, asking for access and doing everything you need to
get your package to compile. Well, i'm lazy, so i didn't do it.

Automatic tinderbox testing would very much help in the process. Maybe
someone can write a script so that once a maintainer opens/gives his OK
to a stable bug, automatic testing could be started and the results
posted back to the bug?

After the timeframe (30 days? 60? I don't know, and it's not important
at this point) maintainers could move to stable their package themself
IF the automatic tests indicate success AND no arch member has spoken
up.

just my $0.02
-- 
Regards, Matti Bickel
Signed/Encrypted email preferred (key 4849EC6C)

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]