Re: [gentoo-dev] RFC Bugzilla interaction guide for devs editbugs users
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
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
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
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
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
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
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