Re: Constitutional issues in the wake of Lenny

2009-03-14 Thread 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

2009-03-14 Thread 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

2009-03-14 Thread 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

2009-03-14 Thread 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]

2009-03-14 Thread 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

2009-03-14 Thread 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]

2009-03-14 Thread 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

2009-03-14 Thread 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: Question for all candidates about http://wiki.debian.org/DiscussionsAfterLenny

2009-03-14 Thread Luk Claes
Charles Plessy wrote:
> Dear Steve, Luk and Stefano,

Hi Charles

> thank you very much for the time and efforts you are proposing to dedicate to
> the Project !
> 
> Our Consitution suggests a stronger leadership of the DPL the discussions:
> 
>  9. Lead discussions amongst Developers.
> 
> The Project Leader should attempt to participate in discussions amongst 
> the
> Developers in a helpful way which seeks to bring the discussion to bear 
> on the
> key issues at hand. The Project Leader should not use the Leadership 
> position
> to promote their own personal views.
> 
> http://www.debian.org/devel/constitution.en.html#5
> 
> Given how heated discussions can become in Debian, it seems that many previous
> Leaders have chosen to have a cooling role rather than a conducting role.
> Nevertheless, how do you intend to act in the context of this 5.1.9 article if
> you are elected ? In particular, there is already a long list of subjects on
> the Wiki. Can you comment about it ?

I would try to have people already involved in the discussion lead the
discussions and help them where needed (like I just did for the
Constitutional Issues thread).

I think the wiki page is a very good initiative and hope it will be used
to keep track of what discussions need to happen and to keep track of
their status.

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

2009-03-14 Thread 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

2009-03-14 Thread 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

2009-03-14 Thread 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

2009-03-14 Thread 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

2009-03-14 Thread 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