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

Re: Bug#97671: xutils: why is rstart.real a conffile?

reassign 97671 tech-ctte

> Anthony has offered no basis for his latest manipulation of my bug list
> aside from the derisive remark in the Subject:.
> I am requesting the Technical Committee's resolution of this dispute
> under Section 6.1 of the Constitution.  Both parties stipulate that the
> bug in question is not release critical.  Therefore, this bug does not
> fall within the Release Manager's jurisdiction, and I am not aware of
> any other grounds upon which the package maintainer's discretion can be
> overridden on issues like this.

>   We therefore recommend that
>   * The bug system administrators and/or the project leader or some
>     other delegates appointed by the project leader decide on the
>     proper use of the bug system features.

I believe I speak for everyone on owner@bugs.debian.org in saying that
the bug system administrators do not have an opinion on this matter,
or other policy matters for use of the BTS in general.

Obviously, I, personally, do, and if you want to punt to the release
manager, you can make use of that. It's not clear that's particularly
appropriate, since the question is surely as much "was this the right
thing to do" as "does Anthony have any right to do it". My opinion on
the use of severities and the consideration of bugs as release-critical
or not is as follows:

	(1) All bugs have an objectively defined severity, which can be
	    determined by reference to the bug submission guidelines,
	    policy, and similar resources. The principle is that bugs
	    that have a similar effect should have a similar severity.

	    Unfortunately, this "objective reality" is somewhat poorly
	    documented, and can be readily misinterpreted; eg the policy
	    for woody was that as long as the package had ever been
	    built on an architecture, "doesn't autobuild" bugs were
	    not RC, whereas this is not the case for sarge; without any
	    documentation changing. The only particularly effective way of
	    finding this out is to ask on debian-devel@lists.debian.org.

	(2) By default, the release manager will consider all bugs that
	    have a severity of serious, grave or critical to be
	    show-stoppers: either on a per-package basis, or for the
	    entire release. This default can and often will be overriden
	    by the subjective judgement of the release manager: either
	    to say that some less severe bugs will also be considered
	    show-stoppers, or that some serious, grave or critical bugs
	    will not be considered show-stoppers.

	(3) As such, the issue in question should remain filed as
	    "serious" (as it is a clear violation of the FHS), and
	    should not have been considered a show-stopper bug for
	    woody's release (based on the release manager's judgement,
	    with the support of the package maintainer).

At this point, afaics, the tech-ctte may wish to do any of:

	* Decide that use of severities in the BTS is a technical issue,
	  and determine a policy for this, and apply that policy to the
	  bug in question.

	* Decide on what the appropriate resolution of the matter for
	  this bug is, without reaching a conclusion in the general case,
	  and implement it.

	* If I'm the appropriate delegate for setting the policy for
	  use of severities at issue here, determine if the policy as
	  I've presented has been followed for this bug.

	* Punt to the DPL under 5.1(4) ("Make any decision for whom noone
	  else has responsibility").

For your interest, I'm now with it enough to comment on some of the
alternatives that've been discussed, that I've avoided being drawn
on previously.

Branden suggested:

] The Release Manager can strip the "release-critical" tag off of any bug
] he wants.  This is how things have *always* worked in reality.  If a bug
] is truly a showstopper for a release, we don't release with it.  We
] either wait, fix the bug, or drop the package.
] I honestly believe this mechanism would head off most of these catfights
] at the pass.  Proper usage of "must" vs. "should" in the Policy manual?
] Immaterial.  Mass-filing of serious bugs as public service or
] masturbatory frenzy?  Immaterial.  Release-critical?  Release Manager's
] call, period (unless someone bothers to appeal to the Technical
] Committee -- not a process that is likely to get one a speedy remedy :).

This doesn't work -- we've already tried it with the "important" severity.
The result is that all these things that Branden claims don't matter
really end up not mattering, but that stops them helping too -- people
file their bugs at whatever severity they think is appropriate and
frequently get it wrong. The release manager then spends an hour or two
*every single day* correcting the errors. It's frustrating, horribly time
consuming, and a thoroughly ineffective use of time. It also seems likely
to increase the risk of people marking a bug with too low a severity,
and thus increasing the chance an unacceptably buggy package will be
released without the release manager being able to do anything about it
(whether that be encourage other people to fix it, or just stop the
package from being released).

What we do now is, effectively, add an additional tag to release-critical
bugs that aren't going to be treated as such: for potato it was an
[IGNORE] in the release critical bug list, for woody it should've been
the same except some scripts were broken, and for sarge it will probably
a real "ignore" or "allow-release" tag. The benefit of doing it this
way rather than dropping the severity is that it makes it easy for the
release manager to keep track of the bugs he needs to be responsible for;
even the ones he's decided to allow remain unfixed.

( Hrm, an "allow-release" tag might be a better way of doing things than )
( checking there aren't more bugs in unstable than there are in testing. )
          o    (thought bubble, no response nor even comprehension required)

I don't believe there's any real value in changing the BTS to treat
"ignored" bugs specially in a way that would be useful for Branden's
triage; although generalising it to allow the maintainer to arbitrarily
re-prioritise bugs would probably be a win -- the idea being you could use
a different URL and get the bugs in the order in which the maintainer will
be focussing on them. (Which is to say, I won't be writing or applying
any patches for the former, although someone else on owner@bugs might, but
I'd probably be interested in seeing patches or good ideas for the latter)

Assuming the "pending" tag on Bug#143825 is for triage (since it hasn't
been closed in any of the uploads since the tag was applied) it's probably
better to add [lowpri] to the bug's subject, then use


to get the sanitized page. An inaccurate "pending" tag probably makes it
less likely for people to provide patches, etc, which would presumably
be a loss. Apologies if the assumption's incorrect, of course.


Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

 ``If you don't do it now, you'll be one year older when you do.''

Reply to: