|
|
"Vancouver" has gotten a very specific meaning in the Debian community: one of a visionary proposal[1] that received quite its share of flames from many Debian contributors, including myself. Since it appeared to many of us that the intentional result of this proposal would have been to essentially kill off many of our architectures, many of us weren't too happy with the proposal.
|
|
--qMm9M+Fa2AknHoGS
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Hi all,
"Vancouver" has gotten a very specific meaning in the Debian community:
one of a visionary proposal[1] that received quite its share of flames from
many Debian contributors, including myself. Since it appeared to many of us
that the intentional result of this proposal would have been to essentially
kill off many of our architectures, many of us weren't too happy with the
proposal.
In subsequent communication with some of the people present at the
Vancouver meeting, however, it became apparent to me that this was not
the idea; rather, the proposal tried to create a set of quality
requirements for all of our ports, so that our users would be guaranteed
to get, for example, a Debian/SPARC of the same quality as
Debian/PowerPC.
This in itself is a laudable goal; but as I felt that the requirements,
as proposed, did not meet that goal, I called for a meeting at DebConf5
with all parties involved and present at the conference.
This meeting has taken place on 2005-07-11[2], with the following people
attending:
* Bdale Garbee, DPL team member, has been involved with the startup of 5
ports;
* Branden Robinson, DPL;
* Wouter Verhelst, m68k porter;
* Gerfried Fuchs, local admin to buildd machines;
* Joey Hess, core d-i developer, present at the Vancouver meeting;
* Kurt Roeckx, non-DD amd64 porter;
* Anthony Towns, FTP-master, present at the Vancouver meeting;
* Jeroen van Wolffelaar, DPL team member, FTP team member, present at
the Vancouver meeting;
* James Troup, arm and sparc buildd admin, DSA team member, FTP-master,
present at the Vancouver meeting;
* Florian Lohoff, mips/mipsel porter, local admin to buildd machines;
* Andreas Barth, Release Assistant, present at the Vancouver meeting;
* Guido G=FCnther, mips/mipsel porter;
* Robert Jordens, DD;
* Steinar Gunderson, DD
In addition, I have, beforehand, exchanged mail with Joey Schulze of the
Debian Security team about this meeting, and he's provided me with his
opinion on the matter.
While I did my best to get a wide range of people to attend, two notable
absentees are both our Release Managers. Since they couldn't be in
Helsinki, they obviously couldn't be at this meeting either (although
they've had the opportunity to review this text before it was sent out);
therefore, while we've come up with all sorts of things, they're not to
be seen as any sort of official release policy statement -- unless, of
course, it is officially added to our release policy by the release
team.
Anyway.
The problematic items we discussed at this meeting included the
following four points:
1. The requirement that 'an architecture must be publically available to
buy new'.
It was explained that this requirement was not made to be applied
retroactively to already existing ports; rather, it was designed to
avoid new hardware which, as of yet, is only available under NDA, or
to avoid things such as a Vax port of Debian. Older ports, such as
m68k and arm, are expected to reach a natural end-of-life to a point
where it no longer is possible for Debian and the port's porters to
support it, at which point the port would then, of course, be
dropped.
With this explanation and rationale, nobody at the meeting no longer
had any opposition to the requirement, and it was retained.
2. The requirement that any architecture needs to be able to keep up
with unstable by using only two buildd machines.
The rationale for this requirement was that there is a nontrivial
cost to each buildd, which increases super-linearly; apparently,
there have been cases in the past where this resulted in ports with
many autobuilders slacking when updates were necessary (such as with
the recent security autobuilder problems).
On the flip side, it was argued that more autobuilders results in
more redundancy; with a little overcapacity, there is a gain here
over an architecture which has just one autobuilder, where then that
single autobuilder goes down.
This item was much debated, and we didn't reach an agreement; in the
end, we decided to move on. We hope that after more debate, we will
reach a solution that is acceptable to everyone, but in the mean
time, the requirement remains (but see below).
3. The veto powers given to the DSA team, the Security team, and the
Release team, on a release of any given port.
Some of us feared for abuse of this veto power. All understood the
problems that exist if any port is of such low quality that it would
suck up the time of any of the three given teams; however, we felt
that a nonspecific veto power as proposed would be too far-reaching.
At first, a counter-proposal was made which would require the three
teams to discuss a pending removal of a port together with the
porters team, and require them to come to an agreement. This was
dismissed, since a) this would move the problems to somewhere else,
rather than fix them (by refusing to drop a port, a porters team
could essentially kill the security team), and b) the three
beforementioned teams could already refuse to support a port anyhow,
simply by not doing the work.
In that light, we agreed on a procedure for dropping a port which is
designed to avoid abuse, by making it as open as possible: if any of
the aforementioned teams wants to use their veto power, they have to
post a full rationale to the debian-devel-announce mailinglist, with
an explanation of the problems and reasons for their decision.
It should be mentioned that this requirement was meant to be
implicitely part of the original proposal, but it is good to mention
it none the less.
4. The requirement that any port has to have 5 developers support it,
and be able to demonstrate that there are (at least) 50 users.
Some people feared that this could kill off a port such as s390,
which typically has little installations, but many users on a single
installation. It was confirmed that the important number here is the
number of users, rather than the number of installations; so any port
should be able to reach that number.
With this explanation and rationale, nobody at the meeting no longer
had any opposition to the requirement, and it was retained.
None of the participants had a problem with any of the other
requirements. Note that the separate mirror network is fully distinct of
the rest of the original proposal (although there was a significant
amount of confusion over that fact). The ability to be part of a
stable release (or not) would be fully distinct of the separate mirror
network; indeed, the implementation of both items will now be discussed
and implemented fully separate, to avoid further confusion.
We also came to the conclusion that some of the requirements proposed in
Vancouver would make sense as initial requirements -- requirements that
a port would need to fulfill in order to be allowed on the mirror
network -- but not necessarily as an 'overall' requirement -- a
requirement that a port will always need to fulfill if it wants to be
part of a stable release, even if it's already on the mirror network.
Those would look like this:
Initial:
- must be publically available to buy new
- must be freely usable (without NDA)
- must be able to run a buildd 24/7 without crashing
- must have an actual, working buildd
- must include basic UNIX functionality
- 5 developers must send in a signed request for the addition
- must demonstrate to have at least 50 users
- must be able to keep up with unstable with 2 buildd machines, and must
have one redundant buildd machine
Overall:
- must have successfully compiled 98% of the archive's source (excluding
arch-specific packages)
- must have a working, tested installer
- security team, DSA, and release team must not veto inclusion
- must be a developer-accessible debian.org machine for the
architecture
- binary packages must be built from unmodified Debian source
- binaries must have been built and signed by official Debian
Developers
In addition to those points, we also agreed on the following:
* The m68k porters (i.e., myself) would test out a buildd running with
distcc so that a cost/benefit analysis of such a setup could be made.
A full explanation of why such an analysis is required would take us
too far; suffice to say that it isn't entirely guaranteed that there
would be a noticeable performance increase, while the cost to maintain
such a setup (as opposed to a regular buildd setup) is nontrivial.
* All ports must 'requalify'; that is, they must also comply with the
set of initial requirements once, probably before etch releases.
However, if one of the already existing ports satisfies most of the
requirements from this list of initial requirements but there are a
few that they cannot comply with for technical reasons, they can
request exceptions.
And that about sums it up. We think the last word most certainly has not
been said about this proposal (yet), but are happy that it could be
discussed in an open, civilized manner. Hopefully this will lead to an
even better-quality Debian in the future.
Regards,
[1] http://lists.debian.org/debian-devel-announce/2005/03/msg00012.html
[2] The fact that it took over a month to produce this announcement has
everything to do with some post-meeting confusion and me slacking
while producing this text. Sorry about that.
--=20
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond
--qMm9M+Fa2AknHoGS
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFDB9/APfwsYq950p4RAtsTAKCLAi2+Sc3BCYGtK1ing06gVS3JIgCfQQUN
HfwpV7Xph8KOMkSvEFhg0F4=
=xMUa
-----END PGP SIGNATURE-----
--qMm9M+Fa2AknHoGS--
--
To UNSUBSCRIBE, email to [e-mail:debian-devel-announce-REQUEST@lists.debian.org]
with a subject of "unsubscribe". Trouble? Contact [e-mail:listmaster@lists.debian.org]
|
