Steve Langasek, 2005-03-13 20:45:09 -0800 :
[...]
> 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.
Which is a major change in content from everything we've heard until
now, especially when said release team and ftpmasters came into the
"let's drop the doorstop architectures" flamewars, with a "number of
arches is not what's blocking us".
> 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.
> 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.
I'll call that "dropping architectures". You can nitpick about the
words, but the concept is clearly that.
> 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.
Based on the last few hours only, I think you'll have lots of comments
to meditate on :-)
> 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.
> 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:
One could argue about the "objective" part.
> - the release architecture must be publicly available to buy new
What if it's readily available in large quantities on Ebay, for
instance ?
> - the release architecture must have a working, tested installer
I'll come back to that later.
> - 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.
> 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.
The way I see it (and although I do read d-devel, d-release,
d-d-announce and related lists, and I do hang around on IRC for a
considerable amount of time, I have to admit it's a bit of non-trivial
connect-the-dots), the release blockers are (or have been):
- 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.
- d-i, especially the kernel problems: okay, so there the
arch-specific kernels have played a role.
- 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.
- buildd broken because of a broken upload: hardly related to the
number architectures.
- buildd backlogged: more of a social problem, apparently, since there
have been numerous attempts to provide help in the form of manpower
and/or hardware.
Now drop some arches. What happens?
- d-i progresses faster in the "main" arches. Which means the lowly
arches have an even harder time keeping up. (Incidentally: dropping
the other arches actually means that all this tremendous and highly
successful work the d-i team did could have been avoided, by simply
using Anaconda, since the only objection to switching to it was
portability.)
- 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 porters also have the additional burden of having to maintain
their own testing scripts and release team and so on, for a net
result (a hypothetical stable release) that won't even be officially
endorsed by the project.
- Of course, people who already run servers on Sparc or Alpha
hardware, or use their Mips or Arm palmtops as portable
communication devices, or keep their network secure by putting a
firewall on their old Mac, are given a friendly wave, maybe a round
of applause in thanks for their past incentive we had to be
portable, and a firm goodbye.
> 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?
> Also, since the original purpose of the SCC proposal was to reduce
> the size of the archive that mirrors had to carry, the list of
> release candidate architectures will be further split, with only the
> most popular ones distributed via ftp.debian.org itself. The
> criterion for being distributed from ftp.debian.org (and its
> mirrors) is roughly:
[...]
These are reasonable criteria for the SCC scheme. Again, since SCC
has been overridden, pleae change its name.
> This plan has been signed off on by:
> The following people in Debian leadership roles have also expressed
> their support:
Could we know who expressed their lack of support, or maybe even
opposition? As is, it smells like a small team has decided to kick
the porting efforts out of Debian. "Oh," I hear you cry, "they're not
kicked out". Well, no, they just aren't recognised by the project,
they can't get the blessing of an official debian stable release, they
don't get to matter in how packages migrate to testing, and so on.
Hey, since their packages have to be built from the exact same sources
as the "mainstream" packages, it's even virtually guaranteed their
packages won't work (or build), since some of the package maintainers
won't apply their patches.
> 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.
What bothers me a lot is that you call this a plan (a "prospective
plan" at best) and not a proposal. There's this half-secret meeting
planned (only half-secret because you did announce it, of a sort, two
days beforehand -- or so I'm told, I haven't read that), then held,
where you discuss things that have a huge impact on the project, then
come up with plans. And then, one sunny Monday morning, the world
awakens and sees large yellow bulldozers before its house, with a
Vogon Constructor Fleet on its way.
Additionnally, the fact that all but one of the DPL candidates support
that plan, and that they all mention they want to improve transparency
and internal communication (except for one who boasts his ability to
represent the diversity of [...] interests that make up our project)
is really scary to me. That, and the "I din't answer *that* question,
you can't hold it against me" weaseling-out (I don't like the term,
but I can't find one more suited). I hope Debian is not becoming
another banana republic.
I'm sure you can tell I'm disgruntled by that proposal. I hope my
conspiration theory fears are unfounded, but I believe the main "let's
drop two-thirds of our arches" problem is a large mistake. In both
cases, I'd be glad to be corrected -- with facts, please. As has been
noted, this plan doesn't mention what problems it tries to solve, nor
what measure solves which problem.
Roland.
--
Roland Mas
'And what would humans be without love?'
RARE, said Death. -- in Sourcery (Terry Pratchett)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
