1 |
On 5/12/12 6:28 PM, Rich Freeman wrote: |
2 |
> On Sat, May 12, 2012 at 6:34 AM, "Paweł Hajdan, Jr." |
3 |
> <phajdan.jr@g.o> wrote: |
4 |
>> The idea is that if you only fix in ~arch, you risk a serious and |
5 |
>> _known_ regression in stable, which could be easily avoided. |
6 |
> |
7 |
> How can you have a regression in stable if stable has the bug already? |
8 |
|
9 |
Let me explain in more detail. Suppose you have package foo, and you fix |
10 |
a compile error with say qt-4.8, but the fix stays in ~arch. Now qt-4.8 |
11 |
is getting stabilized, and if we don't also grab the ~arch foo, stable |
12 |
foo becomes broken. |
13 |
|
14 |
Similar thing applies to e.g. gcc updates. I remember a reminder to use |
15 |
gcc tracker bugs and include precise info which version of a package |
16 |
works with more recent gcc, to make sure ~arch has the fixes when given |
17 |
gcc version goes ~arch, and same for stable. |
18 |
|
19 |
> I see the value when we're talking about security bugs, or very |
20 |
> critical bugs, but for the run-of-the-mill minor issues that are the |
21 |
> majority of bug reports I don't see the value in keeping bugs open for |
22 |
> a month or two just to track that the inevitable hasn't happened yet. |
23 |
|
24 |
Agreed. I'm talking about compile errors or crashes here. I've really |
25 |
seen arches stabilizing packages with known problems, just having closed |
26 |
bugs because "the fix is in ~arch". |
27 |
|
28 |
Paweł |