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 09-07-2010, 09:43 PM
"Andreas K. Huettel"
 
Default RFC Bugzilla interaction guide for devs & editbugs users

> > 2.3. Upstream issues
> >
> > Do not close a bug (as RESOLVED/UPSTREAM) until it is fixed by
> > upstream.
>
> 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).


Some teams are already tracking (some) upstream bugs like this. E.g. kde.

This is another case where RESOLVED does not really apply. We'd really need an
alternative category, e.g. DEFERRED. Meaning the problem is still there but we
can't / won't do anything about it now. The bug is not resolved but remains as
a silent reminder.

Then,
RESOLVED UPSTREAM -> DEFERRED UPSTREAM
RESOLVED LATER -> DEFERRED LATER

Cheers, Andreas
 
Old 09-07-2010, 09:44 PM
 
Default RFC Bugzilla interaction guide for devs & editbugs users

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.
 
Old 09-07-2010, 10:05 PM
Pacho Ramos
 
Default RFC Bugzilla interaction guide for devs & editbugs users

El miÚ, 08-09-2010 a las 01:44 +0400, dev-random@mail.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.
 
Old 09-07-2010, 10:53 PM
Duncan
 
Default RFC Bugzilla interaction guide for devs & editbugs users

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@mail.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.

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
 
Old 09-08-2010, 04:44 AM
Ryan Hill
 
Default RFC Bugzilla interaction guide for devs & editbugs users

On Tue, 7 Sep 2010 22:53:22 +0000 (UTC)
Duncan <1i5t5.duncan@cox.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@mail.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
 
Old 09-10-2010, 04:32 PM
Jeroen Roovers
 
Default RFC Bugzilla interaction guide for devs & editbugs users

On Tue, 7 Sep 2010 21:30:34 +0000
"Robin H. Johnson" <robbat2@gentoo.org> wrote:

> On Tue, Sep 07, 2010 at 10:47:27PM +0200, R├│bert ─îer┼łansk├Ż wrote:
> > 2.3. Upstream issues
> > Do not close a bug (as RESOLVED/UPSTREAM) until it is fixed by
> > upstream.

If the reason you propose this is visibility, then maybe we should make
the quicksearch option include more than just open bugs. I've thought
about having UPSTREAM/DUPLICATE/INVALID added so that bugzilla users
can more easily discover whether a bug was already reported and was
deemed fixed, a duplicate of another bug or canonically invalid.

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

Quoting [1]:
UPSTREAM
It is not suitable to deal with the bug at this level, and the bug
should be taken to the upstream developers for resolution.

It all depends on the kind of bug. Requests for new features should
probably normally go upstream (including the kind where a patch is
available). That's out of our scope. With the above proposal, feature
request bugs like bug #171277 [2] might not go unnoticed as easily. In
the case of app-misc/screen, upstream did seem dead for a couple of
years, and even now after many new features were added (including
vertical split) and bug fixes were included there, there is still no
new version out. I guess that bug is still not marked UPSTREAM just to
aid in its visibility - after the bug was reopened, no more
duplicates were filed.


jer


[1] https://bugs.gentoo.org/page.cgi?id=fields.html#resolution
[2] https://bugs.gentoo.org/show_bug.cgi?id=171277
 
Old 09-11-2010, 07:17 AM
Duncan
 
Default RFC Bugzilla interaction guide for devs & editbugs users

Jeroen Roovers posted on Fri, 10 Sep 2010 18:32:38 +0200 as excerpted:

> If the reason you propose this is visibility, then maybe we should make
> the quicksearch option include more than just open bugs. I've thought
> about having UPSTREAM/DUPLICATE/INVALID added so that bugzilla users can
> more easily discover whether a bug was already reported and was deemed
> fixed, a duplicate of another bug or canonically invalid.

I've wondered why quick-search didn't do ALL by default, myself.

Bugzilla's advanced search is quite difficult for users to get right (I
never seem to, tho it may be konqueror's scripting or some such, so I use
quick-search and either specify version or start from the bottom and work
backward as far as I believe reasonable), so I presume most use the quick
search nearly exclusively. That being the case, and further, the case
being that users almost certainly will want ALL, having that NOT the
default is simply begging for users to miss closed bugs.

So I'd say make ALL the default, and have an ONLYOPEN or some such option,
instead, to cover the current default for those who actually want/need it.

--
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
 
Old 09-11-2010, 01:43 PM
Jeroen Roovers
 
Default RFC Bugzilla interaction guide for devs & editbugs users

On Sat, 11 Sep 2010 07:17:01 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> Jeroen Roovers posted on Fri, 10 Sep 2010 18:32:38 +0200 as excerpted:
>
> > If the reason you propose this is visibility, then maybe we should
> > make the quicksearch option include more than just open bugs. I've
> > thought about having UPSTREAM/DUPLICATE/INVALID added so that
> > bugzilla users can more easily discover whether a bug was already
> > reported and was deemed fixed, a duplicate of another bug or
> > canonically invalid.
>
> I've wondered why quick-search didn't do ALL by default, myself.

Because it's never just right. We'd get even more people reopening bug
reports that were RESOLVED/FIXED years ago just because there's a
similarity in package/problem. Also, because you'd easily see a couple
of thousands of results listed. Just think of all the bugs filed with a
Summary of "fails to compile" or "emake failed" instead of something
specific, accurate, unique. Which is why we should all make an effort
to move away from the "firefox crashed" type of Summary, but that's an
never-ending battle as well.


jer
 
Old 09-11-2010, 09:58 PM
R├│bert ─îer┼łansk├Ż
 
Default RFC Bugzilla interaction guide for devs & editbugs users

On Fri, 10 Sep 2010 18:32:38 +0200
Jeroen Roovers <jer@gentoo.org> wrote:

> On Tue, 7 Sep 2010 21:30:34 +0000
> "Robin H. Johnson" <robbat2@gentoo.org> wrote:
>
> > On Tue, Sep 07, 2010 at 10:47:27PM +0200, R├│bert ─îer┼łansk├Ż wrote:
> > > 2.3. Upstream issues
> > > Do not close a bug (as RESOLVED/UPSTREAM) until it is fixed by
> > > upstream.
>
> If the reason you propose this is visibility, then maybe we should
> make the quicksearch option include more than just open bugs. I've
> thought about having UPSTREAM/DUPLICATE/INVALID added so that

Visibility, I would say is kind of derived problem. Visible or not,
currently the RESOLVED/UPSTREM state does not tell whether a bug is
fixed (in gentoo) or not.

From a user point of view even an upstream bug is a bug in software
that is part of gentoo distribution and I think the right way to deal
with it would be to report it further to upstream by gentoo develpers,
and close in gentoo once fixed version gets to the tree (of course
users (most likely the reporter of a bug) can be asked to help and
report bug by themselves).

Just let bugzilla reflect the _realilty_, that's the right foundation
to other issues as well I think (like visibility, dependency and so
on). Yes we might end up with another 2500 bugs open but if that's
the reality then let them be. Why pretend that they arn't there?

However, to leave such bugs open as if they would be non-upstream ones
is probably also not a good idea. I would imagine that a developer
wants to see only those bugs that he can work on while on upstream
ones he can not do anything. Therefore we need a new state that would
represent "open upstream" bugs (EXPORTED/UPSTREAM perhaps).

Robert


--
Robert Cernansky
E-mail: hslists2@zoznam.sk
Jabber: hs@jabber.sk
 

Thread Tools




All times are GMT. The time now is 03:36 PM.

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