Package: release.debian.org
Severity: normal
User: release.debian.org@packages.debian.org
Usertags: britney

Hello,

I have been wondering why hugin 2016.2.0~rc1+dfsg-2 (urgency=low) will
be considered for testing migration after only 5 days and I think I found
the reason.

Testing has 2016.0.0+dfsg-1, which was followed by
[2016-07-16] 2016.2.0~rc1+dfsg-2 in unstable (low)
[2016-07-11] 2016.2.0~rc1+dfsg-1 in experimental (low)
[2016-06-04] 2016.2.0~beta1+dfsg-1 in experimental (medium)

britney seems to have remembered that 2016.2.0~beta1+dfsg-1 had medium
urgency and chose to consider this urgency for sid->testing migration.

I think that is a bug, especially as dch uses medium by default for
uploads to experimental.

cu Andreas

(dch uses medium by default for uploads to /all/ suites.)

It's a feature, specifically because the information that britney has
about urgencies (via dak) is of the form:

dm-writeboost 2.2.1-1 medium
libapache-mod-auth-kerb 5.4-2.3 medium

i.e. there's no mention of suite. I don't know whether anything other
than britney uses the data; if not then I guess it would be a simple dak
patch to add the suite data if desired.

Regards,

Adam

Closing as not a bug.

Cheers,
Julien

Does it remember or does it parse the changelog and use the highest
priority since the version in testing? The hugin changelog contains
the urgency=medium entry so this seems a valid urgency to use.

MfG
	Goswin

Does it remember or does it parse the changelog and use the highest
priority since the version in testing? The hugin changelog contains
the urgency=medium entry so this seems a valid urgency to use.

MfG
	Goswin

[...]
[...]

Hello,

Ok, I will accept this, seems there is a judgement call involved.

It seemed crystal clear to me that testing propagation using the
priority of uploads to experimental was a bug. Simply because uploads to
experimental *never* are subject to testing propagation, testing
propagation checking only starts with the sid upload.

I will try to get dch changed to use low priority for experimental
uploads.

cu Andreas

[...]
[...]

britney knows nothing about changelogs. The input is a strictly
chronological (in terms of when dak accepted the package) list of source
package name, version and urgency tuples for all uploads to the main
archive.

Regards,

Adam

Adam D. Barratt:

For the people interested, the input data is available from [1].  If you
want it changed, it will need to be fixed in dak (producer) and Britney
(as the consumer).
  From my PoV: Patches welcome and will gladly help people, who are
interested in it.  I don't expect to have time to fix it myself any time
soon - but as I said; I will gladly help people getting started.

Thanks,
~Niels

[1] https://ftp-master.debian.org/britney/urgencies/

Control: reopen -1
Control: clone -1 -2
Control: reassign -2 ftp.debian.org
Control: retitle -2 [dak] Include suite information in UrgencyLog
Control: block -1 by -2

I think that's the proper fix for this and I would prefer to avoid
adding even more special-casing code to dch.

Cheers,

Control: block -1 by 831699
Control: tag -1 + moreinfo
Control: severity -1 wishlist

If dak should change its output, it would need:

1. Documentation what should be written. Uploads can end up in multiple
suites and suites have aliases and so on.
2. The consumers must not break once the output changes (ignoring the
additional data is sufficient).

I think (1) is missing. And I don't know about (2) as this isn't a JSON
document or similar where one would expect consumers to just ignore
additional fields.

Ansgar