Serializing transitions
[ Bcc debian-release for info, discussion welcome on -devel ]
Hello,
one of our biggest problems is dealing with transitions because they tend
to get interdependant and it's thus very difficult to move packages from
sid to testing. Also many transitions are badly managed by the maintainers
who are responsible for them, some even tend to consider that once they
have uploaded the package to unstable, the rest will be done
automatically.
It would be nice to solve those problems. I have a proposal and in order
to not make it needlessly complicated I leave out many of the details,
they will have to be fleshed out later if we agree that it's something
that might be doable and should be tried (at that point starting a DEP
would make sense to get approvals from all concerned teams because it
requires far-reaching changes as you will see).
To resolve the problems I suggest to serialize transitions in sid.
First the archive should block package uploads to sid that would be
starting a new transition (defining this in more details is left for
later). Instead transitions should be managed in dedicated repositories
that are overlays over sid. We would have tools (command-line, web
interface, etc.) to manage the transition in that repository. We could
tell which packages need to be rebuilt (bin-NMU, sourceful upload)
and the system would automatically rebuild the package (and it
would also be automatically rebuilt every time that the package is updated
in sid). Some web interface would display the status of the transition,
displaying which package/arch have been built or not, and which one failed
to build from source. Build-dependencies for the package rebuilds are
fetched in sid and in the corresponding transition repository, that way
parallel transitions are not mixed. Once all packages are rebuilt on all
arches in the transition repository, the whole repository can be
integrated in sid instantly (note that other pending transitions at this
point will probably suffer a small setback since the underlying sid
distribution has changed and many packages will have to be rebuilt and
some may fail to build).
Multiple transitions will still end up mixed in sid if you push them
before packages have migrated to testing but they are all already
completed and you only have to deal with RC bugs and delays to ensure
package can migrate to testing. The release team has less responsibilities
in making transitions happen but should instead carefully pick the order
in which transitions will be pushed to sid.
Dealing with transitions that way make it clear that the maintainer has to
take the responsibility to prepare/complete the transition if he wants to
see his package in sid and in the next release.
Transitions can be started at any time, it's just that they will not be
pushed to sid until they are completed. Nowadays we ask people to not
start transitions because others are already going on, it's
counterproductive. Preparing the transition in experimental is not always
done and takes much more energy than such a system would take.
How does that sound to you? There are numerous problems to solve to
implement this of course, but do you believe that this approach could lead
to better transition management, quicker testing transition and
less frustration?
Cheers,
--
Raphaël Hertzog
Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/
My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/
Reply to: