All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Sokolovsky <pmiscml@gmail.com>
To: Rolf Leggewie <no2spam@nospam.arcornews.de>
Cc: openembedded-devel@lists.openembedded.org
Subject: Re: RFD: Bugzilla in general & bug triaging
Date: Mon, 14 May 2007 14:26:44 +0300	[thread overview]
Message-ID: <1848419262.20070514142644@gmail.com> (raw)
In-Reply-To: <f29cu8$lol$1@sea.gmane.org>

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




  reply	other threads:[~2007-05-14 11:26 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 ` RFD: Bugzilla in general & bug triaging Rolf Leggewie
2007-05-13 15:02   ` 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 [this message]
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=1848419262.20070514142644@gmail.com \
    --to=pmiscml@gmail.com \
    --cc=no2spam@nospam.arcornews.de \
    --cc=openembedded-devel@lists.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.