[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Disputes between developers - draft guidelines



On Thu, Oct 17, 2002 at 12:38:13AM +0100, Ian Jackson wrote:
> I'm not sure the issue of severities needs dealing with explicitly
> here.

It needs to be dealt with somewhere, and the Technical Committee has
explicitly punted on resolving such disputes.

If we don't discuss the issue in this document, then where shall we?

> In fact, your suggested changes seem to spill over from dispute
> resolution into general rules for the use of the BTS.  I don't want to
> address that here.

Well, you address the specifics of when and when not to reopen a closed
bug.  I see that as no less specific an issue.

> In particular, I note that you seem to be grinding your axe about the
> issue from Bug#97671.

No, you do me a disservice.  That was not Debian's first severity war
and it probably won't be the last.

> Surely you must agree that that axe is not best ground in this
> document ?

I would appreciate it if you would not imply that I am motivated by a
personal animus here.  To do so conflates interpersonal disputes with
technical or procedural disagreements.

> Why don't we wait and see what the BTS admins say; it seems to me that
> it's their decision (as it's a process question and they're the
> appropriate delegates).

I would not presume to trump the authority of the BTS admins, to the
extent that they choose to exercise it.  However, they probably wouldn't
like to make decisions in a vacuum, so I have offered my perspectives on
an issue that has provoked disputes in the past, so as to help them
enrich the context within which they make those decisions.  I trust you
don't feel that the BTS administrators are not the only ones who should
opine about how the BTS should work; at least, the second paragraph of
section 2 of your draft strongly suggests the converse.

> But, in any case, I think I largely disagree with you about the
> specifics.  That's why I'm CCing this mail to owner@bugs.debian.org
> and debian-project.

I'm all for a public, thorough, and calm discussion of the issue.

> I disapprove of the `wontfix' tag, in principle.

I'm not sure discussion of this draft is the best forum in which to
object to an already deployed and used aspect of the Debian BTS, but I
suppose a case can be made for it.

In other words, if my raising the issue of bug severities is beyond the
scope of this discussion, the surely so too is the issue of the
"wontfix" tag.

> > +* A bug was reported; both the maintainer and the submitter agree that
> > +it's a defect, but disagree in their interpretations of the
> > +definitions of bug severities.  The bug should be left at the severity
> > +determined by the package maintainer, but the report should not be
> > +closed.  The parties should discuss their disagreement within the bug
> > +report until some mutual agreement can be reached.  Note that the
> > +Release Manager may regard a bug as "release-critical" (or not)
> > +irrespective of its severity in the BTS.
> 
> We can't put anything about this in until the BTS admins have decided
> who is responsible for bug report severities, and this is where you're
> prejudging #97671.

I'm not "prejudging" it at all.  The Technical Committee stated in what
I'll call their "refusal to grant cert" on #97671 that they felt it was
beyond their purview.

At some point, someone needs to take some responsibility for the issue
of arguments over bug severities.  Under our Constitution, there are a
few possibilities:

   1. The Developers, by way of General Resolution or an election;
   2. The Project Leader;
   3. The Technical Committee and/or its Chairman;
   4. The individual Developer working on a particular task;
   5. Delegates appointed by the Project Leader for specific tasks.
   6. The Project Secretary;

I suggest that:

1. is far too heavyweight a process for resolving such disputes;
2. grants too much power to the DPL, and probably pesters him or her
   with issues that are on balance too minor to trouble him or her with;
3. mooted;
4. is the best place in which to vest this power;
5. is the next best place in which to vest this power, however at least
   some of the current BTS admins seem to not want the job, shall we
   have a new group of delegates whose job is solely to adjudicate bug
   wars? -- that might perhaps be exaggerating the scope of the problem,
   and the number of actual disputes;
6. risks politicizing the Project Secretary's position by involving him
   or her in possibly acrimonious disputes; still, if folks feel this
   isn't a plausible risk, I'd say it's the third best choice.

>   * A bug was reported; everyone agrees that it's a defect, but
>   disagree what severity should be assigned.  The bug should be left
>   open at the severity determined by the package maintainer or release
>   manager.  The parties should discuss their disagreement within the
>   bug report until some mutual agreement can be reached.

Well, if I'm "prejudging" #97671 with my statement, surely this one
prejudges it as well, just in the opposite direction.

> > +Under no other circumstances should you get into a back-and-forth with
> > +a package maintainer, changing the state of a bug in the BTS.  If
> > +the maintainer of the package against which a bug is filed makes a
> > +change to that bug report which you disagree, you should *discuss* the
> > +matter with them but *not* immediately undo their action in the BTS,
> > +except to reopen the bug to stop it getting lost.  If you are unable
> > +to reach a conclusion through constructive discussion, you should ask
> > +for outside help with resolving your dispute, as outlined above.
> 
> I disagree with putting this here in that way.  I don't want to
> document in this disputes advice file what the policy is about
> ownership of BTS state.  The BTS admins should do that.

Your disagreement confuses me; this language is almost entirely yours.
All I did was cast the net wider from "open vs. closed" to other
characteristics of a bug report.  This seems to me only a difference in
degree, not in kind.

At any rate, it will indeed be constructive to hear what the current BTS
admins have to say about these issues.

-- 
G. Branden Robinson                |       The last Christian died on the
Debian GNU/Linux                   |       cross.
branden@debian.org                 |       -- Friedrich Nietzsche
http://people.debian.org/~branden/ |

Attachment: pgpV3_bunbYFW.pgp
Description: PGP signature


Reply to: