1 |
I think that with recent advancements in batch-stabilization we're able |
2 |
to process a much higher amount of stabilization bugs, and keep the bug |
3 |
queue low. It used to be longer than 100 bugs, but now it's closer to |
4 |
20-30 bugs for which regressions or other problems have been detected. |
5 |
|
6 |
This allows us to do better testing of the stabilization candidates, but |
7 |
also I think we should start bringing even more updates to the stable tree. |
8 |
|
9 |
When doing stable testing I frequently notice bugs fixed in ~arch but |
10 |
not stabilized, so stable is frequently affected by problems that could |
11 |
be easily fixed by stabilizing a more recent version. |
12 |
|
13 |
I wrote a script, |
14 |
<http://git.overlays.gentoo.org/gitweb/?p=proj/arch-tools.git;a=blob;f=stabilization-candidates.py;hb=HEAD>, |
15 |
that scans the tree for packages that could be easily stabilized (all |
16 |
deps stable, no bugs). |
17 |
|
18 |
I'm attaching a list of packages that are sitting in the tree for at |
19 |
least 6 months (180 days, way more than 30 days required for |
20 |
stabilization) and should be ready for stabilization. |
21 |
|
22 |
Please review the list, it's 800+ packages so I thought about asking for |
23 |
feedback before filing stabilization bugs (I plan to do that in stages |
24 |
of course). |
25 |
|
26 |
Paweł |