Don Armstrong <d...@debian.org> writes: > Assuming that the patch for #699742[0] fixes this issue with DI RC > releases being installed, is there still an outstanding issue for the > CTTE?
Earlier in this thread, there had been a couple of reports that fix didn't work. I haven't looked further, though. > [I can understand a bit of wariness of having d-i built with a version > of syslinux that isn't being distributed in wheezy, but I think that > might need to be discussed and a technical solution fleshed out > elsewhere, and probably isn't ripe for a CTTE decision.] In practice, at least for the last couple of release cycles, we freeze unstable for non-leaf packages during the release freeze because otherwise it's too difficult with our current infrastructure to finish the release. I believe this has even been made explicit in release-team updates, although I haven't gone back and checked the exact wording. I concur with Daniel and with Anthony that it does feel like a deficiency in our tools that we don't have a way to distinguish wheezy-targeted packages from post-wheezy development and build wheezy-targeted packages with the build dependencies that will be released with wheezy. If we had such a thing, I think it would save the release team some time, since it would limit the problems caused by uncoordinated library transitions during the release freeze. I also concur with Daniel that it can make development during the release freeze rather annoying when there are multiple branches of upstream that one wants to follow, since we only have one other archive available for packages that aren't eligible for release. But, well, that's the architecture we have right now and we're clearly not going to fix it immediately. Given that, I think it makes sense to, as Daniel mentioned, make it rather explicit that, yes, unstable is frozen for non-leaf packages until we complete the release. And, in this specific case, to revert the syslinux update in unstable (and hopefully upload to experimental) so that we're not building d-i against a package that isn't part of the release. That does take over experimental for that purpose, but, well, there's always personal repositories; that's what I sometimes do when there are more branches of development to juggle than there is space in Debian. It's annoying, and we need better tools, but it's possible. In the longer term, I think it would be interesting to provide some more metadata and automation around the whole release request/unblock/build process than we have right now. For example, I could see some use in a system where one has to explicitly tag a package as being targeted for the next release or not targeted for the next release, which could be communicated to the buildds in some fashion so that they would build release-targeted packages against only the release-targeted packages, and new uploads of release-targeted packages would be automatically diffed and brought to the release team's attention. There could even be a convention for including the justification for the change. (I can see a lot of complexity here in how one would have to set up the archive suites, since you can't just point the buildds at testing since there would be no way to stage library transitions that *are* going into the release, so let me note that this is not a well-thought-out proposal, just the sketch of an idea.) But that's all outside the scope of tech-ctte deliberation, since that's technical design, and regardless isn't something that we would do right now. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- 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/87vca5rvyu....@windlord.stanford.edu
