[gentoo-dev] Re: RFC Bugzilla interaction guide for devs & editbugs users

[Ryan Hill]

On Tue, 7 Sep 2010 22:53:22 +0000 (UTC)
Duncan <1i5t5.duncan@×××.net> wrote:

> 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@××××.ru 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.

Sure it is.  That's what a blocker is.  The bug isn't fixed.  How can the
action requiring that the bug be fixed to happen take place?

What isn't appropriate is resolving bugs blocking other bugs as RESO/UPSTREAM
in the first place. It basically takes us out of the loop.  Even if the bug
might be fixed better upstream, the bug report in which this is determined
should not be closed until the bug is fixed in Gentoo.  It becomes the
tracker of the upstream progress of the bug, and the later reintegration of
the solution back into Gentoo.  That is, after all, what the dependency bug
is concerned with.
 
> 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.

No.  Here's my scenario.  gcc-porting creates a tracker bug everytime GCC
trunk hits stage 3 for the upcoming version where all packages with build
errors get added as blockers.

In the early throes of this process, where many packagers
(understandably) couldn't give two shits about a GCC version that they've
never heard of I get many bugs closed as RESO/INVALID or RESO/UPSTREAM.  This
encompasses the "not my problem, take it upstream" definition of
RESO/UPSTREAM, and I respect this.  Meanwhile the package is still broken and
while the patches I have do go upstream, I have no way of tracking when these
fixes get into Gentoo without personally and obsessively tracking their
individual progress, which, sadly, I do (see the gcc-porting overlay).

Later as release approaches and people are more amenable, I sometimes get the
"I sent this upstream, they've applied it" RESO/UPSTREAM. Again, this doesn't
help us.  The Gentoo package is still broken.  These I just reopen with a note
saying close it when the fix reaches portage, generally because at this point
I'm too burnt out by stage 1 above.

At release time we always get a few high profile projects shun the new
release for breaking their favorite feature and decree on high they will not
support it.  RESO/UPSTREAM seems designed for these types of bugs, surely we
can use it here!  Nope.  It's still broken.  We judge how ready we are to
unmask new major compiler releases by looking at how many _open_ bugs there
are on the tracker.  If these types of high-profile bugs are RESO/UPSTREAM,
they will probably get overlooked, like I almost missed emacs (twice!)
earlier in the 4.5 cycle.

The point is, no matter how you interpret it, RESO/UPSTREAM is never a good
idea for bugs blocking others.

I have no problem how you use it outside that context.

-- 
fonts, gcc-porting,             we hold our breath, we spin around the world
toolchain, wxwidgets            you and me cling to the outside of the earth
@ gentoo.org                EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662