[gentoo-dev] pushing fixes to stable before closing bugs

[gentoo-dev] pushing fixes to stable before closing bugs

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 538 bytes --]

I noticed a general tendency to close bugs affecting stable before
pushing the fix to stable.

One recent example is <https://bugs.gentoo.org/show_bug.cgi?id=399291>,
but there are more.

The idea is that if you only fix in ~arch, you risk a serious and
_known_ regression in stable, which could be easily avoided.

Do you have any ideas how do we:

1. Make as many developers (everyone?) as possible aware of this.

2. Handle already closed bugs with no fix in stable? I've seen people
closing the bugs again.

Paweł


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

Re: [gentoo-dev] pushing fixes to stable before closing bugs

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 806 bytes --]

El sáb, 12-05-2012 a las 12:34 +0200, "Paweł Hajdan, Jr." escribió:
> I noticed a general tendency to close bugs affecting stable before
> pushing the fix to stable.
> 
> One recent example is <https://bugs.gentoo.org/show_bug.cgi?id=399291>,
> but there are more.
> 
> The idea is that if you only fix in ~arch, you risk a serious and
> _known_ regression in stable, which could be easily avoided.
> 
> Do you have any ideas how do we:
> 
> 1. Make as many developers (everyone?) as possible aware of this.
> 
> 2. Handle already closed bugs with no fix in stable? I've seen people
> closing the bugs again.
> 
> Paweł
> 

I guess it depends in how major is the fixed bug, if it's not too major,
I think we can wait for next stabilization round (we tend to do it in
gnome team)

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] pushing fixes to stable before closing bugs

[Rich Freeman]

On Sat, May 12, 2012 at 6:34 AM, "Paweł Hajdan, Jr."
<phajdan.jr@gentoo.org> wrote:
> The idea is that if you only fix in ~arch, you risk a serious and
> _known_ regression in stable, which could be easily avoided.

How can you have a regression in stable if stable has the bug already?
 A regression is when you have a stable package with a bug, then you
introduce a new stable package that doesn't have that bug, and then
you introduce yet another new stable package that has the same bug
back again.

While I can see some value in tracking whether bugs have made it to
stable yet, I think we need better tools if we want to do that.
Otherwise it is a big housekeeping mess tracking what is and isn't in
stable yet.

I see the value when we're talking about security bugs, or very
critical bugs, but for the run-of-the-mill minor issues that are the
majority of bug reports I don't see the value in keeping bugs open for
a month or two just to track that the inevitable hasn't happened yet.

Rich

Re: [gentoo-dev] pushing fixes to stable before closing bugs

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 1335 bytes --]

On 5/12/12 6:28 PM, Rich Freeman wrote:
> On Sat, May 12, 2012 at 6:34 AM, "Paweł Hajdan, Jr."
> <phajdan.jr@gentoo.org> wrote:
>> The idea is that if you only fix in ~arch, you risk a serious and
>> _known_ regression in stable, which could be easily avoided.
> 
> How can you have a regression in stable if stable has the bug already?

Let me explain in more detail. Suppose you have package foo, and you fix
a compile error with say qt-4.8, but the fix stays in ~arch. Now qt-4.8
is getting stabilized, and if we don't also grab the ~arch foo, stable
foo becomes broken.

Similar thing applies to e.g. gcc updates. I remember a reminder to use
gcc tracker bugs and include precise info which version of a package
works with more recent gcc, to make sure ~arch has the fixes when given
gcc version goes ~arch, and same for stable.

> I see the value when we're talking about security bugs, or very
> critical bugs, but for the run-of-the-mill minor issues that are the
> majority of bug reports I don't see the value in keeping bugs open for
> a month or two just to track that the inevitable hasn't happened yet.

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".

Paweł


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

Re: [gentoo-dev] pushing fixes to stable before closing bugs

[Rich Freeman]

On Sat, May 12, 2012 at 4:01 PM, "Paweł Hajdan, Jr."
<phajdan.jr@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

Re: [gentoo-dev] pushing fixes to stable before closing bugs

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 614 bytes --]

> I noticed a general tendency to close bugs affecting stable before
> pushing the fix to stable.
> 
> One recent example is <https://bugs.gentoo.org/show_bug.cgi?id=399291>,
> but there are more.

Not about the general question, but about this specific bug... I never really 
expected the Calligra release to take so long. KOffice is basically dead code, 
and will be removed as soon as Calligra goes stable (and I intend to file the 
stablerequest tomorrow). 

-- 
Andreas K. Huettel
Gentoo Linux developer 
kde (team lead), sci, tex, arm, printing
dilfridge@gentoo.org
http://www.akhuettel.de/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] pushing fixes to stable before closing bugs

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 1226 bytes --]

> I noticed a general tendency to close bugs affecting stable before
> pushing the fix to stable.
> 
Right.

> The idea is that if you only fix in ~arch, you risk a serious and
> _known_ regression in stable, which could be easily avoided.
>
As already detailed by others, most of the time these bugs involve problems 
that existed in stable all the time and were fixed in a newer ~arch version. 
So, no regression.

While I understand and applaud your intentions, I dont really intend to keep 
gazillions of bugs open until the last arch has closed the last stablerequest. 
Just for the simple reason that this is dead wood in bugzilla, and blocking 
the view to bugs that actually still need fixing. Also, we dont necessarily 
know from the beginning which revision will go stable.

(BTW, x86 is a bit behind at the moment. :)

We might think about a dedicated application for tracking stabilizations, 
instead of using bugzilla. Alternatively, one could extend bugzilla in a way 
that each closed bug report MUST contain an affected package version *range*.

-- 
Andreas K. Huettel
Gentoo Linux developer 
kde (team lead), sci, tex, arm, printing
dilfridge@gentoo.org
http://www.akhuettel.de/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]