Re: Serializing transitions
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 (xoswald@debian.org)
: :' : GNU/LINUX Debian Developer <http://www.debian.org>
`. `' GPG Key: 1024D/88BBB51E
`- 938D D715 6915 8860 9679 4A0C A430 C6AA 88BB B51E
Reply to: