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
pgpz5I9ikqoBp.pgp
Description: PGP signature