Results of the meeting in Helsinki about the Vancouver proposal

Posted by bstadil on Aug 21, 2005 9:58 AM EDT
Mailing list; By Wouter Verhelst <wouter@debian.org>
Mail this story
Print this story

"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]

  Nav
» Read more about: Story Type: News Story

« Return to the newswire homepage

This topic does not have any threads posted yet!

You cannot post until you login.