Ian Jackson: > Adam D. Barratt writes ("Bug#831699: release.debian.org: urgency is sticky > across dists - low urgency on sid upload ignored"): >> On 2018-06-20 15:55, Ian Jackson wrote: >>> 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. >> >> If you upload 1.0-2 containing an RC bug fix, so with "Urgency: high" >> and then, before 1.0-2 has migrated, upload 1.0-3 with default urgency, >> what should happen? > > [...] > > 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. >
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