Re: Bug#97671: xutils: why is rstart.real a conffile?
(I've taken everything except -project off the CC.)
Branden Robinson writes ("Re: Bug#97671: xutils: why is rstart.real a conffile?"):
...
> How about having only *some* of the bug severities be deliberately
> objective? How about leaving the others to the maintainer's discretion?
>
> I propose something like this:
>
> critical
> grave
> -------------- objectivity threshold
> serious
> -------------- "RCness" threshold
> important
> normal
> minor
> wishlist
I agree completely. This is the way I personally thought it was
supposed to work.
Who do you think determines RCness ? It seems to me that it's the
release manager, ultimately, although they probably won't want to see
each bug individually.
The result would be that maintainers and submitters would cooperate to
set bug severities, but if they disagree then the relevant authority
gets to decide: in the ultimate case, the TC decides whether something
meets the objective criteria for critical or grave (although it would
probably be easier to fix the damn bug), and the release manager
decides whether something is RC. (And of course the release manager
can decide spontaneously to upgrade/downgrade bugs across the RCness
threshold.)
> Furthermore, I suggest decoupling policy violations from bug severities.
I think this is essential.
You say ...
> * Manoj has, if I recall correctively, derisively complained about usage
> of the Debian BTS as a personal to-do list for package maintainers.
> But that's what, in part, I think the BTS *should* be. Let the
> package maintainer use it to triage problems, focus his energies, and
> drop hints to other developers about what he most needs help with.
I agree wholeheartedly with your sentiments on this question.
It might be worth having the policy manual state what kind of problems
were usually bugs of what severity - but of course ultimately the
criteria for RCness of bugs have to come by decree from the RM, and
not go through the policy process.
> [The next point is a long one.]
> * The current imperfection of the Debian Policy Manual causes us to lend
> more gravity to certain bugs, as a result of "a severe violation of
> Debian policy [...]
>
> Please, let's isolate the damage from Policy flamewars. [...]
Again, I agree.
> On Tue, Nov 12, 2002 at 02:28:34AM +1000, Anthony Towns wrote:
> > 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.
This seems to be quite strange to me. Either the bug is release
critical (ie, it would be better not to release until the bug is
fixed), in which case we should not ignore it, or the bug is not
release critical (ie, it would be better to release despite the bug),
in which case why do we want to have it down as release critical ?
> I'm not wedded to the name or semantics of a "release-critical" tag.
I think there's no need for this. Your proposed classification of
severities is quite clear: it seems to me unlikely that a bug
which met the objective criteria for grave or critical would not be
release-critical.
And clearly, release critical bugs do objectively deserve more
attention from maintainers. One may complain that this is somehow
interfering with the maintainer's own setting of their own priorities
for their work, but I think it's reasonable for us all to expect that
a maintainer with a release critical bug will at least leave the job
at the top of their todo list, even if they don't manage to actually
get round to it and do something else first.
Ian.
Reply to: