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

2010-09-10 Thread Jeroen Roovers
On Tue, 7 Sep 2010 21:30:34 +
Robin H. Johnson robb...@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



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

2010-09-07 Thread Róbert Čerňanský
On Mon, 6 Sep 2010 08:32:16 +
Robin H. Johnson robb...@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: hslis...@zoznam.sk
Jabber: h...@jabber.sk


signature.asc
Description: PGP signature


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

2010-09-07 Thread 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 : robb...@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

2010-09-07 Thread Andreas K. Huettel
  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



signature.asc
Description: This is a digitally signed message part.


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

2010-09-07 Thread dev-random
On Tue, Sep 07, 2010 at 09:30:34PM +, 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

2010-09-06 Thread Alex Legler
On Mon, 6 Sep 2010 10:39:59 +0200, Dirkjan Ochtman d...@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
a...@gentoo.org | a...@jabber.ccc.de


signature.asc
Description: PGP signature


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

2010-09-06 Thread Michael Weber
On 09/06/2010 10:39 AM, Dirkjan Ochtman wrote:
 On Mon, Sep 6, 2010 at 10:32, Robin H. Johnson robb...@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-nee...@g.o assignd
bugs/packages?

Close as RESO/WONTFIX or add the arches?

Michael

-- 
Gentoo Developer