On Sat, May 12, 2012 at 4:01 PM, "Paweł Hajdan, Jr." <phajdan...@gentoo.org> wrote: > Agreed. I'm talking about compile errors or crashes here. I've really > seen arches stabilizing packages with known problems, just having closed > bugs because "the fix is in ~arch".
We might already be on the same page, but I think the bar to set for stable is that the new build must be overall at least as good as the previous one. Having known issues isn't necessarily a problem as long as overall the level of quality is maintained (all software has bugs - some teams are just better about knowing about them). If foo-3 is stable, and foo-4.1 introduces a bug, and foo-4.2 fixes that bug, then I agree that stablizing foo-4.1 might be a mistake. On the other hand, if foo-3 has 30 bugs, and foo-4.1 has 20 bugs, and foo-4.2 has 25 bugs (just not that one in particular), then it might still make sense to go with 4.1 in the short term. Obviously not all bugs are equal. This is why maintainers in general should be controlling what packages get STABLEREQ'ed, and for important packages it is best to make this decision as a team. Is there really a sense that this is a big problem? I'm sure it happens - but AFAICT the effort required to prevent this might not be worth it except in isolated cases. Rich
