> 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. :)