Hi Roland,
On Mon, Mar 14, 2005 at 04:04:45PM +0100, Roland Mas wrote:
> Steve Langasek, 2005-03-13 20:45:09 -0800 :
> > 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.
> I would like to refer to the (also numerous) flamewars we've had on
> "why should we release after all?". There have always been reasons to
> keep providing releases, and these reasons apply as much to "minor"
> architectures as they do for "major" ones. At least from what's been
> publically discussed.
Certainly, there are reasons why it benefits us (FSO "us" within the
community) to release Debian for each of the architectures that sarge will
be released with. However, this doesn't come for free; the release can only
progress as fast as the slowest architecture at any given time, which means
that if we don't have a very rigid standard for how slowly a release arch is
allowed to move along, we have a very slow release process indeed.
This proposal is, first and foremost, about setting concrete criteria that
we can hold the ports to for etch, to get away from wishy-washy, "one more
week for kernel updates on $arch", "$arch2 isn't doing so well, maybe we
should drop it from testing" problems that the release team is currently
suffering from. The idea of setting criteria should not be controversial,
though I can understand that specific criteria we've suggested may be.
Second, and only second, is the recognition that there is a certain measure
of overhead that can't be dealt with in parallel by porters, and introduces
delays in the release process. This includes factors such as per-arch
toolchain churn when major toolchain changes are introduced, as well as
having to do some things the hard way in britney right now, and any
central coordination that needs to be done by ftpmasters (configuring
wanna-build access, managing the archive size, etc). The last might be
mitigated by expanding the ftpmaster team, if it's a problem; but the big
one here is the toolchain, because each "build, test, fix" cycle has a
lengthy "let the package get picked up by autobuilders, wait to see what
breaks" stuck in it. This kind of thing makes it worthwhile, from a release
standpoint, to consider reducing our release architecture count even if all
our architectures meet the objective quality criteria we set.
This is why the "N <= 2 autobuilders" criterion has been looked at as a
means for deciding which architectures we might want to drop from the
release. It's possible that setting the other requirements would give us a
reduced count of architectures for etch; but it's also possible that all the
port teams will pull together and manage to satisfy the release arch
requirements for all 12 architectures. That would be great, but it would
still leave us with those coordination/synchronization problems that can't
be solved by throwing more manpower at them. It's difficult to say what the
concrete per-arch impact of these problems is on the release cycle, because
I think they're lost in the noise right now of those problems that *can* be
brought under control; but my gut feeling is that 11 architectures is
already above the threshold at which it starts to hurt us.
In that case, it makes sense to consider dropping the slowest, legacy
architectures from the release.
> > 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.
> I'd like this plan to drop the "SCC" name then. It used to be just a
> matter of where to go to fetch packages. Now it's officially
> obsoleted architectures. Very different things, and keeping the name
> would be misleading.
Very different things, which is why the "SCC" name (or "ports", as it looks
like we might prefer) is only used to refer to the mirror division -- not to
whether or not an arch is an RC (release candidate).
> > - the Security Team must be willing to provide long-term support for
> > the architecture
> > - the Debian System Administrators (DSA) must be willing to support
> > debian.org machine(s) of that architecture
> > - the Release Team can veto the architecture's inclusion if they
> > have overwhelming concerns regarding the architecture's impact on
> > the release quality or the release cycle length
> This is where the "objective" is questionable. Please, at least
> require that the reasons for all three of these potential refusals be
> motivated.
Er, I don't really think that was ever in question; the point here is to not
paint ourselves into a corner where we say "we didn't think of this issue
before, but it's a serious problem, we can't release an architecture that
suffers from $foo", and the community replies to us, "but it meets all of
the requirements you listed, so you have to make it work!"
> > 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.
> There comes the meat of my argument. First, a preamble:
> ,----
> | <aba> Lo-lan-2: the single largest problem with sarge release is
> | that both neuro and I were ill for quite some time in the last three
> | weeks.
> `----
> This was, as far as I can tell, Andreas Barth, release assistant, a
> few hours ago on #Debian-devel on irc.debian.org.
> - infrastructure: testing-security not doable because of bugs
> ("patches required") in the dak suite, britney, or whatever. That's
> independent from the number of released arches, I think.
The first round of infrastructure changes were not related to our ability to
release a large number of architectures at once.
The second round are: it's directly about making changes to the software
running on ftp-master.d.o and on all the buildds, so that ftp-master.d.o can
scale to handle the number of incoming ssh connections required for all the
build queues we have to have set up.
> - RC bugs: as far as I can see, the porters have a positive role in
> that, and provide patches more often than not. So the number of
> arches probably has a positive impact too: bugs are detected earlier
> rather than later.
However, RC bugs are not much of a blocking issue, and haven't been for a
while, IMHO. The bug count is no longer steadily dropping, and this seems
to be because we've hit a threshold where it's not as effective to try to
push down the RC bug count without a freeze to help us control the number of
new incoming RC bugs.
> - Assuming porting teams haven't left in disgust, they still do their
> porting jobs and submit bugs and patches. These patches are very
> likely to rot in the BTS, since the maintainer is now able to *say*
> "go away, you're not released, you don't interest me" instead of
> just thinking it and quietly ignoring them. Where's the incentive?
> The package migrates to testing anyway.
The incentive is taking pride in one's packages. Does that not matter
anymore? Do maintainers not care about bugs that aren't RC?
The rest of your predictions strike me as pessimistic speculation that I'm
not going to reply to. It's much more useful right now to focus on finding
solutions here that will enable porters to create something that meets their
needs without dragging down the release process.
> > 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.
> Sbapshots of unstable. And people would run that on their servers?
Some, maybe. Are there lots of people running servers on m68k and arm?
--
Steve Langasek
postmodern programmer
Attachment:
signature.asc
Description: Digital signature