On 11261 March 1977, Margarita Manterola wrote:
> Implement a new file, that works similarly to the hints file, but that
> causes uploads to unstable for selected packages to be rejected. Thus,
> if a maintainer uploads, it won't get through so that it won't get in
> the way of the transition.
> Ganneff volunteered to prepare the patch after the format of the file is
> decided.
The implementation of this is pretty simple, especially when we dont
take Neils idea of a delayed queue and just do the reject. :)
Diverting it to experimental is also not very nice (IMO), as you
a.) have to check if experimental doesnt already have a later version
b.) need to cleanup experimental later
c.) need to upload again anyway to go into unstable when the transition
is done
d.) get files into experimental where the changelog (and .changes) talks
about Distribution: unstable, something that might surprise users,
experimental autobuilders and possibly others
A REJECT is simple, directly tells the maintainer whats going on, and
also leaves the option for them to do a seperate upload to experimental,
in case they want it.
Now, for the file - the format would be YAML, as its easy to parse from
about every language and still easy to edit with $EDITOR. I propose the
following:
--8<------------------------schnipp------------------------->8---
apt_update:
reason: "Apt wants to go to testing"
source: apt
vto: 0.7.9
vtn: 0.7.10
packages:
- apt
- synaptic
- cron-apt
- debtags
- feta
- apticron
foo_broken:
reason: "Something else"
source: foo
vto: 1.2-3
vtn: 1.3-1
packages:
- foo
- baz
- bar
--8<------------------------schnapp------------------------->8---
This would mean we have two transitions, one for apt, one for foo.
apt_update/foo_broken would be an informational tag for the reject
message, together with the reason. All packages named here are source
packages, of course. vto means "version testing old", vtn "version testing
new". And "packages" is simply a list of all packages affected by this
transitions that should get rejected, *including* the transition target itself.
Listing them all leaves the release team with a simple way to allow
uploads of packages involved in a transition, in case its needed, by
simple not listing such exception.
vtn is there so that the file can be cleaned up automagically - as soon
as the version in testing is the same or later as vtn no reject is done
anymore.
We *could* make it more complicated by adding versions to the package
entries in "packages:", but I currently don't see that that is
needed. If it will ever be we can adapt it in the future.
And now, as Im not a release expert - please comment what I forgot to
add to that example. :)
--
bye Joerg
<ribnitz> Ganneff: NM-queue ist das schnellste zu uploadrechten für ein paket,
oder?
<youam> ach aqua^Wribnitz
Attachment:
pgppdJKUfJF64.pgp
Description: PGP signature