Hi,

mentions only high, medum and low urgency values. Britney also
supports critical and emergency. These should be documented as well.

Something like:

- The delays are currently 2, 5 or 10 days, depending on the urgency (high, medium or low).
+ The delays are currently 0, 2, 5 or 10 days, depending on the urgency: critical/emergency, high, medium or low respectively. Where emergency is simply an alias for critical.

Thanks,
--Daniel

control: tags -1 + wontfix
thanks

thanks for filing this bug report, even with a patch, basically!

I'm sorry I still closing this as documenting those severities has no
practical benefit, and in fact might confuse people thinking using those
severities would be encouraged or useful, which is both not the case.

Hi Holger,

That's fine, but in that case this fact should be documented instead no?
Right now there's confusion across the docs what criticality levels are
available. Britney.conf and d-policy mention critical/emergency but nothing
else even acknowledges they exist which is just confusing.

Thanks,
--Daniel

I believe Debian policy should be changed then and not mention a severity
which is not used in practice.

Easier said than done. I see debian-policy@d.o is already CCed on this bug
so, opinions?

Doesn't policy document the reality that these urgency values are in fact
usable? Do you not agree that britney does in fact support these? If I go
ahead and upload a package with urgency=critical will this be REJECTed by
ftp-master?

If not they exist so why shouldn't they be documented in devref?

control: reopen -1
control: reassign -1 debian-policy
control: retitle -1 please stop mentioning urgency=critical
thanks

debian-policy@ has been cc: on this bug because developers-reference and
debian-policy share the same mailinglist.

It will not be rejected but setting the urgency has little practical
relevance these days. You could also upload with urgency=low or urgency=high
and that would be the same in practice.

- because it will make people use them
- because people always think their issues are critical
- because using them will not have an effect
- because people will then complain that they have no effect
- because all of this is a waste of someones time.

Theses urgency values are historical. Their current behaviour is not defined.
A long time ago in a distro not far away, packages for non-i386 were built
manually by porters that used the urgency to decide which packages to build
first.
I do not think this is still the case, except that the security queue is build
first by the autobuilders.

Cheers,

Bill Allombert <ballombe@debian.org> writes:

The current definition of critical and emergency in Debian Policy is in a
footnote and says:

.. [#]
   Other urgency values are supported with configuration changes in the
   archive software but are not used in Debian. The urgency affects how
   quickly a package will be considered for inclusion into the
   ``testing`` distribution and gives an indication of the importance of
   any fixes included in the upload. ``Emergency`` and ``critical`` are
   treated as synonymous.

So far as I can tell from etc/britney.conf at
salsa.debian.org/release-team/britney2, this is correct: emergency and
critical are synonymous, and are not the same thing as high:

# priorities and delays
MINDAYS_LOW       = 10
MINDAYS_MEDIUM    = 5
MINDAYS_HIGH      = 2
MINDAYS_CRITICAL  = 0
MINDAYS_EMERGENCY = 0

Holger, did I get something wrong here? Is there some reason why critical
and emergency do not have a different effect from high that I'm missing?

I think it would be useful to move some of this content out of a footnote
in Policy to somewhere more accessible, but at least at first glance I
don't think there's anything inaccurate in Policy.

I dont think so.

I dunno. I'd believe it's like that because someone implemented it like this,
thinking in future further levels would be useful, but then it turned out, that
we dont need that many levels. But that's just my guess.

agreed.

& thanks for confirming!

Holger Levsen <holger@layer-acht.org> writes:

Okay, great. I'll keep this bug on the Policy side to move the wording
around a bit so that it's not hidden in a footnote. Has this made you
change your mind about documenting critical in developers-reference? (In
other words, do you want a clone of it back for that?)

sure, if you think that useful, please do!

to be clear: I've just lost context & am lazy as well as trusting your
judgement! & Thanks.