On 11/25/11 5:39 PM, Thomas Kahle wrote: > 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.
I also still remember it, and that was one of the things that made me start the batch-stabilization workflow. I don't want to repeat frustration caused by that python script. If anyone's annoyed by my script or wants to opt out, please let me know. > 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. If a package has been in the tree for 180 days, I guess we're safe. I'm going to only consider the last ~arch package as stabilization candidate, as requested by various maintainers. > Personally, I think they don't even need every of their versions > bumped... IMHO nothing wrong with it, and it can even be a good thing if given team has manpower to keep up. Of course it's way more important to fix bugs in existing packages than to bump every minor version. > On the other hand, having a big stable frenzy once every few months > seems good for exactly the reasons you name. Good, I think I still need to figure out the best way to run my script. I'm leaning towards a more continuous fashion instead of a huge frenzy from time to time. Each run can be limited (in fact I've limited the last one to just 100 bugs), and in fact for my next run I'm seriously considering filing _less_ bugs. Partially because Agostino (ago) reported lots of problems with existing stabilization candidates, and I think it's worth to fix them before next round of stabilizations. :)
signature.asc
Description: OpenPGP digital signature
