[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Results of the meeting in Helsinki about the Vancouver proposal

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

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

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

Reply to: