On Mon, Aug 22, 2005 at 10:19:38AM +0200, Ingo Juergensmann wrote: > > 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? TTBOMK, the security team have always said that they are committed to providing security updates for everything in stable/main. You are arguing that we, and our users, should be perfectly comfortable with the idea of shipping a low-quality port for which this guarantee does not hold. I don't see any reason at all why that should be an acceptable answer; if a port's stable users really don't care about security updates, then the technical justification for including it in the release, instead of doing separate snapshot releases, becomes quite slim. > > 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? I don't know if this is a language gap or what, but dude, it's a *veto*. The whole *point* is that these are the teams that bear most of the burden if a port isn't being looked after, and they should therefore have a direct say in whether such a port is included, and it shouldn't be automatically allowed in just because the manner in which it's in shitty shape isn't something anyone thought of when putting together this list. Exercising a veto means that, in that team's expert opinion, it is not in the interest of the Debian project to treat that port as a release candidate. The procedure if you object is to *change that expert opinion* -- preferably by addressing the cause for the veto, though it seems that there are at least some people around who would much rather antagonize the release team/ftpmasters until they resign in disgust than actually step up and *work* on the ports they're so keen to defend. > > 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. Uh, no, it wasn't. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. vorlon@debian.org http://www.debian.org/
Attachment:
signature.asc
Description: Digital signature