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-06-2010, 08:32 AM
"Robin H. Johnson"
 
Default RFC Bugzilla interaction guide for devs & editbugs users

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
 
Old 09-06-2010, 08:39 AM
Dirkjan Ochtman
 
Default RFC Bugzilla interaction guide for devs & editbugs users

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
 
Old 09-06-2010, 12:10 PM
Christian Faulhammer
 
Default RFC Bugzilla interaction guide for devs & editbugs users

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/>
 
Old 09-06-2010, 12:36 PM
Alex Legler
 
Default RFC Bugzilla interaction guide for devs & editbugs users

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
 
Old 09-06-2010, 12:38 PM
Alex Legler
 
Default RFC Bugzilla interaction guide for devs & editbugs users

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
 
Old 09-06-2010, 03:31 PM
Michael Weber
 
Default 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 <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
 
Old 09-06-2010, 04:07 PM
Christian Faulhammer
 
Default RFC Bugzilla interaction guide for devs & editbugs users

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/>
 
Old 09-06-2010, 09:24 PM
Ryan Hill
 
Default RFC Bugzilla interaction guide for devs & editbugs users

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
 
Old 09-07-2010, 08:47 PM
Róbert Čerňanský
 
Default RFC Bugzilla interaction guide for devs & editbugs users

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
 
Old 09-07-2010, 09:30 PM
"Robin H. Johnson"
 
Default 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 : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
 

Thread Tools




All times are GMT. The time now is 02:49 AM.

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