Fwd: REST APIs, and Tags

[Frédéric Buclin]

Le 12. 02. 10 15:52, Benjamin Smedberg a écrit :
> reports, I don't disagree that there are ways to track incoming bugs. I
> do think that it would be good to put some energy into making the triage
> process easier and more explicit for those people who are tasked with
> doing it.

I agree. Maybe this could be done by sharing some well built saved
searches. For instance, I have a saved search which lists all bugs
younger than 2 days in components I'm interested in. That plus
automatically getting bugmail for newly filed bugs, I never miss one. :)


> The hardest part by far is selecting a component in which to file the
> bug.

As discussed on IRC, the guided form could list only a subset of fake
components, and the backend code (aka post_bug.cgi) would then match
them with real existing components. I guess it doesn't really matter if
a bug isn't filed in the right subcomponent of Layout:* or DOM:* or
Widget:*, and it would be easy for the module owner or peer to set the
exact component the bug belongs to.

> what should these people do? Simply moving the bug to the correct
> component may not be enough

It would be better than nothing, as long as module owners and peers
watch their own components, you would notice the newcomer.


> At the end of this process is it clear to the original filer what has
> happened?

I'm not really worried about whether the process is clear to the
reporter or not. If there are missing information, such as STR, we will
let him know. What is important is that its status is clear to
developers who may potentially fix the bug.


> I would like a way to do that for every bug... it's almost as if every
> bug starts out with a triage?initial flag, and after it's gone through
> the process it ends up as triage-done, perhaps with trips through
> triage-ready or triage-needtestcase or whatever. Which is perhaps what
> we should do! I don't know yet.

Personally, we use the "qawanted" keyword to mean "this bug needs some
attention", either because it doesn't look valid, or because it needs
some more investigation before confirming it or marking it as blocker.

Here, I use the same trick as for new bugs. I watch the default QA
contact of components I'm interested in, and in the email preferences, I
only checked "email me when a new bug is filed" and "email me when a
keyword is added or removed" for the QA contact. We don't use many
keywords for Bugzilla, but in your case you could let Thunderbird triage
incoming bugmail and only keep relevant keywords, thanks to the
X-Bugzilla-Keywords header of bugmail. Instead of a flag, you could use
the "needs-triage" keyword. When you see this keyword in a component you
own, you know this bug is for you. :) And if you didn't pay immediate
attention to them, a saved search "keyword=needs-triage" used as an Atom
field will be a good reminder.


> Because they are there, and especially because they confuse new users
> who try to use those fields in the advanced bug search form.

FYI, we plan to make these two fields optional in Bugzilla 3.8, because
it's a pain even for us. :) Meanwhile, advanced users know they should
just ignore these two fields in their queries (this is a workaround for
now).


> I cannot accept nominations for 'this might be important, please decide
> whether it blocks alpha1/beta1/final'.

Couldn't your team use the needs-triage keyword together with a comment
explaining why the keyword is set? You would get something like:

Some Triager <some.triager at company.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           keywords|                            |needs-triage

--- Comment #7 from Some Triager <some.triager at company.com> 2010-02-11
17:03:28 CET ---
bsmedberd, do you think it should block beta1?


> search of "everything which directly or indirectly blocks bug 478976 and
> is assigned to nobody@".

Yes, you are right, you cannot for indirect blockers. But you can for
direct blockers, which is a start. But I think we should implement this;
I hope this is not too hard. Bug 487864 asks dependencies for
QuickSearch. I will check if we have a separate bug for indirect
dependencies specifically.


> And the TM field feels useless because it doesn't have any of the
> "lorentz submilestones" in it, and people don't want to have a TM field
> with 150 entries for each subproject that might want to track things.

This will become easier once bug 77193 is fixed.


> And FWIW, the correct component for these bugs is many different things,
> because this is a multi-disciplinary project!

Haha, yes, I agree. :)


LpSolit