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,

I have just read this bug report (which affects a situation I care
about) and I don't quite understand.

Adam writes:

What I don't understand is why it is not correct for britney to use
the urgency of the actual version it is considering migrating, rather
than some other version.

Or is that what it does ?  I get the impression from what was written
in this bug that it does something more complicated, but that may be a
misunderstanding.

(Sadly no-one copied the actual database information from the original
case into the bug log, so it is not now possible to make sense of what
is written early in the bug.)

I assume that the urgency information reported by dak to britney is
that from the .changes file.  Is that right ?

I experimented and dpkg-genchanges -vX provides a Changes file with
the maximum urgency of any of the included changelog stanzas.  So if
you say

   blah (2.0-3) unstable; urgency=low
   blah (2.0-2) experimental; urgency=high
   blah (2.0-1) experimental; urgency=medium
   blah (1.0-1) unstable; urgency=whatever

and you (correctly) do your upload of 2.0-3 to unstable with -v1.0-1,
the .changes file will say `high', even though from the pov of users
of unstable and testing, it ought to be `low'.

I think that the right fix for this bug is as follows:

 dpkg-genchanges should not consider as higher-urgency any changelog
 entries for "unrelated" suites in previous changelog entries that are
 being included, as a reason to bump the urgency for *this* .changes.
 (An "unrelated" suite is perhaps one whose ^\w+ is not the same as
 that of the final, target, suite.)

 Ie in the examle above, dpkg-genchanges -v1.0-1 should say
 Urgency: medium.

 dak should use the Urgency from the .changes file and report that in
 its /britney/urgencies output.  (It may already do this.)

 britney should use the urgency of the particular package, only.
 (It may already do this.)

 An in-archive copy should not be done to move a package into testing,
 since doing so does not afford anyone the opportunity to specify the
 proper urgency.  (I don't think we do this.)

What do others think ?

Ian.

and then, before 1.0-2 has migrated, upload 1.0-3 with default urgency,
what should happen?

Currently the result is that the "high" from 1.0-2 is used, and 1.0-3
(including the RC bug fix) migrates two days later. If only 1.0-3's
urgency is considered, the package spends at least another five days in
unstable before the RC fix reaches testing.

Regards,

Adam

Adam D. Barratt writes ("Bug#831699: release.debian.org: urgency is sticky across dists - low urgency on sid upload ignored"):

Oh, I see.  Sorry, I was being dim.

This seems to suggest that britney ought to do max of all the
urgencies of all the uploads to unstable after (or with higher
version than) the version in testing.  Which requires the info from
dak discussed earlier in this bug log.

But I think it *also* requires the change to dpkg-genchanges, because
otherwise the urgency of uploads to unstable can be artificially
inflated there too.

I guess it is too much to hope that britney has access to the
changelog ?  If it did it could do its own calculation, which would be
max of the changelog entries *mentioning unstable* between the version
in testing and the version being considered.

Regards,
Ian.

Ian Jackson:

Britney does not have access to the changelog directly and it sounds too
resource intensive to do directly in britney.


There are three alternatives to solving this bug AFAICT:

 1) dak (or a replacement service) excludes urgency entries irrelevant
    for britney, so those entries are never included in the data set.

 2) dak (or a replacement service) provides additional information for
    each entry such that britney can determine whether an entry is
    relevant for computing the effective urgency.

 3) dak (or a replacement service) computes the effective urgency
    directly and we disable the "urgency merging" in britney.

Then orthogonal to these proposals, there is a point about whether the
entries in the data files should be computed from .changes files or from
changelog files.  It is certainly relevant, but that is a problem that
should be solved in the service providing the data and not britney.

Also, regardless of which of these solutions we go with, the code
changes to britney will probably be very trivial (if necessary at all).
Until a better data source or improved data file appears, there is
nothing we can do on the britney side to resolve this.

Hopefully that clarifies the situation.

Thanks,
~Niels

Why should it be low?  What else would the urgency=high in 2.0-2 mean?

Cheers,
Julien

Julien Cristau writes ("Bug#831699: release.debian.org: urgency is sticky across dists - low urgency on sid upload ignored"):

Often, an upload to experimental has quite severe bugs.  I think the
`urgency=high' for 2.0-2 means `if you are running 2.0-1 you *really*
want this update'.  I think the urgency information can be displayed
in advance of the update by apt, so you can see whether you want to be
bothered.  It's also helpful as a very brief summary for humans.

I doubt that many people use `experimental; urgency=high' to mean
`fixes an RC bug present in sid'.  That would be an unusual way to
carry on.  In those cases it is easy enough to manually make sure that
the upload to sid says `unstable; urgency=high'.

Does that make sense ?

Ian.

Niels Thykier writes ("Bug#831699: release.debian.org: urgency is sticky across dists - low urgency on sid upload ignored"):

I suspected that would be the case.

If the information is provided for the benefit of britney that seems
an obvious solution.  AIUI someone with a suitable dak hat is maybe
looking at this now...

Indeed so.  That's not really a service, it's dpkg-dev.  If we agree
on the desired semantics I will file a bug against dpkg-dev.  In
practice we might want to get that update into a stable update for
people who are doing their development on stable.

Thanks, yes, I feel less confused.

Ian.