On Fri, Nov 25, 2011 at 05:39:32PM +0100, Thomas Kahle wrote:
On 09:41 Mon 21 Nov 2011, Paweł Hajdan, Jr. wrote:
I think that with recent advancements in batch-stabilization we're able
to process a much higher amount of stabilization bugs, and keep the bug
queue low. It used to be longer than 100 bugs, but now it's closer to
20-30 bugs for which regressions or other problems have been detected.
I still remember that arfrever had such a script running for python
packages and that we were quite annoyed by the automatic stable bugs for
every minor version of every small python package. For this reason I'm
against running the script constantly. Packages with high release
frequence upstream don't need every of their versions to be stabilized.
Personally, I think they don't even need every of their versions
bumped...
On the other hand, having a big stable frenzy once every few months
seems good for exactly the reasons you name.
Cheers,
Thomas
This allows us to do better testing of the stabilization candidates, but
also I think we should start bringing even more updates to the stable tree.
When doing stable testing I frequently notice bugs fixed in ~arch but
not stabilized, so stable is frequently affected by problems that could
be easily fixed by stabilizing a more recent version.
I wrote a script,
http://git.overlays.gentoo.org/gitweb/?p=proj/arch-tools.git;a=blob;f=stabilization-candidates.py;hb=HEAD,
that scans the tree for packages that could be easily stabilized (all
deps stable, no bugs).
I'm attaching a list of packages that are sitting in the tree for at
least 6 months (180 days, way more than 30 days required for
stabilization) and should be ready for stabilization.
Please review the list, it's 800+ packages so I thought about asking for
feedback before filing stabilization bugs (I plan to do that in stages
of course).
Paweł
The way I understand it, the only things that should be picked up are
those package that have already been in the tree for 180 days. So, it
wouldn't be submitting requests for unmaintained packages constantly
unless somebody is sneaking in bumps. After this first large batch I'd
imagine the requests to taper off quickly.
--
Mr. Aaron W. Swenson
Gentoo Linux Developer
Email: titanof...@gentoo.org
GnuPG FP : 2C00 7719 4F85 FB07 A49C 0E31 5713 AA03 D1BB FDA0
GnuPG ID : D1BBFDA0
pgpOW2bX54LVp.pgp
Description: PGP signature
