Steve Langasek wrote:
> First, the news for sarge. As mentioned in the last release team
> update[1], deploying the testing-security queues has been held up
> pending some infrastructure enhancements, without which
> ftp-master.debian.org cannot handle the load of the added wanna-build
> queues for testing-security. This week, Andreas Barth and Ryan Murray
> have been applying the finishing touches to allow the needed upgrade of
> ftp-master.debian.org's openssh to a version that supports connection
> caching, which is needed before the current ftp-master host will scale
> to handle the addition of testing-security queues. Once this happens,
> the testing-security configuration should itself be completed for all
> architectures in quick succession, with the result that testing-security
> and testing-proposed-updates will be fully operational in the space of
> two weeks.
It's good to know that only one bit is missing and that this will be
fixed soon. However, since it's one bit that is missing for several
months now, I really wonder if this is really the last bit that is
missing and why there shouldn't pop up another last bit in three weeks
that will keep us from releasing.
Also, I really wonder why the w-b load on newraff wasn't a problem
just until now. Switching the buildd network from spontaneous ssh
connections to a persistent connection is not something that needs to
be implemented "right before a release". And at least for m68k the
problem that each ssh connection to the wanna-build database took a
while was known for a long time already.
> This means that we are now (at long last) in the final stretch for
> sarge's release, and we will be freezing soon once we know that d-i RC3
> is golden. While this does not yet give us a timeline with fixed dates
> for the freeze and the release, this is noteworthy enough in itself that
> we wanted to share the news immediately.
Thanks.
> The much larger consequence of this meeting, however, has been the
> crafting of a prospective release plan for etch. The release team and
> the ftpmasters are mutually agreed that it is not sustainable to
> continue making coordinated releases for as many architectures as sarge
> currently contains, let alone for as many new proposed architectures as
> are waiting in the wings. The reality is that keeping eleven
> architectures in a releasable state has been a major source of work for
Up to this mail, this wasn't a problem that was publically discussed.
Why? Was it not a problem? Or was our communication so bad that we
were unable to even discuss problems?
Up to Steve's mail, the reason why we couldn't release were d-i wasn't
ready, testing-proposed-updates wasn't in place, testing-security
wasn't in place and the like. Keeping architectures in sync was never
addressed as a problem. But suddenly it is?
It is one of Debian's strengths that we do our releases synchronous
through all architectures and have security support for all of them in
a proper and sycnchronous fashion. If we drop this feature, Debian
will lose a lot.
Granted, there were problems every once in a while concerning one
transition or another. However, if these transitions that had to be
forced into sarge were so problematic that they will be used as reason
by the release and ftpmaster team to drop architectures, I would have
expected this problem to be communicated a lot earlier.
I'd rather like to implement whatever techniques could be helpful in
order to help mitigate the problem instead of dropping architectures.
> the release team, the d-i team, and the kernel team over the past year;
Also, why is it such a problem to keep d-i usable for all
architectures? We were able to manage boot-floppies for 11
architectures and d-i was supposed to be a lot easier.
Due to it's much better modularisation many architectural problems
need to be and can be addressed by the porters of that particular
architecture. If the porters cannot keep up with the installer, than
*this* would be a good reason to remove this particular architecture
from the list of architectures to be released. At least this is what
I would have expected.
The same goes for the kernel team. Now that we have a kernel team in
which porters for all architectures are supposed to participate it's
clearly the porters obligation to ensure that the kernel is fine on
their architecture, which will lead to being able to release this
architecture or not.
> not to mention the time spent by the DSA/buildd admins and the security
Thanks for asking the security team how much work it is to support 11
architectures. Err... Huh? I wasn't asked? Uh?
However, to clarify this for the readers who aren't involved in
security: Thanks to the awesome buildd network and a stable Debian
release supporting 2 architecturs is as easy or difficult as
supporting 20. The difference is just waiting for one buildd reply or
waiting for 19.
In most of the times the package will compile fine on all
architectures since it's a stable Debian release and hence its
packages are supposed to be rebuildable on a stable Debian machine.
There are exceptions to the rule, but they're not that common. A new
S/390 kernel and a new MIPSel kernel caused some configure scripts to
fail, but this can be solved quite easily (once debugged and
documented) by patching the configure script, so it's just a rebuild
that is required.
More problematic are cases when software doesn't compile anymore on a
certain architecture due to compiler problems or kernel limitations.
However, these are very rare and I only remember two such cases: chbg
doesn't compile on HPPA anymore and xemacs21 cannot be compiled by a
buildd anymore.
It causes the security team a lot more work to support more than one
distribution and/or to support older software for which current
patches don't work and where the code is too different to easily find
out whether it is vulnerable as well or not.
Supporting stable and oldstable for a year until we drop support for
oldstable always causes a lot of extra work for us. Supporting more
than one architecture for a given distribution is not.
This, however, refers to a working buildd network. However, every
once in a while one architecture fails because only one buildd is
configured for stable-security and this buildd is defunct. For
example, there was no working i386 buildd for a long time. Currently,
there is no arm buildd (for whatever reason, I dunno).
The hate architecture for many developers however, m68k, has worked
quite well normally. There are about a dozen buildd machines and
several of them are configured to compile stable-security. If one
machine is busy or down, another one picks up the package.
Additionally, this architecture has quite responsive buildd admins so
problems can be discussed and resolved via irc or mail quite easily.
These are features I would wish for all architectures: more than one
buildd configured for stable-security and responsive buildd admins.
> team. It's also not clear how much benefit there is from doing stable
> releases for all of these architectures, because they aren't necessarily
> useful to the communities surrounding those ports.
Could you elaborate on this?
Why is a release, especially for these architectures that you want to
drop, not useful for their respective user communities?
> Therefore, we're planning on not releasing most of the minor architectures
> starting with etch. They will be released with sarge, with all that
> implies (including security support until sarge is archived), but they
> would no longer be included in testing.
This would be the death of such ports. People using such
architectures would then have to find out whether Debian is still
suitable for them, but I doubt that it would. Maybe forking Debian
into the universal operating system that Debian (then) once was or
getting some kind of compiled Gentoo or Rocklinux would be the proper
way/distribution for our porters.
> This is a very large step, and while we've discussed it fairly thoroughly
> and think we've got most of the bugs worked out, we'd appreciate hearing
> any comments you might have.
From what I have heard and seen, many people, especially users of the
architectures you've suddenly considered as crap, don't like the idea.
I don't like it either, I have to admit.
> This change has superseded the previous SCC (second-class citizen
> architecture) plan that had already been proposed to reduce the amount of
> data Debian mirrors are required to carry; prior to the release of sarge,
> the ftpmasters plan to bring scc.debian.org on-line and begin making
> non-release-candidate architectures available from scc.debian.org for
> unstable.
If you need to split the package archive don't call non-i386 second
class, but ports or tomething. Otherwise you could also name it crap
or shit because that's what the name implies.
If the mirrors complain about the sheer archive size of Debian why
wouldn't it work out if we would only require tier-1 mirrors to mirror
the entire archive, leave this decision to tier->=2 mirrors and offer
better mirrroring software that can be configured much easier to
mirror only a subset of
{stable, testing, unstable, experimental} x {source,all architecures}
To me it is not clear why we need to go from "you have to mirror
everythying" to "we will drop architectures" instead of loosen the
requirements for mirrors and offer a way for them to decide which
parts to mirror.
> Note that this plan makes no changes to the set of supported release
> architectures for sarge, but will take effect for testing and unstable
> immediately after sarge's release with the result that testing will
> contain a greatly reduced set of architectures, according to the
> following objective criteria:
For many people this would imply that Debian sarge was the last real
Debian release.
> - the release architecture must have N+1 buildds where N is the number
> required to keep up with the volume of uploaded packages
- and all of them must be configured to build stable-security *and*
testing-security in addition to stable-proposed-updates and
testing-proposed-updates.
This would actually help mitigate the problem of broken/down buildds
with unresponsive admins.i
> - the value of N above must not be > 2
This number seems to be arbitrarily choosen.
> - the release architecture must have successfully compiled 98% of the
> archive's source (excluding architecture-specific packages)
This is only achieved for the i386 architecture.
> - the release architecture must have a working, tested installer
Just as usual...
> - the Security Team must be willing to provide long-term support for
> the architecture
We can only support an architecture if there is buildd support and we
can only support stable distributions (and to a limited extend
wannabe-stable distributions aka testing).
> - the Debian System Administrators (DSA) must be willing to support
> debian.org machine(s) of that architecture
If they aren't, new people should be added - which is a long-standing
goal already...
> - there must be a developer-accessible debian.org machine for the
> architecture.
Just as usual.
> We project that applying these rules for etch will reduce the set of
> candidate architectures from 11 to approximately 4 (i386, powerpc, ia64
> and amd64 -- which will be added after sarge's release when mirror space
> is freed up by moving the other architectures to scc.debian.org).
> This will drastically reduce the architecture coordination required in
> testing, giving us a more limber release process and (it is hoped) a
> much shorter release cycle on the order of 12-18 months.
Since this is the first time I hear that so much of "architecture
coordination" is required for testing, could you elaborate how much
time this is referring to and which problems the release team has
faced in particular? I'd be glad if somebody could propose an
alternative solution, as dropping most architectures would be a large
regression for Debian and its community.
> Architectures that are no longer being considered for stable releases
> are not going to be left out in the cold. The SCC infrastructure is
> intended as a long-term option for these other architectures, and the
> ftpmasters also intend to provide porter teams with the option of
> releasing periodic (or not-so-periodic) per-architecture snapshots of
> unstable.
Looking at how "easy" it is to roll out an update to stable with
regards to the responsiveness of ftpmasters, I find the above option
quite interesting. FWIW, I'm trying to discuss the next update to
woody for one month again already. Don't think I've gotton a response
yet. Doing a "periodic per-architecture snapshot" is probably much
easier, right?
This would be the death of many ports since it is not possible to
support those snapshots security-wise by the security team and they
would be locked out of a stable release as well. We cannot support an
arbitrary number of source packages. This would get the Debian
archive totally out of sync.
We also cannot install and maintain an arbitrary number of chroot
environments for another arbitrary number of architectures that are
now considered crap. This would also mean that the porters won't be
able to support their architecture should they manage to create
"snapshots" more often than Debian releases i386.
It's also an interesting thought how many architectures will suffer
from the _all dependency trap when maintainers don't care about crap
architectures anymore that won't be released at all.
> This plan has been signed off on by:
>
> Steve Langasek (Release Manager)
> Colin Watson (Release Manager)
> Andreas Barth (Release Assistant)
> Joey Hess (Release Assistant)
> Frank Lichtenheld (Release Assistant)
>
> James Troup (ftpmaster)
> Ryan Murray (ftpmaster)
> Anthony Towns (ftpmaster)
It looks like a public list of the cabal. I'm personally very
disappointed by how this way-to-go was achieved and by the outcome
itself. This is not how Debian worked in the past (despite some
people blocking some parts). This is also not a community effort
anymore which is quite sad to learn.
> The following people in Debian leadership roles have also expressed their
> support:
>
> Andreas Schuldei (DPL candidate)
> Angus Lees (DPL candidate)
> Branden Robinson (DPL candidate)
> Jonathan Walther (DPL candidate)
Anthony Towns (DPL candidate)
I wonder if this means that five people need to be ranked below NONE.
> Again, if you've got any questions, comments or concerns, please raise them
> on -devel so we can take them into account before putting this plan into
> effect.
Done.
Regards,
Joey
--
Ten years and still binary compatible. -- XFree86
Attachment:
signature.asc
Description: Digital signature