On 10:51 Fri 26 Mar , Raphael Hertzog wrote: > 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.
After reading these 2 parts, it shows up that lot of cases have to be handled and this will need a huge amont of work. Before starting anything I think we should clearly define all the needed tools and a transition procedure if we will follow your ideas. > 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. Agreed. > 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? I was thinking to such a proposal last few days after thinking of latest python and perl migration. But it seems that you have deeper studied this topic than me ;) IMHO the discussion starts in the right way. Thanks for raising it. I think it's important to raise and discuss these issues and find out a better way to handle this than it's actually done. Greetings, -- ,''`. Xavier Oswald (xosw...@debian.org) : :' : GNU/LINUX Debian Developer <http://www.debian.org> `. `' GPG Key: 1024D/88BBB51E `- 938D D715 6915 8860 9679 4A0C A430 C6AA 88BB B51E -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100326103217.ga21...@gmail.com
