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