Bug#97671: xutils: why is rstart.real a conffile?
reassign 97671 tech-ctte
thanks
> 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
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
http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=xutils&exclude=subj:[lowpri]
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.
Cheers,
aj
--
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: