[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Release Transitions


as discussed in [1] the transition feature is now available and usable.
Basically it is centered around a Yaml file in which you define the

First: This whole thing is *NOT* meant to set policy on any upload other
than needed for a release transition! No matter how much a possible
upload of a package might be hated. Misuse it and we might accidently
forget how this works in our code. :)

Now, the actual feature. There is a new command, dak transitions. This
has multiple ways to get run:

Called without a parameter you will see an overview of the currently
defined transitions, similar to:

Currently defined transitions:
Looking at transition: apt_update
 Source:      apt
 New Version: 0.7.12
 Responsible: Andreas Barth
 Description: Apt needs to transition to testing to get foo and bar done
 Blocked Packages (total: 7): apt, synaptic, cron-apt, debtags, feta, apticron, aptitude

Transition source apt not in testing, transition still ongoing.

It shows what source and version needs to transition and what packages
will get rejected[2] together with the description and also who is
responsible for it. In case the transition is over it will also say
that, but it *won't* modify the file.

That leads to the first option, -c|--check. It will do the same output
as above, but additionally also remove old transitions. Use that to
semi-automagically cleanup the file, as every defined transition will
get checked for every upload and so you shouldn't have old stuff in
there. If you would want to keep a record of old transitions - copy them
elsewhere or something, dont keep them in this file please.

Now, the most important commandline option for you: -e|--edit.

This will spawn an editor with a temporary file showing the currently
defined transitions. The example from above would look like[3]:
  reason: Apt needs to transition to testing to get foo and bar done
  source: apt
  new: 0.7.12
  - apt
  - synaptic
  - cron-apt
  - debtags
  - feta
  - apticron
  - aptitude
  rm: Andreas Barth

The order of the fields does not matter (and might actually get sorted
randomly when the file gets updated) and the short names (apt_update here)
*have* to be *unique*. One important thing: Use a *consistent* indentation
style, best is to keep 2 spaces for the indent. Strings *should* be
in "", but normally work without them, with one notable exception:
Version-numbers with an epoch REALLY DO WANT to be in "". Trust me. They

For reference, the layout is
# short_tag:    A short tag for the transition, like apt_update
#   reason:     One-line reason what is intended with it
#   source:     Source package that needs to transition
#   new:        New version of the target package
#   rm:         Name of the Release Team member responsible for this transition
#   packages:   Array of package names that are affected by this transition
#   - package1
#   - package2
#   ...

Yes, the packages array has to include the transition source again. It
is not automagically included! This is done on purpose, so you can
easily allow any of the packages to upload again by simply removing them
From this array until the upload you want is there.[4]

After you are done with the edit you will be presented with an overview
of the defined transitions. Look if the programs interpretation of what
you just wrote is what you want to have. Look again. If it is - let it
save it, if not edit again or drop the changes.
In case you made a mistake with the Yaml format, missed a key or added
one too much you should get a nice error message about it, with the only
option to Edit again or Drop the changes.

Effect of such a defined transition:
If someone does a *sourceful* upload it will get rejected with a message
similar to
feta: part of the apt_update transition

Your package is part of a testing transition designed to get apt
migrated (it is currently 0.6.9, we need version 0.7.12).  This
transition is managed by the Release Team, and Andreas Barth is the
Release-Team member responsible for it. Please mail
debian-release@lists.debian.org or contact Andreas Barth directly if you
need further assistance.  You might want to upload to experimental until
this transition is done.

Any questions? If not - have fun.

One more part, for those who produce nice little scripts for devscripts,
manage the pts or our other QA pages: If you want to display transitions
(or give notice before an upload), the sourcefile used for this is
always available at

[1] http://lists.debian.org/debian-release/2008/01/msg00112.html
[2] uploads to unstable only, experimental or *-proposed-updates are
[3] If there are --- in a line above all the rest - ignore them, leave
    them there, even if nothing else is in, they don't hurt.
[4] Transitions get checked on process_unchecked time, so as soon as
    packages are past that point (ie. in incoming.debian.org AKA
    queue/accepted) you could enable the block again.

bye, Joerg
<andreasj> Also diese neuen Spam-Mails muten an wie Blog-Posts von Clint Adams
<andreasj> irgendwie ist es eine Geschichte, aber ich versteh sie nicht

Attachment: pgpyt7oZLrazT.pgp
Description: PGP signature

Reply to: