On Sun, Aug 21, 2005 at 03:58:24AM +0200, Wouter Verhelst wrote: > 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.
Where's the definition of "natural end of life"? Who defines when this state is reached? The porters (how many of them then?)? What is meant with "no longer possible ... to support it"? > 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). According to Joeys blog (http://www.infodrom.org/~joey/log/?200508201755): "I also have the impression that there is no buildd for m68k and s390 for sarge-proposed updates - or there's another reason the updated vim is not available on these architectures." There still seems to be an incomplete buildd infrastructure. Why is that and why is that not communicated properly? All I see is a vaque assumption that the infrastructure is in place or it isn't, but nobody seems to know that for sure. And even more there seems to be a security team and infrastructure for stable and testing and both seem to have nothing to do with eachother, i.e. are the machines for both are identical or what? > 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. I don't see the problem with having as much autobuilders as the porters can handle? ("can handle" = handle the buildd logs, keep them running, supply them with hardware, etc.) > 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). Well, it seems nice to debate the need of autobuilder redundancy, but how about buildd admin redundancy? There has been problems with that for several archs in the past. How should this been addressed? > 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 case, when there might be a package with an unsolvable security issue for a port (perhaps because it needs a newer gcc or toolchain, because the released one has an issue like ICE or so), that package could be dropped from the release for that arch. Why dropping the whole arch then? > 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. I would like to see a detailed rationale under what circumstances such as veto might be raised *beforehand* anyone can veto something. It should be clear what requirements must be fulfilled so that a team can veto something. Otherwise you'll end always with discussions where the vetoing team says this and the other team (like porters) say that. And what if someone has objections against that veto? What procedure will handle this situation then? > 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. How should this demonstration should be achieved? What is the procedure for this? When I grep my /etc/passwd I have 28 users for m68k on my own, but that machine just counts as one user on popcon.d.o. > 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. ... and this paragraph makes clear, that you just can't use popcon for that issue. So, how shall those users be counted? > 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. During the original vancouver proposal discussion the mirror network problem was said to be the reason for the vancouver proposal. So, I expected a more detailed info about this issue and how it would be solved (and when). When the reason for the vancouver proposal is "just" mirror space on "some" mirrors, why should this be addressed by a potential drop of archs anyway? Why don't let the mirrors just mirror what they want? Nobody forces a mirror admin that he *has* to be a primary mirror, right? I have absolutely no problems with mirrors that don't carry all archs as long as there are several mirrors that do. > 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 Again, I don't see the point in limiting the numbers of buildd machines as long as the porters can handle them. > have one redundant buildd machine Why just one? Or should this have been "at least one"? > Overall: > - must have successfully compiled 98% of the archive's source (excluding > arch-specific packages) I believe 98% is way too high. When I do a grep "up-to-date" unstable/listdir/*_stats I get: unstable/listdir/alpha_stats: 93.17% (5578) up-to-date, 93.17% (5578) including uploaded unstable/listdir/amd64_stats: 95.52% (5924) up-to-date, 95.52% (5924) including uploaded unstable/listdir/arm_stats: 94.18% (5616) up-to-date, 94.21% (5618) including uploaded unstable/listdir/hppa_stats: 90.70% (5385) up-to-date, 90.70% (5385) including uploaded unstable/listdir/i386_stats: 99.87% (6258) up-to-date, 99.87% (6258) including uploaded unstable/listdir/ia64_stats: 96.16% (5728) up-to-date, 96.16% (5728) including uploaded unstable/listdir/m32r_stats: 0.00% up-to-date, 0.00% including uploaded unstable/listdir/m68k_stats: 91.13% (5415) up-to-date, 91.13% (5415) including uploaded unstable/listdir/mips_stats: 96.47% (5758) up-to-date, 96.47% (5758) including uploaded unstable/listdir/mipsel_stats: 96.00% (5688) up-to-date, 96.00% (5688) including uploaded unstable/listdir/powerpc_stats: 96.90% (5855) up-to-date, 96.90% (5855) including uploaded unstable/listdir/s390_stats: 95.39% (5692) up-to-date, 95.39% (5692) including uploaded unstable/listdir/sparc_stats: 96.61% (5787) up-to-date, 96.61% (5787) including uploaded As you can see only i386 would satisfy this requirement. For m68k it's quite sure that it never reaches the 98% mark, just because of the high number of buildds. There is currently a total of 5942 packages, but 132 are marked as building and 143 as needs-build. 2% of 5942 packages would be 119 packages (118.84 exactly). So, with 132 packages marked as building, you already exceed the allowed maximum of 2% missing packages. This 98% mark is just arbitrary... > - must have a working, tested installer What is meant by "working, tested installer"? What are the requirements to qualify as "working, tested"? Will any kind of installer be ok or is d-i mandatory for that? > - security team, DSA, and release team must not veto inclusion What are possible reasons for a veto? Be define beforehand. > - must be a developer-accessible debian.org machine for the > architecture A single machine is sufficient? Should this be a public available d.o machine or is limited access sufficient? > - binary packages must be built from unmodified Debian source Uhm? When there is a new arch upcoming, they need to modifiy the Debian source, at least sometimes, right? This counts especially for the inclusion of there arch tag in the arch: line of the package. And I think, a new port needs to patch the packages anyway, as well as already establised ports. Or do you mean by "overall requirements" just the already established ports? My interpretation of "overall" is that this counts for both (new and old ports). > - binaries must have been built and signed by official Debian > Developers This has been always the case, right? > 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. Oh well, the current distcc on m68k simply doesn't work. Been there, done that... > * 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. The above contradicts to: > 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; Either all existing ports won't need to requalify or they do. Otherwise you get a point that is not exactly defined and thus a potential point where opinions might collide. What are the requirements for those exceptions? Who are about to grant them? Won't the teams veto? Overall, I thing this new vancouver proposal (or whatever you name it) is a little bit unprecise (or as I would say in German: "wischiwaschi" :). I miss exact definitions of procedures and such. Of course I know it's difficult to give those definitions in such a proposal, but it would have been nice when those definitions would be worked out and voted about *before* the proposal is implemented. This is valid especially for the veto thing. A vague veto right is not a good thing and might be abused (or give the impression to others of being abused). -- Ciao... // Fon: 0381-2744150 Ingo \X/ SIP: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]