As a DPL candidate, and as a signatory to the document Steve Langasek posted to debian-devel-announce[1], I reckoned it would be useful to post some detailed thoughts of my own.
1) First and foremost, I'd like to thank the attendees, the organizer
(Andreas Schuldei) and the NUUG Foundation for making this happen. We've
witnessed angst over the Debian release process for years, and it's
heartening to see that a community sponsor is willing to underwrite the
opportunity to put many of our critical infrastructural personnel into a
room together and ask them to grapple with the issues.
2) Secondly, I understand the writeup Steve posted to be a proposal, which
is why I call it the "Vancouver Prospectus". I did not and do not
understand it to be a fait accompli, an ultimatum, or a done deal. The
Vancouver Prospectus is the *beginning* of tackling the problem of the long
stable release cycle, not the end. (The end is, I would think, actually
pulling off a release on schedule -- twice!) Other proposals to date that
I have seen have been incomplete stabs in the dark. The Vancouver
Prospectus has about it at least the "whiff of plausibility", which I'm
very happy to smell.
The next stage in the process is to actually sell the proposed changes for
etch to the developers at large[2]. There are several points which can and
should be discussed; I myself am not certain what the motivations for some
criteria are, and it would be good to have those documented so that we can
tell if an when they no longer apply.
Let me offer some examples:
* Why is the permitted number of buildds for an architecture restricted to
2 or 3?
* Three bodies (Security, System Administration, Release) are given
independent veto power over the inclusion of an architecture.
A) Does the entire team have to exercise this veto for it to be
effective, or can one member of any team exercise this power
effectively?
B) Is the availability of an able and willing Debian Developer to join
one of these teams for the express purpose of caring for a given
architecture expected to mitigate concerns that would otherwise lead
to a veto?
C) How often can/should these bodies be petitioned for a reconsideration
of their veto in light of underlying changes in circumstance?
D) How will the exercise of a veto be communicated to the Project?
* The guidelines for eligibility as a released architecture, and for
inclusion in SCC, could be initially met, but later fail. For example,
an architecture could fall below the 98% up-to-date mark. Does this
spell automatic expulsion from the slate of releasable architectures?
Similarly, for how long are the petitions for inclusion in SCC (5
developers and 50 users) assumed to remain valid?
I think it would be quite worthwhile for a FAQ to be maintained on the
Debian Wiki, so that answers to these and other questions can be
collected. As a matter of fact, I just started one[3].
3) For the record, I support the proposal Steve Langasek even though I am
adversely affected by it. I host my share of Debian infrastructure
(Subversion repositories for packages I and the Debian X Strike Force
maintain), to say nothing of my personal DNS domains, web site, and MX
host, on an UltraSPARC machine running Debian/GNU Linux. I also own a
Macintosh Quadra 840AV (m68k) which has Debian installed, but has not run
for some time because I, er, disassembled the thing and can't figure out
how to put it back together[4].
Still, there are other potential proposals I might like more. The support
of the existing release, security, archive administration, and system
administration teams is important, however; regardless of whether I'm
elected DPL, I feel that the buy-in is critical from those who are actually
expected to do the work of managing these architectures from the numerous
perspectives required.
The other strongly appealing factor of the Vancouver Prospectus is, of
course, that it is a proposal which actually exists.
4) If anyone was wondering, no, I didn't have any advance warning of the
broad strokes or details of the proposal forged in Vancouver, until it was
sent to me and the other DPL candidates for review. The LWN interview
predated that, complete with my skeptical remarks about dropping
architectures. :)
5) To reiterate point 2) above, this is the beginning of process, not its
end. The Debian Developers have the power of the General Resolution at
their disposal. Even if it is generally agreed that the Vancouver
Prospectus, despite some of its painful aspects, is the best way to go
forward, we need not leave it lie. We can still propose and pass a General
Resolution. In fact, that might be a healthy thing to do -- but not just
this moment.
For the near term, I suggest we take the advice Steve Langasek offered;
we're told the security infrastructure for sarge should be ready by now.
I welcome discussion, but I would discourage us from fighting tomorrow's
battle before today's are won. I exhort all of us (myself included[5]) to
do our utmost to get sarge releasable -- on all 11 architectures. That is
a feat to my knowledge never approached by any other GNU/Linux
distribution. Sarge is definitely something we'll be able to be proud of.
I welcome any questions on my support of the Vancouver Prospectus that you
may have.
[1] Message-ID: <[EMAIL PROTECTED]>
[2] I'm assuming people don't actually have a problem with bringing the
sarge security infrastructure online and actually freezing it. If I'm
wrong, please let me know in a follow-up.
[3] http://wiki.debian.net/?VancouverProspectus
[4] I tremble at the votes I will lose through this admission of
ineptitude. :) Maybe I should take a real-world "exploded view"
photograph to show just how obnoxious the chassis really is...
[5] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=299272
--
G. Branden Robinson | I must despise the world which does
Debian GNU/Linux | not know that music is a higher
[EMAIL PROTECTED] | revelation than all wisdom and
http://people.debian.org/~branden/ | philosophy. -- Ludwig van Beethoven
signature.asc
Description: Digital signature
