Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Duncan <1i5t5.duncan@...>
Subject: Re: RFC Bugzilla interaction guide for devs & editbugs users
Date: Tue, 7 Sep 2010 22:53:22 +0000 (UTC)
Pacho Ramos posted on Wed, 08 Sep 2010 00:05:34 +0200 as excerpted:

> El mié, 08-09-2010 a las 01:44 +0400, dev-random@... escribió:
>> On Tue, Sep 07, 2010 at 09:30:34PM +0000, Robin H. Johnson wrote:
>> > This implies that the upstream is alive enough to fix it.
>> > 
>> > I feel it should mean that the bug has been reported to upstream, and
>> > that state is documented in the bug.
>> > 
>> > If we keep every upstream bug open instead of closed, we'd have
>> > probably another 2500 open bugs (5312 RESO/UPSTREAM in the history of
>> > Gentoo, and I'm ballparking that 50% aren't actually fixed yet
>> > upstream).
>> 
>> Bug may be a blocker. And marking it as RESOLVED/UPSTREAM you may
>> unblock another bug (e.g. stabilization request) which should be still
>> blocked because there is no fixed package in tree.
>> 
>> 
> In most cases when it's really a blocker, bug will remain opened anyway
> until solved or, if not possible, stabilization will be postponed.

Additionally, RESOLVED/UPSTREAM indicates that the Gentoo package 
maintainer (or other dev who marked it such) believes Gentoo is not the 
appropriate place for a patch fixing the problem.

As such, the bug will never be fixed at the Gentoo level, only upstream, 
and if there's a blocker on it, the blocker would never get resolved 
either, until upstream fixes it.  Where upstream isn't active or doesn't 
believe the fix appropriate either, that'd lead to stalemate and forever 
blocking the dependent Gentoo bug.  That's not appropriate either.

So RESOLVED/UPSTREAM *should* unblock blockers, even where upstream 
doesn't resolve, or we've simply created a deadlock that's not going to be 
resolved.  If it's truly a blocker, the problem will need worked around 
some other way.  But often, "blockers" really aren't blockers, when 
upstream chooses not to take the package in that direction after all.  It 
simply means some other alternative, perhaps an alternative package, must 
be developed instead, and the package as it is can continue to evolve in 
the normal way.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman



Replies:
Re: RFC Bugzilla interaction guide for devs & editbugs users
-- Ryan Hill
References:
RFC Bugzilla interaction guide for devs & editbugs users
-- Robin H. Johnson
Re: RFC Bugzilla interaction guide for devs & editbugs users
-- Róbert Čerňanský
Re: RFC Bugzilla interaction guide for devs & editbugs users
-- Robin H. Johnson
Re: RFC Bugzilla interaction guide for devs & editbugs users
-- dev-random
Re: RFC Bugzilla interaction guide for devs & editbugs users
-- Pacho Ramos
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: RFC Bugzilla interaction guide for devs & editbugs users
Next by thread:
Re: RFC Bugzilla interaction guide for devs & editbugs users
Previous by date:
Re: RFC Bugzilla interaction guide for devs & editbugs users
Next by date:
Re: RFC Bugzilla interaction guide for devs & editbugs users


Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.