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

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

[Robin H. Johnson]

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

Hi,

After a discussion on IRC, a few of us were considering the value of
adding suggestions on handling of bugs in Bugzilla from a developer (and
editbugs user) perspective.

These is the simplest set I have to start, but I'd really like other
comments and ideas.

1. General case
  - You should only close bugs that you are assigned or if you (or an alias
	you represent) just fixed them.
  - If you fix a bug and AREN'T already getting mail for it, you should
	add yourself to the CC list, to listen for regressions or responses
	to TESTREQUEST.

2. Special cases
2.1. STABLEREQ, KEYWORDREQ
  The last arch on the list should close the bug when they have completed
  the action.

2.2. Security bugs
  The developer should comment, but ONLY members of the security team
  should:
  - change whiteboard
  - add/remove arches
  - change bug status/reso

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 330 bytes --]

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

[Dirkjan Ochtman]

On Mon, Sep 6, 2010 at 10:32, Robin H. Johnson <robbat2@gentoo.org> wrote:
> After a discussion on IRC, a few of us were considering the value of
> adding suggestions on handling of bugs in Bugzilla from a developer (and
> editbugs user) perspective.

Good idea, I've been confused about the interaction models here.

> 1. General case
>  - You should only close bugs that you are assigned or if you (or an alias
>        you represent) just fixed them.
>  - If you fix a bug and AREN'T already getting mail for it, you should
>        add yourself to the CC list, to listen for regressions or responses
>        to TESTREQUEST.

Only add arches to stabilization requests if you're a maintainer?

> 2. Special cases
> 2.1. STABLEREQ, KEYWORDREQ
>  The last arch on the list should close the bug when they have completed
>  the action.
>
> 2.2. Security bugs
>  The developer should comment, but ONLY members of the security team
>  should:
>  - change whiteboard
>  - add/remove arches
>  - change bug status/reso

The arches can still remove themselves when they've done whatever they
needed to do, right?

Cheers,

Dirkjan

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

[Christian Faulhammer]

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

Hi,

"Robin H. Johnson" <robbat2@gentoo.org>:
> 2.2. Security bugs
>   The developer should comment, but ONLY members of the security team
>   should:
>   - change whiteboard
>   - add/remove arches

 As security may be grateful for any kind of help, those two actions is
often done by the maintainers.

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://gentoo.faulhammer.org/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Alex Legler]

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

On Mon, 6 Sep 2010 14:10:41 +0200, Christian Faulhammer
<fauli@gentoo.org> wrote:

> Hi,
> 
> "Robin H. Johnson" <robbat2@gentoo.org>:
> > 2.2. Security bugs
> >   The developer should comment, but ONLY members of the security
> > team should:
> >   - change whiteboard
> >   - add/remove arches
> 
>  As security may be grateful for any kind of help, those two actions
> is often done by the maintainers.
> 

We are indeed grateful for help, but we require people who change
things there to know what they are doing.

I understand that we're slow at times, but we regularly have to revisit
a bug because there was a change, but it wasn't done right. 
That's no help. Instead, it's creating more work (and frustration).

There is a specific guideline on how we handle our bugs, and we request
people who change bugs assigned to our team to follow them or to stay
away.

So, as for the guide, it should link to the vulnerability policy as
well include a note with the contents of the previous paragraph.

-- 
Alex Legler | Gentoo Security / Ruby
a3li@gentoo.org | a3li@jabber.ccc.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Alex Legler]

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

On Mon, 6 Sep 2010 10:39:59 +0200, Dirkjan Ochtman <djc@gentoo.org>
wrote:

> [...]
> >
> > 2.2. Security bugs
> >  The developer should comment, but ONLY members of the security team
> >  should:
> >  - change whiteboard
> >  - add/remove arches
> >  - change bug status/reso
> 
> The arches can still remove themselves when they've done whatever they
> needed to do, right?
> 

Of course.

-- 
Alex Legler | Gentoo Security / Ruby
a3li@gentoo.org | a3li@jabber.ccc.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Michael Weber]

On 09/06/2010 10:39 AM, Dirkjan Ochtman wrote:
> On Mon, Sep 6, 2010 at 10:32, Robin H. Johnson <robbat2@gentoo.org> wrote:
>> After a discussion on IRC, a few of us were considering the value of
>> adding suggestions on handling of bugs in Bugzilla from a developer (and
>> editbugs user) perspective.
> 
> Good idea, I've been confused about the interaction models here.
> 
>> 1. General case
>>  - You should only close bugs that you are assigned or if you (or an alias
>>        you represent) just fixed them.
>>  - If you fix a bug and AREN'T already getting mail for it, you should
>>        add yourself to the CC list, to listen for regressions or responses
>>        to TESTREQUEST.
> 
> Only add arches to stabilization requests if you're a maintainer?

What about user issued KEYWORD/STABLE-REQ on maintainer-needed@g.o assignd
bugs/packages?

Close as RESO/WONTFIX or add the arches?

Michael

-- 
Gentoo Developer

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

[Christian Faulhammer]

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

Hi,

Michael Weber <xmw@gentoo.org>:
> What about user issued KEYWORD/STABLE-REQ on maintainer-needed@g.o
> assignd bugs/packages?
> 
> Close as RESO/WONTFIX or add the arches?

 Common sense.  Practice has been to add arches if it fixes a problem
in a current stable, if there is no stable version available or the
current one is still ok, rethink.

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://gentoo.faulhammer.org/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Ryan Hill]

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

On Mon, 6 Sep 2010 10:39:59 +0200
Dirkjan Ochtman <djc@gentoo.org> wrote:

> On Mon, Sep 6, 2010 at 10:32, Robin H. Johnson <robbat2@gentoo.org> wrote:
> > After a discussion on IRC, a few of us were considering the value of
> > adding suggestions on handling of bugs in Bugzilla from a developer (and
> > editbugs user) perspective.
> 
> Good idea, I've been confused about the interaction models here.
> 
> > 1. General case
> >  - You should only close bugs that you are assigned or if you (or an alias
> >        you represent) just fixed them.

Prefix "Once assigned,".

Can we add a point about bug-wranglers not messing with bugs after they've
been assigned?  I've had someone closing bugs filed directly from a dev to my
herd because they didn't include emerge --info.

> >  - If you fix a bug and AREN'T already getting mail for it, you should
> >        add yourself to the CC list, to listen for regressions or responses
> >        to TESTREQUEST.
> 
> Only add arches to stabilization requests if you're a maintainer?

No.  If the maintainer doesn't respond in a reasonable amount of time then
I'm adding arches myself.  If this weren't allowed then the GCC stabilization
bugs would take approx 8 years to fix.


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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Róbert Čerňanský]

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

On Mon, 6 Sep 2010 08:32:16 +0000
"Robin H. Johnson" <robbat2@gentoo.org> wrote:

[...]
> 2. Special cases

As a user I'd like to see following:

2.3. Upstream issues
   Do not close a bug (as RESOLVED/UPSTREAM) until it is fixed by
   upstream.

Robert


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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Robin H. Johnson]

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

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

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

[Andreas K. Huettel]

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

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


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

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

[dev-random]

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.

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

[Pacho Ramos]

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

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.

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

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

[Duncan]

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

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

[Ryan Hill]

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

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Jeroen Roovers]

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

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

[Duncan]

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

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

[Jeroen Roovers]

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

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

[Róbert Čerňanský]

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