1 |
On 11/25/11 5:39 PM, Thomas Kahle wrote: |
2 |
> I still remember that arfrever had such a script running for python |
3 |
> packages and that we were quite annoyed by the automatic stable bugs |
4 |
> for every minor version of every small python package. |
5 |
|
6 |
I also still remember it, and that was one of the things that made me |
7 |
start the batch-stabilization workflow. |
8 |
|
9 |
I don't want to repeat frustration caused by that python script. If |
10 |
anyone's annoyed by my script or wants to opt out, please let me know. |
11 |
|
12 |
> For this reason I'm against running the script constantly. Packages |
13 |
> with high release frequence upstream don't need every of their |
14 |
> versions to be stabilized. |
15 |
|
16 |
If a package has been in the tree for 180 days, I guess we're safe. I'm |
17 |
going to only consider the last ~arch package as stabilization |
18 |
candidate, as requested by various maintainers. |
19 |
|
20 |
> Personally, I think they don't even need every of their versions |
21 |
> bumped... |
22 |
|
23 |
IMHO nothing wrong with it, and it can even be a good thing if given |
24 |
team has manpower to keep up. Of course it's way more important to fix |
25 |
bugs in existing packages than to bump every minor version. |
26 |
|
27 |
> On the other hand, having a big stable frenzy once every few months |
28 |
> seems good for exactly the reasons you name. |
29 |
|
30 |
Good, I think I still need to figure out the best way to run my script. |
31 |
I'm leaning towards a more continuous fashion instead of a huge frenzy |
32 |
from time to time. Each run can be limited (in fact I've limited the |
33 |
last one to just 100 bugs), and in fact for my next run I'm seriously |
34 |
considering filing _less_ bugs. |
35 |
|
36 |
Partially because Agostino (ago) reported lots of problems with existing |
37 |
stabilization candidates, and I think it's worth to fix them before next |
38 |
round of stabilizations. :) |