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

Debian policy bug triage



It's remarkably hard to find BTS usertags documentation.

I spent several hours this afternoon going through every open bug against
debian-policy and taking a first pass at classification vaguely according
to the new Policy process that Manoj proposed at DebConf.  The tagging
should at this point be considered my personal opinion and is very rough,
but it should give an idea of what the current backlog looks like and give
us a bit of practical experience with the new policy.

You can see the classified bug list at:

http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=debian-policy&users=rra@debian.org&ordering=policy&pend-exc=done

I broke bugs into three categories: Normative, Informative, and Packaging,
where the latter is a catch-all for things that affect the machinery of
the debian-policy package and its documents and not the text of the
policies themselves.  We may want to consider breaking virtual package and
menu policy bugs into separate categories; right now, they're normative.

Within the normative and informative categories, I further broke things
into the following stages:

    Issue Raised
    Under Discussion
    Change Proposed
    Wording Proposed
    Wording Accepted
    Rejected

This is all very rough.  Vaguely, Issue Raised means that someone reported
a problem or requested a change, but there's been no discussion yet.
Under Discussion means there's been some discussion, but it doesn't seem
to have converged on a concrete change proposal (or there's a lot of
opposition to the one proposed, or one was proposed but there's been no
real consensus around it).  Change Proposed means that someone has put
forward a concrete description of what should change, but there's no patch
against Policy that could be applied as-is.  Wording Proposed means that
someone has a proposed patch (but it's possible not everyone agrees with
it).  Wording Accepted means that one of the Policy maintainers has
committed the change and considers it ready for the next release.
Finally, Rejected means that one of the Policy maintainers has rejected
the change proposal; at this point, there's only one bug in that category
and I put it there because I think it's too general and duplicates other
bugs that are more specific.

This should be vaguely recognizable as similar to the stages of a policy
proposal in Manoj's proposal, although we'll need to tweak it to implement
that proposal entirely.

There are two other usertags I added, kind of as an experiment, which
aren't reflected in the categorization.  I tagged quite a few bugs
"dubious", meaning that in my opinion it's unlikely that the bug is going
to converge on something we can accept into Policy any time soon.  This
may be because a lot of people think it's a bad idea, because it will
require a lot of other work to happen first, because Debian just isn't
ready for the idea yet, or various other things.  It doesn't mean that the
idea is a bad one, inherently.

I also tagged "dpkg" bugs that are more about documentation of how dpkg
works than about other areas of Policy.  These touch areas that *might* be
worth breaking out into a separate dpkg manual instead of including in
Policy, depending on what we decide about how much of dpkg's behavior
should be in Policy proper.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>



Reply to: