All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rolf Leggewie <no2spam@nospam.arcornews.de>
To: openembedded-devel@openembedded.org
Subject: RFD: Bugzilla in general & bug triaging
Date: Sun, 13 May 2007 16:33:06 +0200	[thread overview]
Message-ID: <f277j3$i00$1@sea.gmane.org> (raw)
In-Reply-To: <1179059149.5404.3.camel@cimmeria.hyboria>

Graeme Gregory wrote:
> RFC
> 
> Dont add people to CC field of bugs without talking to them.

Thank you Graeme for raising this issue.  It is something I meant to 
discuss earlier but never found enough time to think it through and 
write up something.  I still have not thought it through, but here it goes.

Let me first say, that I am totally aware that we are all doing this in 
our limited free time.  We also all don't like things being stuffed down 
our throat.  There is a bit of dilemma here.

As a non-dev, I feel one of the better ways for me and others alike is 
to make sure the BTS is in good shape.  It is called bug triaging which 
I also do in other projects.  For me, this is all about efficiency, 
division of labor so to speak (although that capitalistic thinking might 
not go down too well with all of us freeminds ;-))  The idea is that 
there is someone who sifts through the bug reports and makes sure they 
are understandable, complete and real.  The triager also crosslinks bugs 
that share similarities and classifies them.   All this *before they eat 
up valuable time from a real dev*.  That is at least what I am trying to 
do, for the devs to sit down and find well-structured problems to work 
on whenever they feel like it (I know the OE BTS is not there yet, bug 
2194 is a shy start at this).

This is how Ubuntu and Mozilla approach the bugs they receive.  But it 
needs a way to signal "Hey, this bug is OK" and furthermore bugs are 
usually assigned to the most appropriate person.  So that is what I did 
first, assign bugs to the people I thought would be most appropriate in 
dealing with them.  That did not go down so well :-)  So, it was 
suggested to me that instead of assigning, I should cc people.  But that 
is certainly not the best solution, either.

I believe it would be great if OE started some kind of not too rigid 
process of triaging bugs.  All projects are a bit different, so what do 
you think would be the best way for OE to handle this?

 > Everyone on oe-issues list gets all bug reports anyway and I can use
 > web search quite effectively myself.

Graeme, I understand your concern.  I don't mean to say "Hey, here is 
the solution" but maybe there are some options you might consider.

First is that I would think that it might be a waste of valuable dev 
time if all core devs read all bug reports on oe-issues.  Of course, 
that is an individual decision.  But if we got something like bug 
triaging going in a more instituationalized way, it might indeed become 
unnecessary.  Second, bugzilla offers many settings on what mails you 
want to receive and which you don't at 
http://bugs.openembedded.org/userprefs.cgi?tab=email.  If you read 
oe-issues, you might want to consider deactivating all mail from 
bugzilla itself to keep the load down.




  parent reply	other threads:[~2007-05-13 14:34 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-13 12:25 RFC: Bugzilla CC Field Graeme Gregory
2007-05-13 14:29 ` Koen Kooi
2007-05-13 14:33 ` Rolf Leggewie [this message]
2007-05-13 15:02   ` RFD: Bugzilla in general & bug triaging Koen Kooi
2007-05-13 15:15   ` Paul Sokolovsky
2007-05-14  8:08   ` Junqian Gordon Xu
2007-05-14  8:25     ` Paul Sokolovsky
2007-05-14  8:49       ` Junqian Gordon Xu
2007-05-14  9:06         ` Paul Sokolovsky
2007-05-14  9:18           ` Junqian Gordon Xu
2007-05-14  9:06         ` Koen Kooi
2007-05-14 10:16         ` Rolf Leggewie
2007-05-14 11:26           ` Paul Sokolovsky
2007-05-14 10:28   ` Rolf Leggewie
2007-05-14 13:28     ` Marcin Juszkiewicz
2007-05-16  3:27     ` Junqian Gordon Xu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='f277j3$i00$1@sea.gmane.org' \
    --to=no2spam@nospam.arcornews.de \
    --cc=openembedded-devel@lists.openembedded.org \
    --cc=openembedded-devel@openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.