FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 05-12-2012, 10:34 AM
"Paweł Hajdan, Jr."
 
Default pushing fixes to stable before closing bugs

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ł
 
Old 05-12-2012, 10:50 AM
Pacho Ramos
 
Default pushing fixes to stable before closing bugs

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)
 
Old 05-12-2012, 04:28 PM
Rich Freeman
 
Default pushing fixes to stable before closing bugs

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
 
Old 05-12-2012, 08:01 PM
"Paweł Hajdan, Jr."
 
Default pushing fixes to stable before closing bugs

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ł
 
Old 05-12-2012, 08:17 PM
Rich Freeman
 
Default pushing fixes to stable before closing bugs

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
 
Old 05-12-2012, 09:15 PM
"Andreas K. Huettel"
 
Default pushing fixes to stable before closing bugs

> 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/
 
Old 05-12-2012, 09:26 PM
"Andreas K. Huettel"
 
Default pushing fixes to stable before closing bugs

> 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/
 

Thread Tools




All times are GMT. The time now is 06:46 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org