On 2008-02-25, 20:05 GMT, Jon Stanley wrote:
> The ASSIGNED state is a state that has a new meaning - it used
> to mean that the bug was actually assigned to a person.
> Instead, it now means that the bug is capable of being worked
> on by a maintainer - i.e. the triage team believes that this is
> a complete, actionable bug - i.e. with a stack trace for
> a crasher, various log files for other components, complete AVC
> message for SELinux stuff, etc.
a) I totally agree not to require retooling — Red Hat Bugzilla
maintainers are totally buzzy with upgrading to Bugzilla 3.2
(yay!!!) but Red Hat BZ is so heavily modified that this is
crazy amount of work.
b) ASSIGNED state is really ambiguous, but its definition is not
what is important about it (and believe me, as a former
lawyer, I like heated discussions about definitions ;-)). To
make further discussion more understandable I will venture
with these definitions of ASSIGNED, but I repeat this is not
what's important, the further discussion is.
So, ASSIGNED could mean:
1) The bug has been triaged, and the triager believe that
there is nothing she can do about it and further decisions
about the bug have to be done by developers. (Further
discussion what this actually means would be endless, so
I will skip it here).
2) The bug has been put to the sack of particular developer(s)
and he will (sometime) work on it.
3) The bug is actively being worked on by a particular
developer(s).
My point is that in this discussion many people seem to confuse
2) and 3). I don't want to indulge here in the discussion whether
there should be a special state of the bug to distinguish between
these two, because I believe that THIS IS TOTALLY OUTSIDE OF THE
WORK OF BUG TRIAGERS. Our only job is to get bug to the state 1)
(or 2) at the best -- see below), but we have no business to tell
developers what they should do.
It is very important IMHO to actively understand that we are here
just as servants of developers (using so strong words to make an
emphasis), the only purpose of our work is that davej, ajax et
al. don't have to deal with stupid stuff like obsolete NEEDINFOs,
but we are certainly not in the position to decide what davej
should do and what are his priorities (actually we may end up
setting the priority/severity field sometime, but currently it is
useless and impossible, and it is not what I mean here).
Less important but still IMHO interesting and relevant to our
discussion is the distinction between 1) and 2). For me
personally, while working on my Xorg bugs, this distinction is
not particularly relevant (and bugs I triage should end in the
state 2)), because I know from discussion with developers what
kind of bugs each of them expects, and of course whenever in
doubts what to do with a particular bug I could ask on IRC.
Which leads me to the point, that for bug triager to be excellent
it is crucially important to be part of the team of developers
for the particular set of components.
Well, let me back off a little bit. We are here talking probably
about two types of bug triaging. It is certainly useful when
somebody just runs through kernel bugs and deals with old
NEEDINFOs, never to be seen again.
But there is a higher position waiting for each of us -- to be
part of the team who actually actively develops Fedora, even
though you cannot write a line in C if it would save your life.
And that's where it begins to be fun and really interesting.
Does it make a sense?
Matej
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
