Re: Bug#699808: tech-ctte: syslinux vs the wheezy release
Don Armstrong <don@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 (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: