RFC: Bugzilla CC Field

RFC: Bugzilla CC Field

[Graeme Gregory]

RFC

Dont add people to CC field of bugs without talking to them.

Recently I am finding myself added as CC to bugs I have no interest in
as I either don't have the hardware or don't use the software in
question.

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

Graeme (XorA)

Re: RFC: Bugzilla CC Field

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Graeme Gregory schreef:
> RFC
> 
> Dont add people to CC field of bugs without talking to them.
> 
> Recently I am finding myself added as CC to bugs I have no interest in
> as I either don't have the hardware or don't use the software in
> question.
> 
> Everyone on oe-issues list gets all bug reports anyway and I can use web
> search quite effectively myself.

Same here, and I was suggested to just turn off all email in the bugzilla userprefs.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGRyDPMkyGM64RGpERAmzyAJ4lfF/HAeoRx0k/Kn+jXme1ed8xOwCdGr+V
yEXpOXkev8SZFGHcxLqP5pw=
=bROF
-----END PGP SIGNATURE-----

RFD: Bugzilla in general & bug triaging

[Rolf Leggewie]

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.

Re: RFD: Bugzilla in general & bug triaging

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rolf Leggewie schreef:

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

Personally, I treat oe-issues the same as oe-commits, by just skimming through the
subjects and reading ones that trigger some sort of red flag.

regards,

Koen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGRyh5MkyGM64RGpERAih1AKCSCjkbNYMQKvz5uGBlSC4kJUFCuwCdH/ZS
dxXPFRHDlbpXplCWROFMuN8=
=rrgr
-----END PGP SIGNATURE-----

Re: RFD: Bugzilla in general & bug triaging

[Paul Sokolovsky]

Hello Rolf,

Sunday, May 13, 2007, 5:33:06 PM, you wrote:

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

        I'm sure that I can speak from many peoples' side: your work
and effort on bug management is *much* appreciated. Thanks to you, we
now have *live* bugtracker, not a swamp, which it was just few months
ago.

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

        I guess this can be expressed as:

1. If there's a confirmed bugtracker manager, whatever he does,
already has good weight in it.
2. There're indeed well-known work flow patterns and best practices,
and those should be rather reused, not ignored.
3. There should be room for improvements and adaption to our specific
case and environment.

        In this regard, I think that current scheme, and your use of
it, is good enough to go with. In particular, I appreciate, and
recommend, that everyone who submits something important (or having
other special criteria) for the area I maintain/watch, to add myself
to cc:, to ensure prompt replies and addition guarantee that important
issues are not lost in awful amount of mail I receive, and don't
depend on not 100% reliable things like my watching bug tracker
notifications.

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

        I guess this solution is straight into bull's eye - why spend
time communicating your preferences to other people (or, fingers
crossed, quarrel with them), if they instead can be communicated to
Bugzilla, which is there to serve all needs. The same goes for
everyone's best friend, an email client, which has cool things like
folders and filters, and opens their wonders to everyone who wants to
*receive* their mail the way they want, instead of arguing with the
whole world (or arbitrary part of it) how it should send mail to them ;-)


-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com

Re: RFD: Bugzilla in general & bug triaging

[Junqian Gordon Xu]

Rolf,

Is it a problem if I replace the openembedded-issues@ with my email 
address in the Reassign to field? Does openembedded-issues still gets 
all the updates?

I don't want only me receiving the emails even I assign the bug to myself.

regards
Gordon

Rolf Leggewie wrote:
> 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.
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
>   

Re: RFD: Bugzilla in general & bug triaging

[Paul Sokolovsky]

Hello Junqian,

Monday, May 14, 2007, 11:08:03 AM, you wrote:

> Rolf,

> Is it a problem if I replace the openembedded-issues@ with my email 
> address in the Reassign to field? Does openembedded-issues still gets 
> all the updates?

        As Rolf described in his mail, we do not reassign bugs in our
workflow - they keep being assigned to ML. That's corresponds to
the fact/reassures that we don't have bug owners in OE, and entire
community welcome to/works on any issue (which in turn is based on the
fact that we don't have dedicated engineers to resolve bugs).

> I don't want only me receiving the emails even I assign the bug to myself.

> regards
> Gordon

> Rolf Leggewie wrote:
[]

-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com

Re: RFD: Bugzilla in general & bug triaging

[Junqian Gordon Xu]

Paul Sokolovsky wrote:
> Hello Junqian,
>
> Monday, May 14, 2007, 11:08:03 AM, you wrote:
>
>   
>> Is it a problem if I replace the openembedded-issues@ with my email 
>> address in the Reassign to field? Does openembedded-issues still gets 
>> all the updates?
>>     
>
>         As Rolf described in his mail, we do not reassign bugs in our
> workflow - they keep being assigned to ML. That's corresponds to
> the fact/reassures that we don't have bug owners in OE, and entire
> community welcome to/works on any issue (which in turn is based on the
> fact that we don't have dedicated engineers to resolve bugs).

Paul,

One benefit of reassigning the bug to myself is that I can click the "My 
Bug" button and list all my filed and self-assigned bugs, instead of 
remembering the bug number or relying on search.

I'm undoing the damages right now. But please let me know if there's an 
alternative to easily keep track of interested bugs.  Well, maybe I'm 
too lazy.

Gordon

Re: RFD: Bugzilla in general & bug triaging

[Paul Sokolovsky]

Hello Junqian,

Monday, May 14, 2007, 11:49:12 AM, you wrote:

> Paul Sokolovsky wrote:
>> Hello Junqian,
>>
>> Monday, May 14, 2007, 11:08:03 AM, you wrote:
>>
>>   
>>> Is it a problem if I replace the openembedded-issues@ with my email 
>>> address in the Reassign to field? Does openembedded-issues still gets 
>>> all the updates?
>>>     
>>
>>         As Rolf described in his mail, we do not reassign bugs in our
>> workflow - they keep being assigned to ML. That's corresponds to
>> the fact/reassures that we don't have bug owners in OE, and entire
>> community welcome to/works on any issue (which in turn is based on the
>> fact that we don't have dedicated engineers to resolve bugs).

> Paul,

> One benefit of reassigning the bug to myself is that I can click the "My
> Bug" button and list all my filed and self-assigned bugs, instead of 
> remembering the bug number or relying on search.

        I well understand benefits of assigning bugs, it's just the
fact that OE doesn't assign them (as as was mentioned, it's good, as
have psychological effect of welcoming everyone to work on things, not
think "well, that guy will fix it" or "oh, it's that guy's, I can't
touch it").

> I'm undoing the damages right now. But please let me know if there's an
> alternative to easily keep track of interested bugs.  Well, maybe I'm 
> too lazy.

        You still better rely on search. And Bugzilla is a powerful
("enterprise-grade" ;-) ) tool, which allows you to do many things.
For example, that's how I have it set up: I add myself to cc: of the
interesting bugs (in full accordance to Rolf's RFD), then once made
an advanced search setup, which searches for my address in any email
field (reporter, cc, etc.), and saved it as saved search. Now, it's
the same one click as predefined "My Bugs" search. And you can have
number of saved searches, for machines of your interest, for software,
etc. - all one click away.

> Gordon


-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com

Re: RFD: Bugzilla in general & bug triaging

[Junqian Gordon Xu]

Paul Sokolovsky wrote:
>> I'm undoing the damages right now. But please let me know if there's an
>> alternative to easily keep track of interested bugs.  Well, maybe I'm 
>> too lazy.
>>     
>
>         You still better rely on search. And Bugzilla is a powerful
> ("enterprise-grade" ;-) ) tool, which allows you to do many things.
> For example, that's how I have it set up: I add myself to cc: of the
> interesting bugs (in full accordance to Rolf's RFD), then once made
> an advanced search setup, which searches for my address in any email
> field (reporter, cc, etc.), and saved it as saved search. Now, it's
> the same one click as predefined "My Bugs" search. And you can have
> number of saved searches, for machines of your interest, for software,
> etc. - all one click away

Thanks for the great tip. When I said I was too lazy, that's also 
including that I'm too lazy to study/play with all the features of 
Bugzilla, esp. considering the enterprise-grade motto :)

Gordon

Re: RFD: Bugzilla in general & bug triaging

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Junqian Gordon Xu schreef:
> Paul Sokolovsky wrote:
>> Hello Junqian,
>>
>> Monday, May 14, 2007, 11:08:03 AM, you wrote:
>>
>>   
>>> Is it a problem if I replace the openembedded-issues@ with my email 
>>> address in the Reassign to field? Does openembedded-issues still gets 
>>> all the updates?
>>>     
>>         As Rolf described in his mail, we do not reassign bugs in our
>> workflow - they keep being assigned to ML. That's corresponds to
>> the fact/reassures that we don't have bug owners in OE, and entire
>> community welcome to/works on any issue (which in turn is based on the
>> fact that we don't have dedicated engineers to resolve bugs).
> 
> Paul,
> 
> One benefit of reassigning the bug to myself is that I can click the "My 
> Bug" button and list all my filed and self-assigned bugs, instead of 
> remembering the bug number or relying on search.
> 
> I'm undoing the damages right now. But please let me know if there's an 
> alternative to easily keep track of interested bugs.  Well, maybe I'm 
> too lazy.

You could assign to yourself and add oe-issues in CC:

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGSCajMkyGM64RGpERAldiAKCqrJcD6ZE0ULRWcz1Ksxxi+LQ2dACdHXvV
cdawEzHNUHLAOXzREdLLIKQ=
=wDhJ
-----END PGP SIGNATURE-----

Re: RFD: Bugzilla in general & bug triaging

[Rolf Leggewie]

Junqian Gordon Xu wrote:
>>         As Rolf described in his mail, we do not reassign bugs in our
>> workflow 

Actually that is neither what I wrote nor what I'd propose ;-)  I have 
no issue with you assigning 2309 to yourself.  You seem to take good 
care of it.

> One benefit of reassigning the bug to myself is that I can click the "My 
> Bug" button and list all my filed and self-assigned bugs, instead of 
> remembering the bug number or relying on search.

yes, very valid point.  It innocently illustrates the kind of workflow 
I'd be looking for (and that I use to a certain degree for myself).  You 
have a link with a search function saved in bugzilla and when you click 
on it all the bugs that need your attention or that you are interested 
in are right there.

Gordon, maybe you want to save http://tinyurl.com/385p8b  You could also 
separate that out to only list cc bugs or whatever suits your needs. 
Tweak it to your liking.

Here are three searches that I use and deem useful for others

http://tinyurl.com/2oypog (todays bugs: action: stay current)
http://tinyurl.com/35l78g (bugs where compilation fails, action: verify)
http://tinyurl.com/39gss8 (old with patches, action: inspect, commit)

Re: RFD: Bugzilla in general & bug triaging

[Paul Sokolovsky]

Hello Rolf,

Monday, May 14, 2007, 1:16:37 PM, you wrote:

> Junqian Gordon Xu wrote:
>>>         As Rolf described in his mail, we do not reassign bugs in our
>>> workflow 

> Actually that is neither what I wrote nor what I'd propose ;-)

        Well, ok, what you wrote is that you once tried assign bugs,
but was suggested not to do that. If you want to propose that again,
then the same suggestion: please don't do that. The reasons were
given, and I reiterate over the matter below again.

> I have
> no issue with you assigning 2309 to yourself.  You seem to take good 
> care of it.

>> One benefit of reassigning the bug to myself is that I can click the "My 
>> Bug" button and list all my filed and self-assigned bugs, instead of 
>> remembering the bug number or relying on search.

> yes, very valid point.  It innocently illustrates the kind of workflow
> I'd be looking for (and that I use to a certain degree for myself).

        That's kind of bug workflow most projects use, be them
opensource or commercial, so no wonder. But such workflow works
especially well if as many as possible of the following are true:

1. Scope of project and functional areas are well defined.
2. There're dedicated developer for each area.
3. There's a manager who performs assignment.

        None of these are true for OE - the scope is too wide, areas
either to big (like, a distro), or too diversified (issues with
specific package or machine), there're no dedicated developers for
specific areas, and no manager who tells folks what to do.

        So, there's another workflow, of course not so organized, but
flexible and well fitting OE devel model, the reason why it was there
well before you or me came into active contribution.

> You
> have a link with a search function saved in bugzilla and when you click
> on it all the bugs that need your attention or that you are interested
> in are right there.

        Yes, you have saved searches, you have email preferences, you
have other cool things in Bugzilla, you learn to use them well in
framework on the existing workflow, before trying to revolutionize the
workflow itself.

> Gordon, maybe you want to save http://tinyurl.com/385p8b  You could also
> separate that out to only list cc bugs or whatever suits your needs. 
> Tweak it to your liking.

> Here are three searches that I use and deem useful for others

> http://tinyurl.com/2oypog (todays bugs: action: stay current)
> http://tinyurl.com/35l78g (bugs where compilation fails, action: verify)
> http://tinyurl.com/39gss8 (old with patches, action: inspect, commit)

        These links are nice, but won't help too much. Until people
start to make bug filters which *they* like and need, there always be
idea that something's lacking and that you need to put it upside down
trying to make it "work" for you.

-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com

Re: RFD: Bugzilla in general & bug triaging

[Rolf Leggewie]

Rolf Leggewie wrote:
> 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.

I have asked and been granted greater powers on bugzilla.  There are 
features which we don't use yet but which could aid in establishing a 
sane workflow while rendering unnecessary the current clutches and 
ad-hoc fixes.

Bugzilla will be upgraded soon and no structural changes will be made 
until that is completed.  But that leaves us some good time to think 
about how this should be enhanced.

Things I'd like to see
* confirmation flags
* better documentation of workflow status (need to define it first)
* assigning bugs (or if you prefer "Hey, please take a look")
* link to some bug searches like the ones I send about 5 minutes ago
   on the entry page
* entry page clean-up (why two search fields?)
* removal of dead stuff (ZaurusKernel, Familiar)

Please add to the list.  The most important point is the second.  That 
is what we should discuss.

Re: RFD: Bugzilla in general & bug triaging

[Marcin Juszkiewicz]

Dnia poniedziałek, 14 maja 2007, Rolf Leggewie napisał:

> Bugzilla will be upgraded soon and no structural changes will be made
> until that is completed.  But that leaves us some good time to think
> about how this should be enhanced.

> Please add to the list.  The most important point is the second.  That
> is what we should discuss.

MACHINE field would be useful - there are bugs specific to machine (kernel 
bug etc) which now have it in title or comment. 

Re: RFD: Bugzilla in general & bug triaging

[Junqian Gordon Xu]

Rolf Leggewie wrote:
> I have asked and been granted greater powers on bugzilla.  There are 
> features which we don't use yet but which could aid in establishing a 
> sane workflow while rendering unnecessary the current clutches and 
> ad-hoc fixes.
>
> Bugzilla will be upgraded soon and no structural changes will be made 
> until that is completed.  But that leaves us some good time to think 
> about how this should be enhanced.
>   
two quibbles about the recent change in bugtracker
1) aligning left wastes lot of space on the right of the screen. I think 
the old "centered" scheme looks better.
2) "the Words field cannot be empty. You have to enter at lease on word 
in your search criteria". This is inconvenient for me to just browser 
the bugs.

> Things I'd like to see
> * confirmation flags
> * better documentation of workflow status (need to define it first)
> * assigning bugs (or if you prefer "Hey, please take a look")
> * link to some bug searches like the ones I send about 5 minutes ago
>    on the entry page
> * entry page clean-up (why two search fields?)
>   

> * removal of dead stuff (ZaurusKernel, Familiar)
>   
better hide them (sort of a archive in case some people want to dig into 
those) than remove
> Please add to the list.  The most important point is the second.  That 
> is what we should discuss.
>   
I agree on the necessity of the second point. Please have a list of 
best-practice/workflow rules (whatever they are) and hide the additional 
irrelevant features. A clean and uncluttered interface is also desirable.

Gordon