Re: Constitutional issues in the wake of Lenny

[Gaudenz Steinlin]

On Sun, Mar 15, 2009 at 08:49:51AM +, Matthew Johnson wrote:
> On Sat Mar 14 19:40, Russ Allbery wrote:
> > It makes an advisory project statement about the project interpretation of
> > the FD.  DDs can choose to follow that interpretation or not as they
> > choose in their own work, but I would expect that people who didn't have a
> > strong opinion would tend to follow the opinion of the majority in the
> > project as determined by the GR.  But if a DD decides that they flatly
> > don't agree with that interpretation, the GR doesn't override them unless
> > someone proposes and passes another one with a 3:1 majority.
> > 
> > Does that make it clearer?
> 
> Well, what I'm thinking about is the whole reason we tend to have GRs
> is because one DD flatly doesn't agree with an interpretation. In which
> case, how has the GR helped the situation. For example, the Lenny
> firmware GR, at least one of those options would fall into this
> category, the proposer explicitly said they weren't amending an FD, so
> it would just be a position statement, but then we've not actually
> solved anything if it wins.

In the case of the GR before lenny it would clearly have solved the
problem. If any of the options which supported the actions of the
release team wins (as it was the case), then the release team would have
had the explicit support of the project for it's decisions. The GR would
be a sign that the majority of the project agrees with the release teams
interpretation of the FDs without forcing anyone to accept this
interpretation for his own work. The position statement would have the
sole effect, that it is no longer possible to enforce a diverging
interpretation upon others (as was tried with the pre lenny GR).

Personally I think that we should drop the supermajority requirements
alltogether. This would solve all the ambiguities. IMHO supermajority
requirements are a bit odd in our Condorcet voting system. 

Gaudenz

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Constitutional issues in the wake of Lenny

[Russ Allbery]

Matthew Johnson  writes:

> 4. Option X is declared not to be in conflict with a foundation document (?)
> 5. Option X conflicts with a foundation document, but explicitly doesn't
>want to override the FD (?)

This is not a meaningful statement about a GR currently.  In order for
this to be a meaningful statement, we would have to amend the constitution
to create a person who is responsible for determining that such a conflict
exists.  Right now, there is no person who can make the above judgement,
so making it a distinct case isn't particularly useful.

> 6. Option X would appear that it might contradict an FD, but doesn't say
>which of 2-5 it is.

> My point of view would be that 3 requires 3:1, 4 does not and that votes
> of type 5 or 6 should not be allowed to run until they are clarified.

I agree with all of those statements except for 5, which I don't believe
exists.  5 is actually identical to 4 in our current system.

If, down the road, we create an officer responsible for ruling on
conflicts around Foundation Documents, then 5 could exist if the statement
in the GR was in conflict with their ruling.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Constitutional issues in the wake of Lenny

[Matthew Johnson]

This seems to have stalled a bit, so trying to get bark on track here.

There seems to be several sorts of vote here:

1. Option X conforms to a foundation document (clearly not 3:1)
2. Option X changes a foundation document (clearly 3:1)
3. Option X overrides a foundation document, possibly temporarily (?)
4. Option X is declared not to be in conflict with a foundation document (?)
5. Option X conflicts with a foundation document, but explicitly doesn't
   want to override the FD (?)
6. Option X would appear that it might contradict an FD, but doesn't say
   which of 2-5 it is.

1. and 2. are what we wish every vote were like.

3. is things like "we agree that the kernel modules aren't free, but
we'll ship them anyway" or "we'll ship them for this release".

4. is things like "we think that firmware can be its own source, so
shipping blobs is fine"

On Mon Mar 16 23:06, Kurt Roeckx wrote:

> If you have an option saying "Allow Lenny to release with
> firmware blobs.  This does not override the DFSG", I can only
> see that make sense if it really means: "firmware blobs are not a
> DFSG violation", and the "Lenny" part doesn't make sense.

This would be 5, and as you say, I don't think it makes much sense.

My point of view would be that 3 requires 3:1, 4 does not and that votes
of type 5 or 6 should not be allowed to run until they are clarified.

Incidentally, I'm not intending to answer the question here of whether
we can release with blobs or dfsg violations, but what the vote about
this should look like.

-- 
Matthew Johnson


signature.asc
Description: Digital signature

Re: Constitutional issues in the wake of Lenny

[Kurt Roeckx]

On Mon, Mar 16, 2009 at 11:52:33PM +0100, Wouter Verhelst wrote:
> 
> The point is, language isn't math, and as a result the same
> text will often mean one thing to one person, and something entirely
> else to another.

Which is my point.  And people do have different opinions about
it.  So you now leave it up to the secretary to interprete it.  It
would be better if proposals would not leave a part open to
interpretation.


Kurt


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Constitutional issues in the wake of Lenny

[Charles Plessy]

Dear all,

in my impression, the problem in the vote for the Lenny release is that at the
end it became an aggreagation of things of which nobody was satisfied, and of
which nobody was feeling responsible anymore. To avoid this, I propose three
actions.

First, establishing the impartiality of the Secretary by not letting him taking
the initiative of issuing constitutional statements. It may seem paradoctical
at first, but if there is a subject that is matter of interpretation, there
must be more than one person that feels that it is necessary. If the Secretary
himself can not be the one who ask for clarification, nobody can suspect him to
use his charge to push his personal opinions. That is the way many
constitutional courts work in western and westernized states. In the case of
the Lenny GR, it means that somebody else would have taken the blame for the
mess introduced by supermajority requests, which would have protected Manoj and
our institutions.

Second, not mixing simple GRs with formal modifications of our Constitution and
foundation documents. It is a very stressful situation if in the context of an
already difficult discussion the Project wakes up one morning with a clock
ticking for a constitutional amendment in two weeks. I think that modifications
to the constitution and the foundation documents should be announced in
advance, planned and discussed with a clear goal, and I would support
modifications of the constitution that clearly separate simple GRs with
supermajority GRs, where all the options except "None of the above" would
require supermajority. This means letting the DDs vote for unconstitutional
statements in simple GRs, just like our parliaments do with our laws everyday.
This said, there are multiple protections against this: we are benevols and
nobody can force a DD to do some work if he does not agree, and there are the
DPL, the Secretary and the Technical Comittee, who have the authority and in
some cases the power to block the implementation of blatantly wrong decision.

Third, giving more leadership to the GR proposer. I already proposed this last
year, and read Ian's answers with interest. After being convinced by his
arguments a few monthes, I reverted to my original opinion :) Each vote is an
investment of time and effort, and I think that it is important that somebody
feels responsible for its success, which means: takes the blame if the
situation is worse after the vote than before. By letting the proposer of a GR
refuse some amendments, we can make him feel responsible for the vote process
he started. What if he refuses one that has the favor of many? Probably a
"Further disucssion" result, followed by another GR, which means a personal
failure.


I have tried to keep things short, so it may look simplistic, but if there are
people intersted in refining the proposition or parts of it, we can work
together on a text that looks more like a patch.


Lastly, if there is some constitutional amendment, we can do some minor
clarifications by the way. For instance:

 - In A.2.1 there is "The proposer or a sponsor of a motion or an amendment may
   call for a vote", but nowhere defines what a "motion" is.

 - According to A.2.2, "The proposer or any sponsor of a resolution may call
   for a vote on that resolution and all related amendments." But then, what
   kind of vote can be called by the proposers of amendments in A.2.1 ?


Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Constitutional issues in the wake of Lenny

[Wouter Verhelst]

On Mon, Mar 16, 2009 at 11:06:49PM +0100, Kurt Roeckx wrote:
> On Mon, Mar 16, 2009 at 08:13:05PM +0100, Wouter Verhelst wrote:
> > This is an interpretation of the SC, not the DFSG, and a perfectly valid
> > position statement.
> 
> That can be seen as an interpretation of SC #4 (our priorities are
> our users and free software).  But I don't see it offer an
> interpretation for SC #1 (Debian will remain 100% free).

Not that it matters anymore now (what with the vote being over and all),
but:

"remain" is not the same thing as "become". Etch wasn't 100% free;
neither was sarge, and with woody we had similar problems. I wasn't
around for the potato release, so I can't speak for that one.

The point being, this seems like progress toward a goal that Debian be
100% free software.

It would be possible to interpret the SC as a description of a utopia to
which we want to evolve; one which we've not quite arrived at yet, but
where we very much would like to get.

For clarity: I'm not saying that any of the above represents my personal
opinion. The point is, language isn't math, and as a result the same
text will often mean one thing to one person, and something entirely
else to another. This is why legalese exists; to remove as much
ambiguity as possible from a legal text, those texts are written using
formulations that are well-defined in the context, or that do not have a
lot of ambiguity to start with.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Constitutional issues in the wake of Lenny

[Russ Allbery]

Kurt Roeckx  writes:

> If you have an option saying "Allow Lenny to release with firmware
> blobs.  This does not override the DFSG", I can only see that make sense
> if it really means: "firmware blobs are not a DFSG violation", and the
> "Lenny" part doesn't make sense.

> The same goes for "Allow Lenny to release with known DFSG violations.
> This does not override the SC."  That would be the same as "Allow
> releases with known DFSG violations".

I agree.  However, I'm very reluctant to say that the Secretary should
prevent the project from voting on proposals that don't make sense,
provided that they're constitutionally clear.

I would vote against both of those proposals as phrased because I think
they're self-contradictory and they're not interpretations that I think we
can make, despite the fact that I was on the side favoring releasing lenny
in the previous GR.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Constitutional issues in the wake of Lenny

[Kurt Roeckx]

On Mon, Mar 16, 2009 at 08:13:05PM +0100, Wouter Verhelst wrote:
> On Mon, Mar 16, 2009 at 07:43:45PM +0100, Kurt Roeckx wrote:
> > I have no problem with considering the following to be position
> > statements:
> > - Firmware blobs are not a DFSG violation
> > - Allow releases with known DFSG violations
> > 
> > They are interpreting the DFSG/SC.
> 
> Actually, they are interpreting the DFSG, not the SC.

That is about 2 different issues.

The first is about firmware blobs.  There are probably many
different ways to look at this, and depending on what you say
exactly you can get some firmware blobs to comply with the DFSG.

The second is about releases and DFSG violations.  The
interpretation of the DFSG is not being questioned here.  Just
that we can make a release with DFSG violation or not.  Note that
there are more DFSG violations than just the firmware blobs.

> > But these do not seem like a position statement to me:
> > - Allow Lenny to release with firmware blobs
> > - Allow Lenny to release with known DFSG violations
> > 
> > It does not say how to interprete the DFSG/SC,
> 
> It does.

Those statements on themself do not.

> > and both seem to temporary override the Foundation Document.
> 
> No, they don't.
> 
> For instance, Proposal B on the latest vote read, in full:
> 
> | Allow Lenny to release with proprietary firmware
> | 
> | 1. We affirm that our Priorities are our users and the free software
> | community (Social Contract #4);
> | 2. We acknowledge that there is a lot of progress in the kernel firmware
> | issue; most of the issues that were outstanding at the time of the last
> | stable release have been sorted out. However, new issues in the kernel
> | sources have cropped up fairly recently, and these new issues have not
> | yet been addressed;
> | 3. We assure the community that there will be no regressions in the
> | progress made for freedom in the kernel distributed by Debian relative
> | to the Etch release in Lenny (to the best of our knowledge as of 1
> | November 2008);
> | 4. We give priority to the timely release of Lenny over sorting every
> | bit out; for this reason, we will treat removal of sourceless firmware
> | as a best-effort process, and deliver firmware as part of Debian Lenny
> | as long as we are legally allowed to do so.
> 
> While it doesn't do so explicitly, the statement implicitly confirms
> that "firmware blobs" violate the DFSG; however, it explicitly states
> that dealing with this, while important, does not weigh up against the
> problems caused for our users by delaying the release.
> 
> This is an interpretation of the SC, not the DFSG, and a perfectly valid
> position statement.

That can be seen as an interpretation of SC #4 (our priorities are
our users and free software).  But I don't see it offer an
interpretation for SC #1 (Debian will remain 100% free).


Kurt


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Constitutional issues in the wake of Lenny

[Kurt Roeckx]

On Mon, Mar 16, 2009 at 12:00:10PM -0700, Russ Allbery wrote:
> Kurt Roeckx  writes:
> 
> > But these do not seem like a position statement to me:
> > - Allow Lenny to release with firmware blobs
> > - Allow Lenny to release with known DFSG violations
> >
> > It does not say how to interprete the DFSG/SC, and both
> > seem to temporary override the Foundation Document.
> 
> Well, this is the reason why, in my proposal, I require that the GR
> explicitly say one way or the other whether it's overriding a FD if it's
> at all ambiguous.  I don't believe either of those proposals should be
> allowed to go to vote until they explicitly say either that they're
> temporarily overriding a FD or that they believe that the release is
> consistent with the FD as written and are therefore a non-binding position
> statement on how the project interprets the FD.
> 
> Basically, what I'm saying is that I'm not very worried about the case of
> a non-binding position statement saying that it doesn't override an FD but
> saying something completely contradictory to it.  First, I don't think
> such a GR would pass, and second, even if it does, it's non-binding, so
> DDs who completely disagree with it aren't bound to follow it.

If you have an option saying "Allow Lenny to release with
firmware blobs.  This does not override the DFSG", I can only
see that make sense if it really means: "firmware blobs are not a
DFSG violation", and the "Lenny" part doesn't make sense.

The same goes for "Allow Lenny to release with known DFSG
violations.  This does not override the SC."  That would be the
same as "Allow releases with known DFSG violations".


Kurt


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Constitutional issues in the wake of Lenny

[Wouter Verhelst]

On Mon, Mar 16, 2009 at 07:43:45PM +0100, Kurt Roeckx wrote:
> I have no problem with considering the following to be position
> statements:
> - Firmware blobs are not a DFSG violation
> - Allow releases with known DFSG violations
> 
> They are interpreting the DFSG/SC.

Actually, they are interpreting the DFSG, not the SC.

> But these do not seem like a position statement to me:
> - Allow Lenny to release with firmware blobs
> - Allow Lenny to release with known DFSG violations
> 
> It does not say how to interprete the DFSG/SC,

It does.

> and both seem to temporary override the Foundation Document.

No, they don't.

For instance, Proposal B on the latest vote read, in full:

| Allow Lenny to release with proprietary firmware
| 
| 1. We affirm that our Priorities are our users and the free software
| community (Social Contract #4);
| 2. We acknowledge that there is a lot of progress in the kernel firmware
| issue; most of the issues that were outstanding at the time of the last
| stable release have been sorted out. However, new issues in the kernel
| sources have cropped up fairly recently, and these new issues have not
| yet been addressed;
| 3. We assure the community that there will be no regressions in the
| progress made for freedom in the kernel distributed by Debian relative
| to the Etch release in Lenny (to the best of our knowledge as of 1
| November 2008);
| 4. We give priority to the timely release of Lenny over sorting every
| bit out; for this reason, we will treat removal of sourceless firmware
| as a best-effort process, and deliver firmware as part of Debian Lenny
| as long as we are legally allowed to do so.

While it doesn't do so explicitly, the statement implicitly confirms
that "firmware blobs" violate the DFSG; however, it explicitly states
that dealing with this, while important, does not weigh up against the
problems caused for our users by delaying the release.

This is an interpretation of the SC, not the DFSG, and a perfectly valid
position statement.

There's a difference between stating "This is non-free, but we're not
going to worry about that for now so as to allow our users to actually
get a release" and "Yes, this is non-free. Who cares."

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Constitutional issues in the wake of Lenny

[Russ Allbery]

Kurt Roeckx  writes:

> But these do not seem like a position statement to me:
> - Allow Lenny to release with firmware blobs
> - Allow Lenny to release with known DFSG violations
>
> It does not say how to interprete the DFSG/SC, and both
> seem to temporary override the Foundation Document.

Well, this is the reason why, in my proposal, I require that the GR
explicitly say one way or the other whether it's overriding a FD if it's
at all ambiguous.  I don't believe either of those proposals should be
allowed to go to vote until they explicitly say either that they're
temporarily overriding a FD or that they believe that the release is
consistent with the FD as written and are therefore a non-binding position
statement on how the project interprets the FD.

Basically, what I'm saying is that I'm not very worried about the case of
a non-binding position statement saying that it doesn't override an FD but
saying something completely contradictory to it.  First, I don't think
such a GR would pass, and second, even if it does, it's non-binding, so
DDs who completely disagree with it aren't bound to follow it.

nWhat I want to do is get out of the deadlock where the Secretary feels
obligated to make a ruling on whether or not the interpretation is correct
when that may be the whole point of the GR.  Instead, the GR should
explicitly say one way or the other whether it's intended to change the
FD.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Constitutional issues in the wake of Lenny

[Kurt Roeckx]

On Sat, Mar 14, 2009 at 09:45:58PM -0700, Russ Allbery wrote:
> Kurt Roeckx  writes:
> > On Sat, Mar 14, 2009 at 12:07:03PM -0700, Russ Allbery wrote:
> 
> >>  6 Anything which overrides a Foundation Document modifies it to contain
> >>that expecific exception and must say so in the proposal before the
> >>vote proceeds.  Such overrides require a 3:1 majority.
> 
> >>A GR which explicitly states that it does not override a Foundation
> >>Document but instead offers a project interpretation of that Foundation
> >>Document does not modify the document and therefore does not require a
> >>3:1 majority.  This is true even if the Secretary disagrees with the
> >>interpretation.  However, such intepretations are not binding on the
> >>project.
> 
> > Would that be a "position statement"?  That only seems to have a
> > normal majority requirement.
> >
> > The problem I have with position statements is that they're not
> > binding.  But it atleast gives the secretary a consensus to base
> > decisions on for other votes.
> 
> Yup, exactly, something that fit the last paragraph would be a position
> statement.

I have no problem with considering the following to be position
statements:
- Firmware blobs are not a DFSG violation
- Allow releases with known DFSG violations

They are interpreting the DFSG/SC.

But these do not seem like a position statement to me:
- Allow Lenny to release with firmware blobs
- Allow Lenny to release with known DFSG violations

It does not say how to interprete the DFSG/SC, and both
seem to temporary override the Foundation Document.


Kurt


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Constitutional issues in the wake of Lenny

[Steve Langasek]

On Sun, Mar 15, 2009 at 08:49:51AM +, Matthew Johnson wrote:
> Maybe I just see GRs as a last resort where we really really need a
> definitive answer.

Except they aren't; they're used any time six developers *think* we need a
definitive answer, which is not the same thing.

> Certainly after we've gone through the whole process I'd like all that
> effort to have resulted in a solution everyone has to follow...

Requiring supermajorities doesn't ensure that.  What says that the outcome
won't be "Further discussion" instead?  Then you've gone to all that effort
to result in no solution at all.

In any case, the desire to minimize the number of GR round-trips doesn't
justify preventing other DDs from proposing position statements if they
choose to, even when you consider those position statements to contradict
the Foundation Documents.  You *always* have the option of proposing an
amendment that explicitly modifies the Foundation Document instead.  Maybe
you'll persuade the proposer to accept the amendment; maybe you'll end up on
the ballot as a separate option and the developers will agree to modify the
Foundation Document; or maybe your option will fail to reach supermajority,
and we'll instead have a non-binding position statement.  Why shouldn't all
of these options be open to developers?

Even if you don't give developers the option of formally ratifying position
statements that interpret the Foundation Documents, developers are still
going to do their own interpreting of these documents, and more often than
not they're going to assume that the rest of the project agrees with them.
So I don't see any way that permitting such position statements is *worse*
than having Further Discussion win.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Overriding vs Amending vs 'Position statement' [Was: Re: Constitutional issues in the wake of Lenny]

[Raphael Hertzog]

On Sat, 14 Mar 2009, Matthew Johnson wrote:
> On Sat Mar 14 14:23, Kurt Roeckx wrote:
> > 
> > I'm currently inclined to interprete it so that anything that
> > seems to modify an interpretation will require an explicit change
> > in some document.  But I'm not sure it's in my power to refuse
> > an option that doesn't do so.  So that would be option 2 above.
> 
> Yeah, this is what I think too, but Manoj got a lot of flack about it,
> hence why I want to make it explicit.

It depends what "some document" means. If it's a foundation document, then
it's all wrong for me. If it's some external document that explains how
we interpret the foundation documents, then it's ok.

Cheers,
-- 
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Constitutional issues in the wake of Lenny

[Matthew Johnson]

On Sat Mar 14 19:40, Russ Allbery wrote:
> It makes an advisory project statement about the project interpretation of
> the FD.  DDs can choose to follow that interpretation or not as they
> choose in their own work, but I would expect that people who didn't have a
> strong opinion would tend to follow the opinion of the majority in the
> project as determined by the GR.  But if a DD decides that they flatly
> don't agree with that interpretation, the GR doesn't override them unless
> someone proposes and passes another one with a 3:1 majority.
> 
> Does that make it clearer?

Well, what I'm thinking about is the whole reason we tend to have GRs
is because one DD flatly doesn't agree with an interpretation. In which
case, how has the GR helped the situation. For example, the Lenny
firmware GR, at least one of those options would fall into this
category, the proposer explicitly said they weren't amending an FD, so
it would just be a position statement, but then we've not actually
solved anything if it wins.

Maybe I just see GRs as a last resort where we really really need a
definitive answer. Certainly after we've gone through the whole process
I'd like all that effort to have resulted in a solution everyone has to
follow...

Issuing nebulous position statements is what we elect a DPL for, isn't
it (-;

Matt

-- 
Matthew Johnson


signature.asc
Description: Digital signature

Re: Constitutional issues in the wake of Lenny

[Russ Allbery]

Kurt Roeckx  writes:
> On Sat, Mar 14, 2009 at 12:07:03PM -0700, Russ Allbery wrote:

>>  6 Anything which overrides a Foundation Document modifies it to contain
>>that expecific exception and must say so in the proposal before the
>>vote proceeds.  Such overrides require a 3:1 majority.

>>A GR which explicitly states that it does not override a Foundation
>>Document but instead offers a project interpretation of that Foundation
>>Document does not modify the document and therefore does not require a
>>3:1 majority.  This is true even if the Secretary disagrees with the
>>interpretation.  However, such intepretations are not binding on the
>>project.

> Would that be a "position statement"?  That only seems to have a
> normal majority requirement.
>
> The problem I have with position statements is that they're not
> binding.  But it atleast gives the secretary a consensus to base
> decisions on for other votes.

Yup, exactly, something that fit the last paragraph would be a position
statement.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Constitutional issues in the wake of Lenny

[Kurt Roeckx]

On Sat, Mar 14, 2009 at 12:07:03PM -0700, Russ Allbery wrote:
> Matthew Johnson  writes:
> 
> > As Luk says, tackling these one at a time is probably best. So, first up
> > is (bullets numbered so that I can refer to them):
> 
> >> Positions (in no particular order):
> >> 
> >> 1 The supermajority is rubbish and we should drop it entirely, so it 
> >> doesn't
> >>   matter what the difference is.
> >> 2 Anything which overrides a FD implicitly modifies it to contain that
> >>   specific exception, even if it's not specified in the GR, so always needs
> >>   3:1.
> >> 3 Actually, the Social Contract isn't binding per-se, individual delegates/
> >>   developers are aiming for it as a goal, but can interpret it as they see
> >>   fit.
> >> 4 The DFSG doesn't automatically trump our users, we'll cope with DFSG
> >>   issues if it's needed for things to work.
> >> 5 Single exceptions don't require supermajority, but permanent changes do
> 
> I'm not sure that I see my position in there, which is a combination of 2
> and 3.  The rule I would like to see is:
> 
>  6 Anything which overrides a Foundation Document modifies it to contain
>that expecific exception and must say so in the proposal before the
>vote proceeds.  Such overrides require a 3:1 majority.
> 
>A GR which explicitly states that it does not override a Foundation
>Document but instead offers a project interpretation of that Foundation
>Document does not modify the document and therefore does not require a
>3:1 majority.  This is true even if the Secretary disagrees with the
>interpretation.  However, such intepretations are not binding on the
>project.

Would that be a "position statement"?  That only seems to have a
normal majority requirement.

The problem I have with position statements is that they're not
binding.  But it atleast gives the secretary a consensus to base
decisions on for other votes.


Kurt


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Constitutional issues in the wake of Lenny

[Russ Allbery]

Matthew Johnson  writes:
> On Sat Mar 14 12:07, Russ Allbery wrote:

>>A GR which explicitly states that it does not override a Foundation
>>Document but instead offers a project interpretation of that
>>Foundation Document does not modify the document and therefore does
>>not require a 3:1 majority.  This is true even if the Secretary
>>disagrees with the interpretation.  However, such intepretations are
>>not binding on the project.

> What does it mean to vote for something that contradicts an FD,

I didn't say that it contradicts an FD.  I think that in most cases where
this is an issue, whether it contradicts an FD is going to be a matter of
opinion.  In some cases, the whole *point* of the GR is to express a
majority view that this interpretation does not contradict the FD.

> but doesn't modify it and the result of it is not binding? How has this
> improved the position before the vote?

It makes an advisory project statement about the project interpretation of
the FD.  DDs can choose to follow that interpretation or not as they
choose in their own work, but I would expect that people who didn't have a
strong opinion would tend to follow the opinion of the majority in the
project as determined by the GR.  But if a DD decides that they flatly
don't agree with that interpretation, the GR doesn't override them unless
someone proposes and passes another one with a 3:1 majority.

Does that make it clearer?

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Constitutional issues in the wake of Lenny

[Matthew Johnson]

On Sat Mar 14 12:07, Russ Allbery wrote:
>A GR which explicitly states that it does not override a Foundation
>Document but instead offers a project interpretation of that Foundation
>Document does not modify the document and therefore does not require a
>3:1 majority.  This is true even if the Secretary disagrees with the
>interpretation.  However, such intepretations are not binding on the
>project.

What does it mean to vote for something that contradicts an FD, but
doesn't modify it and the result of it is not binding? How has this
improved the position before the vote?

Matt

-- 
Matthew Johnson


signature.asc
Description: Digital signature

Re: Overriding vs Amending vs 'Position statement' [Was: Re: Constitutional issues in the wake of Lenny]

[Matthew Johnson]

On Sat Mar 14 14:23, Kurt Roeckx wrote:
> 
> I'm currently inclined to interprete it so that anything that
> seems to modify an interpretation will require an explicit change
> in some document.  But I'm not sure it's in my power to refuse
> an option that doesn't do so.  So that would be option 2 above.

Yeah, this is what I think too, but Manoj got a lot of flack about it,
hence why I want to make it explicit.

Matt

-- 
Matthew Johnson


signature.asc
Description: Digital signature

Re: Constitutional issues in the wake of Lenny

[Russ Allbery]

Matthew Johnson  writes:

> As Luk says, tackling these one at a time is probably best. So, first up
> is (bullets numbered so that I can refer to them):

>> Positions (in no particular order):
>> 
>> 1 The supermajority is rubbish and we should drop it entirely, so it doesn't
>>   matter what the difference is.
>> 2 Anything which overrides a FD implicitly modifies it to contain that
>>   specific exception, even if it's not specified in the GR, so always needs
>>   3:1.
>> 3 Actually, the Social Contract isn't binding per-se, individual delegates/
>>   developers are aiming for it as a goal, but can interpret it as they see
>>   fit.
>> 4 The DFSG doesn't automatically trump our users, we'll cope with DFSG
>>   issues if it's needed for things to work.
>> 5 Single exceptions don't require supermajority, but permanent changes do

I'm not sure that I see my position in there, which is a combination of 2
and 3.  The rule I would like to see is:

 6 Anything which overrides a Foundation Document modifies it to contain
   that expecific exception and must say so in the proposal before the
   vote proceeds.  Such overrides require a 3:1 majority.

   A GR which explicitly states that it does not override a Foundation
   Document but instead offers a project interpretation of that Foundation
   Document does not modify the document and therefore does not require a
   3:1 majority.  This is true even if the Secretary disagrees with the
   interpretation.  However, such intepretations are not binding on the
   project.

   In the event that it's unclear whether a particular GR falls into the
   first group or the second group, the vote should not proceed until this
   has been clarified in the GR.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Overriding vs Amending vs 'Position statement' [Was: Re: Constitutional issues in the wake of Lenny]

[Kurt Roeckx]

On Sat, Mar 14, 2009 at 12:03:08PM +, Matthew Johnson wrote:
> As Luk says, tackling these one at a time is probably best. So, first up
> is (bullets numbered so that I can refer to them):
> 
> On Mon Mar 02 00:23, Matthew Johnson wrote: 
> > Overriding vs Amending vs 'Position statement'
> > 
> > When a GR has an option which contradicts one of the foundation documents, 
> > but
> > doesn't explicitly amend it; does this count as amending it? If it does not,
> > then how is this reconciled with the fact that we have just agreed to do
> > something which would contravene our own foundation documents?
> > 
> > Positions (in no particular order):
> > 
> > 1 The supermajority is rubbish and we should drop it entirely, so it 
> > doesn't
> >   matter what the difference is.
> > 2 Anything which overrides a FD implicitly modifies it to contain that
> >   specific exception, even if it's not specified in the GR, so always 
> > needs
> >   3:1.
> > 3 Actually, the Social Contract isn't binding per-se, individual 
> > delegates/
> >   developers are aiming for it as a goal, but can interpret it as they 
> > see
> >   fit.
> > 4 The DFSG doesn't automatically trump our users, we'll cope with DFSG
> >   issues if it's needed for things to work.
> > 5 Single exceptions don't require supermajority, but permanent changes 
> > do
> 
> Currently it seems that people think we are either in option 2 or option
> 5, but I've heard views for the others. The goal of this discussion is
> to amend the constitution to make it clear which option we want.
> 
> If we drop the super-majority completely (1) this renders options 2, 4,
> and 5 moot. Option 3 renders everything moot.
> 
> I think we are (and should be) in 2, but please, please give me your
> views.

As secretary, it's now basicly up to me to decide that.  The
constituion has this to say about it:

   The Project Secretary should make decisions which are fair and
   reasonable, and preferably consistent with the consensus of the
   Developers.

And if there is no consensus, I will have to decide for myself.  I
prefer a clear consensus on this, and I think the only way to get
that by changing the constitution.

What this is about is how to interprete 4.1.5 of the constitution
which says:
5. Issue, supersede and withdraw nontechnical policy documents and
   statements.
   These include documents describing the goals of the project, its
   relationship with other free software entities, and nontechnical
   policies such as the free software licence terms that Debian
   software must meet.
   They may also include position statements about issues of the day.
 1. A Foundation Document is a document or statement regarded as
critical to the Project's mission and purposes.
 2. The Foundation Documents are the works entitled "Debian Social
Contract" and "Debian Free Software Guidelines".
 3. A Foundation Document requires a 3:1 majority for its
supersession. New Foundation Documents are issued and existing
ones withdrawn by amending the list of Foundation Documents in
this constitution.

I'm currently inclined to interprete it so that anything that
seems to modify an interpretation will require an explicit change
in some document.  But I'm not sure it's in my power to refuse
an option that doesn't do so.  So that would be option 2 above.


Kurt


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Constitutional issues in the wake of Lenny

[Matthew Johnson]

As Luk says, tackling these one at a time is probably best. So, first up
is (bullets numbered so that I can refer to them):

On Mon Mar 02 00:23, Matthew Johnson wrote: 
> Overriding vs Amending vs 'Position statement'
> 
> When a GR has an option which contradicts one of the foundation documents, but
> doesn't explicitly amend it; does this count as amending it? If it does not,
> then how is this reconciled with the fact that we have just agreed to do
> something which would contravene our own foundation documents?
> 
> Positions (in no particular order):
> 
>   1 The supermajority is rubbish and we should drop it entirely, so it 
> doesn't
> matter what the difference is.
>   2 Anything which overrides a FD implicitly modifies it to contain that
> specific exception, even if it's not specified in the GR, so always 
> needs
> 3:1.
>   3 Actually, the Social Contract isn't binding per-se, individual 
> delegates/
> developers are aiming for it as a goal, but can interpret it as they 
> see
> fit.
>   4 The DFSG doesn't automatically trump our users, we'll cope with DFSG
> issues if it's needed for things to work.
>   5 Single exceptions don't require supermajority, but permanent changes 
> do

Currently it seems that people think we are either in option 2 or option
5, but I've heard views for the others. The goal of this discussion is
to amend the constitution to make it clear which option we want.

If we drop the super-majority completely (1) this renders options 2, 4,
and 5 moot. Option 3 renders everything moot.

I think we are (and should be) in 2, but please, please give me your
views.

Matt
-- 
Matthew Johnson


signature.asc
Description: Digital signature

Re: Constitutional issues in the wake of Lenny

[Matthew Johnson]

On Sat Mar 14 12:51, Luk Claes wrote:
> Hmm, I thought the reason we delayed it till after the release is so we
> could discuss things and only when we have a consensus to change or seem
> to have clear options, to get to a vote.
> 
> As I saw your name mentioned next to the constitutional issues, I
> thought you were going to tackle one point after another to lead the
> discussions and not just to try to defend your own views?

Well, I was going to, but there's no discussion to lead! 

The main thing is that I really really don't want nothing to have
happened by the time we are trying to release squeeze.

Matt

-- 
Matthew Johnson


signature.asc
Description: Digital signature

Re: Constitutional issues in the wake of Lenny

[Luk Claes]

Matthew Johnson wrote:
> On Sat Mar 14 12:14, Luk Claes wrote:
>> I think the reason there were no comments is just because you tried to
>> cover the whole field, I would rather take one point at a time.
> 
> Sure, please do follow up with separate emails if you prefer.

Hmm, I thought you were going to lead the discussion and not just send a
IMHO giant proposal to be commented on.

>>> I also believe that the secretary should have the power to refuse to run
>>> a ballot option (by delaying the vote as appropriate) if he believes
>>> that it contradicts a FD but the ballot option itself does not
>>> explicitly claim to or otherwise resolve this problem.
>> I don't see what this power to refuse would by us other than getting a
>> similar situation we had with the previous Secretary? I would rather
>> give the Secretary the power to delay a ballot for a limited amount of
>> time to actively try to clarify the ambiguity.
> 
> No, Manoj believed (correctly or no) that he should mark them as
> super-majority if he thought they contradicted an FD, which the people
> who posted them disagreed with. I'm saying that the secretary can delay
> (possibly indefinitely) such a vote until it's made explicit.

Well, this is far from easy as even if you say explicitly that it does
not contradict, some people will still think it contradicts. So then
we're at a point we need to know who can decide about one or the other?

> (I think we actually agree about both of these issues)
> 
>> If a known DFSG issue is in sid, that means there is no problem with
>> distributing it (or the FTP Team is not acting). By the way if the
>> Release Team would ignore DFSG issues, one would not find a Release Team
>> action that shows this fact. Tagging them -ignore, is not
>> ignoring the bugs, but telling our developers that we don't think the
>> issue should delay the release. 
> 
> Yes, this is what I think and tried to say in my previous mail.
> 
>>> WRT the other issues, I'm happy with the seconding and supermajority
>>> options as they are, so won't be proposing we change them.
>> So is Dato leading the discussion for these other options?
> 
> Anyone who wants to change them. I tried starting off that discussion,
> but noone followed up. I'm not about to propose running a vote to keep
> them as they are...

Hmm, I thought the reason we delayed it till after the release is so we
could discuss things and only when we have a consensus to change or seem
to have clear options, to get to a vote.

As I saw your name mentioned next to the constitutional issues, I
thought you were going to tackle one point after another to lead the
discussions and not just to try to defend your own views?

Cheers

Luk


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Constitutional issues in the wake of Lenny

[Matthew Johnson]

On Sat Mar 14 12:14, Luk Claes wrote:
> I think the reason there were no comments is just because you tried to
> cover the whole field, I would rather take one point at a time.

Sure, please do follow up with separate emails if you prefer.

> > I also believe that the secretary should have the power to refuse to run
> > a ballot option (by delaying the vote as appropriate) if he believes
> > that it contradicts a FD but the ballot option itself does not
> > explicitly claim to or otherwise resolve this problem.
> 
> I don't see what this power to refuse would by us other than getting a
> similar situation we had with the previous Secretary? I would rather
> give the Secretary the power to delay a ballot for a limited amount of
> time to actively try to clarify the ambiguity.

No, Manoj believed (correctly or no) that he should mark them as
super-majority if he thought they contradicted an FD, which the people
who posted them disagreed with. I'm saying that the secretary can delay
(possibly indefinitely) such a vote until it's made explicit.

(I think we actually agree about both of these issues)

> If a known DFSG issue is in sid, that means there is no problem with
> distributing it (or the FTP Team is not acting). By the way if the
> Release Team would ignore DFSG issues, one would not find a Release Team
> action that shows this fact. Tagging them -ignore, is not
> ignoring the bugs, but telling our developers that we don't think the
> issue should delay the release. 

Yes, this is what I think and tried to say in my previous mail.

> > WRT the other issues, I'm happy with the seconding and supermajority
> > options as they are, so won't be proposing we change them.
> 
> So is Dato leading the discussion for these other options?

Anyone who wants to change them. I tried starting off that discussion,
but noone followed up. I'm not about to propose running a vote to keep
them as they are...

Matt

-- 
Matthew Johnson


signature.asc
Description: Digital signature

Re: Constitutional issues in the wake of Lenny

[Luk Claes]

Matthew Johnson wrote:
> On Mon Mar 02 00:23, Matthew Johnson wrote:
>> The votes around the Lenny release revealed some disagreements around the
>> constitution, DFSG, supermajority requirements and what people think is
>> 'obvious'. What I would like to do is clarify some of these before they come 
>> up
>> again. To avoid overloading -project I'd like to move the initial discussion
>> somewhere else. If you are interested in developing the ballot options for
>> this, please follow up on -vote. We'll move back to -project when there are
>> more firm suggestions.
> 
> Hmm, so far the discussion has been rather less verbose than when the
> issues were blocking Lenny. While not having arguments is good, I really
> do think we need to make sure we don't have the arguments again for
> squeeze. My previous email tried to cover the whole field of views, this
> one is my personal view, which I want to run to a GR to make the
> constitution and FDs explicit on the points which were ambiguous in the
> discussions pre-lenny.

I think the reason there were no comments is just because you tried to
cover the whole field, I would rather take one point at a time.

>> Overriding vs Amending vs 'Position statement'
>>
>> When a GR has an option which contradicts one of the foundation documents, 
>> but
>> doesn't explicitly amend it; does this count as amending it? If it does not,
>> then how is this reconciled with the fact that we have just agreed to do
>> something which would contravene our own foundation documents?

This is the difference between a goal and pragmatism AFAICS. It's not
because we have a position statement that *temporary* contradicts a
foundation document, that we want to amend the foundation document.

> I personally believe that any vote which contradicts one of the FDs,
> even if just a temporary or limited scope exception, implicitly modifies
> that FD and therefore requires a supermajority. Such votes should be
> included (probably via a hyperlink) in the FD itself.

I guess that would mean we should rethink all the foundation documents
as many items are currently already contradicted in practice...

>>- Ballots which are ambiguous about resolving the clash between them
>>  and a FD should be rejected and not run.
> 
> I also believe that the secretary should have the power to refuse to run
> a ballot option (by delaying the vote as appropriate) if he believes
> that it contradicts a FD but the ballot option itself does not
> explicitly claim to or otherwise resolve this problem.

I don't see what this power to refuse would by us other than getting a
similar situation we had with the previous Secretary? I would rather
give the Secretary the power to delay a ballot for a limited amount of
time to actively try to clarify the ambiguity.

>> Release team vs DFSG issues

This is a very unfortunate way of looking at things IMHO.

>> DFSG applies to sid. If it's there and no-one has removed it, the RT can
>> snapshot the archive at any point for the release. DFSG or other RC bugs; 
>> it's
>> up to them whether to ignore them. This is possibly a subset of the above two
>> items, however, I think it's important enough to warrant being explicitly
>> specified.

If a known DFSG issue is in sid, that means there is no problem with
distributing it (or the FTP Team is not acting). By the way if the
Release Team would ignore DFSG issues, one would not find a Release Team
action that shows this fact. Tagging them -ignore, is not
ignoring the bugs, but telling our developers that we don't think the
issue should delay the release. This tagging is of course only done when
it's clear that there is being worked on the issue, but that it's very
unlikely that it would be finished before the release.

Note that tagging bugs -ignore does not at all mean they cannot
be fixed before the release. On the contrary, it means that fixes for
them are still accepted, but when the fixes are not in time for the
release, we're not going to wait for them.

> WRT the other issues, I'm happy with the seconding and supermajority
> options as they are, so won't be proposing we change them.

So is Dato leading the discussion for these other options?

Cheers

Luk


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Constitutional issues in the wake of Lenny

[Matthew Johnson]

On Mon Mar 02 00:23, Matthew Johnson wrote:
> The votes around the Lenny release revealed some disagreements around the
> constitution, DFSG, supermajority requirements and what people think is
> 'obvious'. What I would like to do is clarify some of these before they come 
> up
> again. To avoid overloading -project I'd like to move the initial discussion
> somewhere else. If you are interested in developing the ballot options for
> this, please follow up on -vote. We'll move back to -project when there are
> more firm suggestions.

Hmm, so far the discussion has been rather less verbose than when the
issues were blocking Lenny. While not having arguments is good, I really
do think we need to make sure we don't have the arguments again for
squeeze. My previous email tried to cover the whole field of views, this
one is my personal view, which I want to run to a GR to make the
constitution and FDs explicit on the points which were ambiguous in the
discussions pre-lenny.
 
> Overriding vs Amending vs 'Position statement'
> 
> When a GR has an option which contradicts one of the foundation documents, but
> doesn't explicitly amend it; does this count as amending it? If it does not,
> then how is this reconciled with the fact that we have just agreed to do
> something which would contravene our own foundation documents?

I personally believe that any vote which contradicts one of the FDs,
even if just a temporary or limited scope exception, implicitly modifies
that FD and therefore requires a supermajority. Such votes should be
included (probably via a hyperlink) in the FD itself.

>- Ballots which are ambiguous about resolving the clash between them
>  and a FD should be rejected and not run.

I also believe that the secretary should have the power to refuse to run
a ballot option (by delaying the vote as appropriate) if he believes
that it contradicts a FD but the ballot option itself does not
explicitly claim to or otherwise resolve this problem.

> Release team vs DFSG issues
> 
> DFSG applies to sid. If it's there and no-one has removed it, the RT can
> snapshot the archive at any point for the release. DFSG or other RC bugs; it's
> up to them whether to ignore them. This is possibly a subset of the above two
> items, however, I think it's important enough to warrant being explicitly
> specified.

The release team is appointed by the DPL who is elected. I think we
should trust them to do their job and hence empower them to make
whatever decision they like about whether a bug (of any severity) blocks
the release. Other developers can override this by GR as normal
(although, they should in general listen to people who disagree first
 and policy on the overrides should be set early in the release cycle).

I intend to propose the above three votes (I'll work out actual
wording), all of which will explicitly modify things.

WRT the other issues, I'm happy with the seconding and supermajority
options as they are, so won't be proposing we change them.

Matt
-- 
Matthew Johnson


signature.asc
Description: Digital signature

Constitutional issues in the wake of Lenny

[Matthew Johnson]

Dear all,

The votes around the Lenny release revealed some disagreements around the
constitution, DFSG, supermajority requirements and what people think is
'obvious'. What I would like to do is clarify some of these before they come up
again. To avoid overloading -project I'd like to move the initial discussion
somewhere else. If you are interested in developing the ballot options for
this, please follow up on -vote. We'll move back to -project when there are
more firm suggestions.

I'm going to try and outline what I think are the issues and relevant factions.
Please use this as a starting point for finding out where there are
disagreements and what points of view people have in order to construct a clear
ballot. We're not aiming to decide what is the right answer in the discussion,
we are aiming to decide what is the right question and so I hope the discussion
can remain polite.

Because we have disagreements about whether or not supermajority is required, I
would like all of these votes to explicitly amend the constitution in all
options, so it is completely clear. After the first vote that may not matter
for the rest, of course and this is why I would like this vote to be the first
one to run.

Overriding vs Amending vs 'Position statement'

When a GR has an option which contradicts one of the foundation documents, but
doesn't explicitly amend it; does this count as amending it? If it does not,
then how is this reconciled with the fact that we have just agreed to do
something which would contravene our own foundation documents?

Positions (in no particular order):

- The supermajority is rubbish and we should drop it entirely, so it 
doesn't
  matter what the difference is.
- Anything which overrides a FD implicitly modifies it to contain that
  specific exception, even if it's not specified in the GR, so always 
needs
  3:1.
- Actually, the Social Contract isn't binding per-se, individual 
delegates/
  developers are aiming for it as a goal, but can interpret it as they 
see
  fit.
- The DFSG doesn't automatically trump our users, we'll cope with DFSG
  issues if it's needed for things to work.
- Single exceptions don't require supermajority, but permanent changes 
do
(and slightly orthogonal, but:)
   - Ballots which are ambiguous about resolving the clash between them
 and a FD should be rejected and not run.

Constitutional/FD interpretations

Someone sometimes will need to interpret the constitution or other FDs, however
well we word it (but I think where we find disagreements/ambiguities we should
then fix them)

Positions:

- Secretary does it
- DPL does it
- some other group (eg the TC does it)
- The DD making the relevant decision does it

Release team vs DFSG issues

DFSG applies to sid. If it's there and no-one has removed it, the RT can
snapshot the archive at any point for the release. DFSG or other RC bugs; it's
up to them whether to ignore them. This is possibly a subset of the above two
items, however, I think it's important enough to warrant being explicitly
specified.

Positions:

- RT can snapshot releases whenever and ignore whatever bugs they like
- If it's not a regression there's no problem, we're still improving,
  there's no point in delaying releases for it.
- No, the release is what counts, transitive problems in sid less so, 
but we
  mustn't release with DFSG problems

I'm sure there are other related positions I've missed off too.

Matt

-- 
Matthew Johnson


signature.asc
Description: Digital signature