Tobias Scherbaum <[EMAIL PROTECTED]> 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)
pgpaOntcepuKy.pgp
Description: PGP signature
