[ 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/ -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100326095142.gg7...@rivendell
