Firmware

[Luk Claes]

Hi

As probably many of you know, the most heard criticism from users and 
press on Lenny's release is lost hardware support because of missing 
firmware. Users and press are complaining that their servers don't have 
network anymore after an upgrade or that their notebooks cannot be 
installed via wireless...


It's of course possible to load firmware from extra media during 
installation or install the right package (from non-free) when booting 
back to an older kernel (to have network again) to be able to use the 
network with the new kernel...


What do people think of a new vote regarding the status of firmware? One 
of the options can probably be Peter Palfrader's proposal [1].


Cheers

Luk

[1] http://www.debian.org/vote/2008/vote_003#textf


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

Re: Firmware

[Stephen Gran]

This one time, at band camp, Luk Claes said:
> What do people think of a new vote regarding the status of firmware?

Much as I'm not totally ready to watch/have this argument again so soon,
I thank you for bringing it up early in the release cycle.  I'd personally
like to put this one to bed one way or another, but if we're going to
have a 'discussion' every release, I'd rather see it at the beginning
of the release cycle than at the end.

Cheers,
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :sg...@debian.org |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: Firmware

[Stefano Zacchiroli]

On Fri, May 01, 2009 at 11:48:58AM +0200, Luk Claes wrote:
> What do people think of a new vote regarding the status of firmware?
> One of the options can probably be Peter Palfrader's proposal [1].

I'm very much in favor of having this vote early in the release cycle,
and I was pondering about proposing it myself. Ideally, my goal would
have been to have a vote on the issue in general, without any
release-specific option. Peter's option is the main option I would
like to see in, what else did you have in mind?

IIRC, most of the participants in the pre-Lenny GR discussion was very
keen of settling the issue once and for all just after the Lenny
release. So I think you can just go ahead proposing Peter's text and
see what other options pop up.

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Supermajority first? (was: Re: Firmware)

[Charles Plessy]

Le Fri, May 01, 2009 at 01:58:43PM +0200, Stefano Zacchiroli a écrit :
> 
> I'm very much in favor of having this vote early in the release cycle,

Hi all,

There were discussions started on the supermajority requirement, that
unfortunately were unconclusive (20090302002303.gm29...@matthew.ath.cx),

http://lists.debian.org/debian-vote/2009/03/msg3.html

Nevertheless, wouldn't it be safer to first resolve this issue, while keeping as
a goal to address the firmware question early in the release cycle?

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: Supermajority first?

[Luk Claes]

Charles Plessy wrote:

Le Fri, May 01, 2009 at 01:58:43PM +0200, Stefano Zacchiroli a écrit :

I'm very much in favor of having this vote early in the release cycle,


Hi all,

There were discussions started on the supermajority requirement, that
unfortunately were unconclusive (20090302002303.gm29...@matthew.ath.cx),

http://lists.debian.org/debian-vote/2009/03/msg3.html

Nevertheless, wouldn't it be safer to first resolve this issue, while keeping as
a goal to address the firmware question early in the release cycle?


Well sponsors of the proposals have till Sunday to get it to vote 
AFAICS. Personally I would not mind to have a vote for this first and I 
won't start the process for a firmware vote before the vote about 
supermajority is either dropped (when no sponsor reacts) or voted on...


Cheers

Luk


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

Re: Supermajority first?

[Kurt Roeckx]

On Fri, May 01, 2009 at 03:52:47PM +0200, Luk Claes wrote:
> Charles Plessy wrote:
>>
>> There were discussions started on the supermajority requirement, that
>> unfortunately were unconclusive (20090302002303.gm29...@matthew.ath.cx),
>>
>> http://lists.debian.org/debian-vote/2009/03/msg3.html
>>
>> Nevertheless, wouldn't it be safer to first resolve this issue, while 
>> keeping as
>> a goal to address the firmware question early in the release cycle?
>
> Well sponsors of the proposals have till Sunday to get it to vote  
> AFAICS. Personally I would not mind to have a vote for this first and I  
> won't start the process for a firmware vote before the vote about  
> supermajority is either dropped (when no sponsor reacts) or voted on...

Current vote that is in the process of being withdrawn has nothing
to do with the supermajority requirement.  It's about sponsorship
requirements.

The supermajority is about things like who decideds if something
needs 3:1 supermajority if it's not clear.


Kurt


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

Re: Supermajority first?

[Luk Claes]

Kurt Roeckx wrote:

On Fri, May 01, 2009 at 03:52:47PM +0200, Luk Claes wrote:

Charles Plessy wrote:

There were discussions started on the supermajority requirement, that
unfortunately were unconclusive (20090302002303.gm29...@matthew.ath.cx),

http://lists.debian.org/debian-vote/2009/03/msg3.html

Nevertheless, wouldn't it be safer to first resolve this issue, while keeping as
a goal to address the firmware question early in the release cycle?
Well sponsors of the proposals have till Sunday to get it to vote  
AFAICS. Personally I would not mind to have a vote for this first and I  
won't start the process for a firmware vote before the vote about  
supermajority is either dropped (when no sponsor reacts) or voted on...


Current vote that is in the process of being withdrawn has nothing
to do with the supermajority requirement.  It's about sponsorship
requirements.

The supermajority is about things like who decideds if something
needs 3:1 supermajority if it's not clear.


Ah right, too much things to vote on :-)

Well, I think the sponsorships requirement vote that is currently being 
in process should first be dealt with (either dropped or voted on) first.


Continuing discussions about the supermajority requirements before going 
to the firmware is probably not a bad idea.


Cheers

Luk


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

Re: Supermajority first?

[Stefano Zacchiroli]

On Fri, May 01, 2009 at 04:20:21PM +0200, Luk Claes wrote:
> Continuing discussions about the supermajority requirements before
> going to the firmware is probably not a bad idea.

I see the point of asking the supermajority vote to be dealt with
before voting on firmware.

However, I don't see it as necessary. The discussion about the issues
of supermajority was born from a ballot badly dealt with; the errors
of that ballot have already been acknowledged and is pointless to
reiterate here. Still, it is very well possible that we can, this
time, vote on the firmware issues without as many problems as before.

For instance, it would be very useful to know whether the current
secretary would consider Peter's proposal on firmware to require super
majority or not. If the secretary does _not_ think it will imply
supermajority, it would be pointless to delay the vote on the basis of
that.

So, Kurt, what's your take on it?

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Overriding vs Amending vs Position statement

[Luk Claes]

Hi

There seem to be some disagreements about the terms in the subject. As 
far as I'm concerned it's pretty clear though and would not need any 
vote to clarify:


Overriding is only used in combination with decisions. You cannot 
override a document or its interpretation/meaning. You can only override 
a DD's (or delegate's) decision.


Amending is changing something written like a foundation document or a 
proposal. As far as I can see you can only amend explicitly so there 
should be no confusion.


A position statement is a decided on proposal that clarifies the 
position of the Debian project, but does not explicitly amend a 
foundation document.


Supersession of a Foundation Document is replacing a Foundation Document 
with another version: introduce a new one, ammend one or remove one.


According to the Debian Constitution there is only a 3:1 majority needed 
to ammend the Constitution or supersede a Foundation Document.


So I don't really see what we should vote on unless someone disagrees 
with above interpretations?


Cheers

Luk


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

Re: Supermajority first?

[Emilio Pozuelo Monfort]

Stefano Zacchiroli wrote:
> For instance, it would be very useful to know whether the current
> secretary would consider Peter's proposal on firmware to require super
> majority or not. If the secretary does _not_ think it will imply
> supermajority, it would be pointless to delay the vote on the basis of
> that.

As some people already have said, making all the choices in such a ballot modify
the Foundation Documents would make the supermajority problems in the previous
vote go away, and would more likely solve this issue once and for all (or
probably not only affecting the current release or whatever), as it would be
written in the FDs.

Emilio



signature.asc
Description: OpenPGP digital signature

Re: Overriding vs Amending vs Position statement

[Don Armstrong]

On Fri, 01 May 2009, Luk Claes wrote:
> A position statement is a decided on proposal that clarifies the
> position of the Debian project, but does not explicitly amend a
> foundation document.

[...]

> So I don't really see what we should vote on unless someone
> disagrees with above interpretations?

The only question resides with the effect of passing such position
statements. Without modifying foundation documents or the
constitution, they are effectively non-binding advisory statements
when operating within areas that are the remit of foundation documents
or the constitution.

Developers can ignore (or follow) such statements as they wish.

Furthermore, the statements must be non-technical.


Don Armstrong

-- 
Filing a bug is probably not going to get it fixed any faster.
 -- Anthony Towns

http://www.donarmstrong.com  http://rzlab.ucr.edu


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

Re: Firmware

[Thomas Bushnell BSG]

On Fri, 2009-05-01 at 13:58 +0200, Stefano Zacchiroli wrote:
> On Fri, May 01, 2009 at 11:48:58AM +0200, Luk Claes wrote:
> > What do people think of a new vote regarding the status of firmware?
> > One of the options can probably be Peter Palfrader's proposal [1].
> 
> I'm very much in favor of having this vote early in the release cycle,
> and I was pondering about proposing it myself. Ideally, my goal would
> have been to have a vote on the issue in general, without any
> release-specific option. Peter's option is the main option I would
> like to see in, what else did you have in mind?

Absolutely I'm in favor of having the decision now, calmly.

My fear is that it won't matter what we do; the partisans of semi-free
Debian will not get everything they want (simply because nobody ever
does), and then will scream as the release is near that we must again
have special exceptions.  I hope I can be proved wrong.

Thomas



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

[Matthew Johnson]

On Fri May 01 11:56, Don Armstrong wrote:
> > So I don't really see what we should vote on unless someone
> > disagrees with above interpretations?
> 
> The only question resides with the effect of passing such position
> statements. Without modifying foundation documents or the
> constitution, they are effectively non-binding advisory statements
> when operating within areas that are the remit of foundation documents
> or the constitution.

Indeed and there is the case of temporary exceptions. Does saying "we
will release with non-free stuff" involve modifying a foundation
document? I would say yes. Does saying "we will release Lenny with
non-free stuff" involve modifying a foundation document? There seems to
be less agreement on this. I think it does, but the previous discussion
showed that some people disagree.

Anyway, I'm going to try and push that discussion a bit more in a
couple of hours, so probably best to discuss in that context

-- 
Matthew Johnson


signature.asc
Description: Digital signature

Re: Overriding vs Amending vs Position statement

[Luk Claes]

Matthew Johnson wrote:

On Fri May 01 11:56, Don Armstrong wrote:

So I don't really see what we should vote on unless someone
disagrees with above interpretations?

The only question resides with the effect of passing such position
statements. Without modifying foundation documents or the
constitution, they are effectively non-binding advisory statements
when operating within areas that are the remit of foundation documents
or the constitution.


Indeed and there is the case of temporary exceptions. Does saying "we
will release with non-free stuff" involve modifying a foundation
document? I would say yes. Does saying "we will release Lenny with
non-free stuff" involve modifying a foundation document? There seems to
be less agreement on this. I think it does, but the previous discussion
showed that some people disagree.


This always sounds very awkward to me. So if we would just not fix bugs 
about non-free stuff everything is ok, but if we want to release it has 
either to be fixed very quickly or get a vote that modifies a foundation 
document? Sorry, but I did not and will not agree with that.


We will not release with random non-free stuff, nor will we release with 
easily fixable non-free stuff, nor will we release with non-free stuff 
where it's clear that upstream does not care in fixing it. We will 
release with non-free stuff that does not get fixed in time where 
upsteam is working on it though.


I don't see why this would need any vote, though if you really think 
it's useful to have a vote on this, so be it.


Cheers

Luk


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

Re: Supermajority first?

[Kurt Roeckx]

On Fri, May 01, 2009 at 06:43:56PM +0200, Stefano Zacchiroli wrote:
> 
> For instance, it would be very useful to know whether the current
> secretary would consider Peter's proposal on firmware to require super
> majority or not. If the secretary does _not_ think it will imply
> supermajority, it would be pointless to delay the vote on the basis of
> that.
> 
> So, Kurt, what's your take on it?

So, the problematic parts are:
"1. firmware in Debian does not have to come with source."
"2. we however do require all other freedoms that the DFSG
mandate from components of our operating system"

If you only look at the first, you could interprete it as
a position statement, but even then it's not clear that
it's a position statement or not.

But 2) makes it totaly unclear what 1) really means.  2) seems to
indicate that 1) modifies some foundation document.

So my problem with it is that it's too much open for
interpretation.

If you would like that such an option does not get a 3:1 majority
requirement, I suggest you reword it so that it's clearly a
position statement.


Kurt


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

Draft vote on constitutional issues

[Matthew Johnson]

As suggested [0] I think we should clarify these issues before any other
votes. As such I'd like to suggest a draft for the vote.

I'm proposing several options for a couple of reasons. Several of them I
would rank above further discussion, but I also want to make sure that
there is an option for everyone on here. I'm trying to clarify our
current situation. Resolving the vote without such a clarification does
not help this. You should all see an option below which you think is the
Status quo, but I'm certain that not everyone agrees with which one, so,
if you want the status quo, please vote for the option which describes
it, not for further discussion. If you _can't_ see what you think is the
status quo below, now is the time to point this out. (note, I'm not
formally proposing this as a vote yet, but would like to fairly soon)

Option 1 - No Supermajority

We do not believe that we should require anything more than a simple
majority for any changes to the constitution or foundation documents.

   - replace Constitution 4.1 point 2 with "Amend this constitution"
   - in Constitution 4.1 point 5, point 3, remove "A Foundation Document
  requires a 3:1 majority for its supersession. "

This option amends the constitution and hence requires a 3:1 majority.

Option 2 - All conflicting GR options require a Supermajority

We believe that any GR which has an option which overrides some or all
of a foundation document, even temporarily, implicitly modifies it to
contain this exception and thus requires a 3:1 majority

   - replace Constitution 4.1 point 5 with "Issue, supersede,
  withdraw, amend and add exceptions to nontechnical policy 
  documents and statements."
   - in Constitution 4.1 point 5 add point 4: "All GR options which 
  provide exceptions to a foundation document (temporary or
  permanent) implicitly modify the document to contain that
  exception and require a 3:1 majority"

This option amends the constitution and hence requires a 3:1 majority.

Option 4 - Balancing issues between users and freedom

We believe that there will be cases where the project must balance
between our priorities of our users and of Debian remaining 100% free.
Project decisions which make such a balance do not require a
Supermajority, but all others do

   - Add Social Contract 6:

   6. Works that our not 100% free but are required by our users.

   We acknowledge that there may be occasions where it is not possible
   to place the interests of our users first with purely free software.
   As such, we may on occasion provide software which does not meet our
   normal standards of freedom if it is necessary in the interests of
   our users. In all cases we will work towards a free system where such
   compromises are not necessary

   - replace Constitution 4.1 point 5 with "Issue, supersede,
  withdraw, amend and add exceptions to nontechnical policy 
  documents and statements."
   - in Constitution 4.1 point 5 add point 4: "All GR options which 
  provide exceptions to a foundation document (temporary or
  permanent) implicitly modify the document to contain that
  exception and require a 3:1 majority"

This option amends the constitution and social contract and hence
requires a 3:1 majority.

Option 5 - Temporary overrides without Supermajority

We believe that GRs may temporarily override foundation documents
without requiring a 3:1 majority. Resolutions which are in conflict with
a foundation document and make a permanent change must modify the
foundation document and require a 3:1 majority

   - replace Constitution 4.1 point 5 with "Issue, supersede,
  withdraw, amend and add exceptions to nontechnical policy 
  documents and statements."
   - in Constitution 4.1 point 5 add point 4: "All GR options which 
  provide permanent exceptions to a foundation document implicitly
  modify the document to contain that exception and require
  a 3:1 majority"
   - in Constitution 4.1 point 5 add point 5: "All GR options which 
  provide temporary exceptions to a foundation document only require
  a simple majority to pass.

This option amends the constitution and hence requires a 3:1 majority.

Option 6 - Votes may modify or be a position statement, but must be explicit

We believe that any vote which overrides a Foundation Document modifies
it to contain that exception and must explicitly 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 only requires a
simple majority.  This is true even if the Secretary disagrees with the
interpretation.  However, such interpretations 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 no

Re: Overriding vs Amending vs Position statement

[Manoj Srivastava]

On Fri, May 01 2009, Don Armstrong wrote:

> On Fri, 01 May 2009, Luk Claes wrote:
>> A position statement is a decided on proposal that clarifies the
>> position of the Debian project, but does not explicitly amend a
>> foundation document.
>
> [...]
>
>> So I don't really see what we should vote on unless someone
>> disagrees with above interpretations?
>
> The only question resides with the effect of passing such position
> statements. Without modifying foundation documents or the
> constitution, they are effectively non-binding advisory statements
> when operating within areas that are the remit of foundation documents
> or the constitution.

> Developers can ignore (or follow) such statements as they wish.

If the statements are in contradiction of the foundation
 document (which is the case in a couple of prior situations), then are
 you saying that anything in the foundation documents can ve worked
 around by putting out a position statement, and have the developers
 proceed to ignore the foundation document on that basis?

That also begs the question: do we _have_ to follow the
 foundation documents? Or can one just issue a statement "I do not agree
 with the foundation doc" and just ignore it at will?

if that is not the case, what value does a position statement in
 contradiction of a foundation document mean?

Can I just set a position statement that redefines all the owrds
 used in a  foundation doc to promote my "interpretation" of the
 foundation doc, as long as the majority of the people voting rate it
 over FD?

How binding _are_ the foundation documents?

manoj
 free === does not cost more than USD 1000300.73
 distribute == transport over trains between sunday noon and monday
   morning 8:00am"
 Guidelines === something that must be followed in the ides of march

-- 
Actors will happen in the best-regulated families.
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Supermajority first?

[Luk Claes]

Kurt Roeckx wrote:

On Fri, May 01, 2009 at 06:43:56PM +0200, Stefano Zacchiroli wrote:

For instance, it would be very useful to know whether the current
secretary would consider Peter's proposal on firmware to require super
majority or not. If the secretary does _not_ think it will imply
supermajority, it would be pointless to delay the vote on the basis of
that.

So, Kurt, what's your take on it?


So, the problematic parts are:
"1. firmware in Debian does not have to come with source."
"2. we however do require all other freedoms that the DFSG
mandate from components of our operating system"

If you only look at the first, you could interprete it as
a position statement, but even then it's not clear that
it's a position statement or not.


It appears you either don't agree with my other post or did not read it 
as there is no interpretation needed to see if something is a position 
statement.


Cheers

Luk


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

Re: Draft vote on constitutional issues

[Luk Claes]

Matthew Johnson wrote:

As suggested [0] I think we should clarify these issues before any other
votes. As such I'd like to suggest a draft for the vote.

I'm proposing several options for a couple of reasons. Several of them I
would rank above further discussion, but I also want to make sure that
there is an option for everyone on here. I'm trying to clarify our
current situation. Resolving the vote without such a clarification does
not help this. You should all see an option below which you think is the
Status quo, but I'm certain that not everyone agrees with which one, so,
if you want the status quo, please vote for the option which describes
it, not for further discussion. If you _can't_ see what you think is the
status quo below, now is the time to point this out. (note, I'm not
formally proposing this as a vote yet, but would like to fairly soon)


I think trying to propose many options together is very wrong as you are 
very probably not objective for all the options nor will you be able to 
word it properly for the ones that do care about an option you don't 
really care about.


The other risk you take by proposing many options at once is to mix 
unrelated things in the same vote IMHO.



Option 1 - No Supermajority

We do not believe that we should require anything more than a simple
majority for any changes to the constitution or foundation documents.

   - replace Constitution 4.1 point 2 with "Amend this constitution"
   - in Constitution 4.1 point 5, point 3, remove "A Foundation Document
  requires a 3:1 majority for its supersession. "

This option amends the constitution and hence requires a 3:1 majority.


I would be very surprised if this option would get enough seconds if you 
would propose it.



Option 2 - All conflicting GR options require a Supermajority

We believe that any GR which has an option which overrides some or all
of a foundation document, even temporarily, implicitly modifies it to
contain this exception and thus requires a 3:1 majority


This all boils down to the definition of override which I tried to state 
in the other thread. If you go by my definition, this is really a 
non-option IMHO.



Option 4 - Balancing issues between users and freedom

We believe that there will be cases where the project must balance
between our priorities of our users and of Debian remaining 100% free.
Project decisions which make such a balance do not require a
Supermajority, but all others do

   - Add Social Contract 6:

   6. Works that our not 100% free but are required by our users.

   We acknowledge that there may be occasions where it is not possible
   to place the interests of our users first with purely free software.
   As such, we may on occasion provide software which does not meet our
   normal standards of freedom if it is necessary in the interests of
   our users. In all cases we will work towards a free system where such
   compromises are not necessary

   - replace Constitution 4.1 point 5 with "Issue, supersede,
  withdraw, amend and add exceptions to nontechnical policy 
  documents and statements."
   - in Constitution 4.1 point 5 add point 4: "All GR options which 
  provide exceptions to a foundation document (temporary or

  permanent) implicitly modify the document to contain that
  exception and require a 3:1 majority"


Same remark as above.


This option amends the constitution and social contract and hence
requires a 3:1 majority.


This option does not look related to supermajority requirements to me.


Option 5 - Temporary overrides without Supermajority

We believe that GRs may temporarily override foundation documents
without requiring a 3:1 majority. Resolutions which are in conflict with
a foundation document and make a permanent change must modify the
foundation document and require a 3:1 majority

   - replace Constitution 4.1 point 5 with "Issue, supersede,
  withdraw, amend and add exceptions to nontechnical policy 
  documents and statements."
   - in Constitution 4.1 point 5 add point 4: "All GR options which 
  provide permanent exceptions to a foundation document implicitly

  modify the document to contain that exception and require
  a 3:1 majority"
   - in Constitution 4.1 point 5 add point 5: "All GR options which 
  provide temporary exceptions to a foundation document only require

  a simple majority to pass.

This option amends the constitution and hence requires a 3:1 majority.


This boils down to the definition of override again...


Option 6 - Votes may modify or be a position statement, but must be explicit

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


This is already the case AFAICS


A GR which explicitly states that it does not override a Foundation
Document but instead offers a project interpretation of that

Re: Firmware

[Joey Schulze]

Luk Claes wrote:
> Hi
>
> As probably many of you know, the most heard criticism from users and  
> press on Lenny's release is lost hardware support because of missing  
> firmware. Users and press are complaining that their servers don't have  
> network anymore after an upgrade or that their notebooks cannot be  
> installed via wireless...
>
> It's of course possible to load firmware from extra media during  
> installation or install the right package (from non-free) when booting  
> back to an older kernel (to have network again) to be able to use the  
> network with the new kernel...
>
> What do people think of a new vote regarding the status of firmware? One  
> of the options can probably be Peter Palfrader's proposal [1].

I would rather like to keep binary firmware blobs outside of Debian/main
and maintain them in Debian/non-free with improved and easy ways to load
them during the installation.

We might require a new vote in order to release squeeze at some date.
We should be able to release squeeze even with non-free binary firmware
data included in the kernel.  However, we should rather try to move
these blobs into separate files (in Debian and upstream).  However,
this requirement should not keep us from releasing.

Regards,

Joey

-- 
Still can't talk about what I can't talk about.  Sorry.  -- Bruce Schneier


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

[Luk Claes]

Manoj Srivastava wrote:

On Fri, May 01 2009, Don Armstrong wrote:


On Fri, 01 May 2009, Luk Claes wrote:

A position statement is a decided on proposal that clarifies the
position of the Debian project, but does not explicitly amend a
foundation document.

[...]


So I don't really see what we should vote on unless someone
disagrees with above interpretations?

The only question resides with the effect of passing such position
statements. Without modifying foundation documents or the
constitution, they are effectively non-binding advisory statements
when operating within areas that are the remit of foundation documents
or the constitution.



Developers can ignore (or follow) such statements as they wish.


If the statements are in contradiction of the foundation
 document (which is the case in a couple of prior situations), then are
 you saying that anything in the foundation documents can ve worked
 around by putting out a position statement, and have the developers
 proceed to ignore the foundation document on that basis?


Of course not. If a position statement contradicts a foundation document 
it's time to update the foundation document accordingly or drop the 
position statement again.



That also begs the question: do we _have_ to follow the
 foundation documents? Or can one just issue a statement "I do not agree
 with the foundation doc" and just ignore it at will?


You do realise that a majority needs to agree with it before it turns 
into a position statement?


It's not because a position statement is not binding that a foundation 
document would also not be binding...



if that is not the case, what value does a position statement in
 contradiction of a foundation document mean?


It would be a clear indication that the foundation document should get 
an update or that the postition statement should get dropped again.



Can I just set a position statement that redefines all the owrds
 used in a  foundation doc to promote my "interpretation" of the
 foundation doc, as long as the majority of the people voting rate it
 over FD?


This is actually asking if a position statement can clarify a foundation 
document but put in a twisted way AFAICS...



How binding _are_ the foundation documents?


Interesting question as you seem to be one to take the Constitution with 
a twisted interpretation when it fits you best in some previous occasions.



 free === does not cost more than USD 1000300.73
 distribute == transport over trains between sunday noon and monday
   morning 8:00am"
 Guidelines === something that must be followed in the ides of march


I guess this is a bad attempt at a joke?

Cheers

Luk


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

[Don Armstrong]

On Fri, 01 May 2009, Manoj Srivastava wrote:
> If the statements are in contradiction of the foundation document
> (which is the case in a couple of prior situations), then are you
> saying that anything in the foundation documents can ve worked
> around by putting out a position statement, and have the developers
> proceed to ignore the foundation document on that basis?

No. I'm in fact saying that developers can ignore the position
statement on that basis.

> if that is not the case, what value does a position statement in
> contradiction of a foundation document mean?

Next to no value, as far as I'm concerned.

> How binding _are_ the foundation documents?

Only as binding as we as a group consider them to be.

Since the language they're written in is ambiguous, we can have
reasonable differences of opinion as to what the foundation documents
actually mean. A position statement about the foundation documents
only serves to state what a majority of the project thinks the
documents say; it doesn't change what the documents actually say.[1]

As such, people who think differently are free to ignore the position
statement in carrying out their duties (though they can of course be
overridden by GR.)


Don Armstrong

1: Fundamentally though, I find the whole process of making position
statements about the foundation documents tedious. If you think the
documents meaning is unclear, propose amendments to the documents to
make them clearer.
-- 
I really wanted to talk to her.
I just couldn't find an algorithm that fit.
 -- Peter Watts _Blindsight_ p294

http://www.donarmstrong.com  http://rzlab.ucr.edu


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

Re: Draft vote on constitutional issues

[Matthew Johnson]

On Sat May 02 00:32, Luk Claes wrote:
> I think trying to propose many options together is very wrong as you are 
> very probably not objective for all the options nor will you be able to 
> word it properly for the ones that do care about an option you don't really 
> care about.

I would vote all of these above Further Discussion, so I think it is
legitimate for me to propose and second them. Further more, in this
specific case I do not believe that Debian would be well served by a
vote which does not list all those options. I am trying very hard to
make sure that people are not voting FD first.

> The other risk you take by proposing many options at once is to mix 
> unrelated things in the same vote IMHO.

I am trying to be careful not to do this, I definitely believe that all
of the below are legitimate alternative options which very definitely
should be on the same ballot, as they address the same thing: making it
clear what options require a supermajority.

>> Option 1 - No Supermajority
>>
> I would be very surprised if this option would get enough seconds if you 
> would propose it.

Then fine, it can be removed. I have seen, I think, at least 3 mails to
the lists explicitly suggesting this, however.

>> Option 2 - All conflicting GR options require a Supermajority
>>
>> We believe that any GR which has an option which overrides some or all
>> of a foundation document, even temporarily, implicitly modifies it to
>> contain this exception and thus requires a 3:1 majority
>
> This all boils down to the definition of override which I tried to state in 
> the other thread. If you go by my definition, this is really a non-option 
> IMHO.

I'll address that below

>> This option amends the constitution and social contract and hence
>> requires a 3:1 majority.
>
> This option does not look related to supermajority requirements to me.

I just had to clarify this on IRC too. This option is "all conflicting
options need supermajority even if temporary", but then amending the SC
so that balancing SC1 and SC4 isn't conflicting with the SC. Sorry if
that wasn't clear.

>> Option 6 - Votes may modify or be a position statement, but must be explicit
>>
>> We believe that any vote which overrides a Foundation Document modifies
>> it to contain that exception and must explicitly say so in the proposal
>> before the vote proceeds.  Such overrides require a 3:1 majority.
>
> This is already the case AFAICS

The entire point of this vote is that opinions vary on what is already
the case. You think that option 6 is already the case. I think that
option 2 is already the case and some people think that option 5  is
already the case. All of use are absolutely convinced it's the only way
to read the constitution. I'm fed up of having arguments about what it
means, whether a particular reading is consistent, or what the spirit of
the constitution is. I want it to be explicit, hence this vote to
clarify it.

> PS: There is a reason why I send the mail about the definitions of the 
> terms even if Kurt as well as you seem to ignore it.

I posted a while back citing several types of vote option [0], with some
examlpes. I'm maybe not using the terminology you'd like, but I hope
you can see what I mean. Here they are again:

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"

5. is something like "Allow Lenny to release with  firmware blobs.  This
does not override the DFSG", which I don't think makes any sense.

Now, I understand you don't like the use of 'override' when describing
option 3, I'm happy to describe it as something else, but _I_ think that
the constitution at the moment requires 3:1 majority for this sort of
vote. I know other people are equally certain it does not, but this is
why I want to clarify it one way or another, to avoid future upset.

Incidentally my point of view is that 3 requires supermajority, 4 does
not and that 5 and 6 should be rejected by the secretary as invalid.

I hope that has explained things better and you can see where I'm coming
from,
Matt

0. http://lists.debian.org/debian-vote/2009/03/msg00091.html
-- 
Matthew Johnson


signature.asc
Description: Digital signature

Re: Overriding vs Amending vs Position statement

[Matthew Johnson]

On Sat May 02 00:52, Luk Claes wrote:
> It would be a clear indication that the foundation document should get an 
> update or that the postition statement should get dropped again.

I think Manoj's point is that if voting some option X (a position
statement in conflict with an FD) means that we have to vote to change
the FD or drop X, then why wasn't X a vote to change the FD in the first
place? Surely we don't need a vote just to then have another vote...

Matt
-- 
Matthew Johnson


signature.asc
Description: Digital signature

Re: Overriding vs Amending vs Position statement

[Steve Langasek]

On Fri, May 01, 2009 at 11:54:15PM +0100, Matthew Johnson wrote:
> On Sat May 02 00:52, Luk Claes wrote:
> > It would be a clear indication that the foundation document should get an 
> > update or that the postition statement should get dropped again.

> I think Manoj's point is that if voting some option X (a position
> statement in conflict with an FD) means that we have to vote to change
> the FD or drop X, then why wasn't X a vote to change the FD in the first
> place? Surely we don't need a vote just to then have another vote...

No one has the authority to declare, a priori, for the entire project, that
a given position statement is in conflict with a FD.

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

[Manoj Srivastava]

On Fri, May 01 2009, Don Armstrong wrote:


> Only as binding as we as a group consider them to be.

Hmm. Certainly puts the social contract in a new light, though.

> Since the language they're written in is ambiguous, we can have
> reasonable differences of opinion as to what the foundation documents
> actually mean. A position statement about the foundation documents
> only serves to state what a majority of the project thinks the
> documents say; it doesn't change what the documents actually say.[1]
>
> As such, people who think differently are free to ignore the position
> statement in carrying out their duties (though they can of course be
> overridden by GR.)

I think I can live with that.

Wait.

Oh. So this is a way, via two simple majority GR's, for any
 majority to do an end run around the 3:1 constitutional requirements?
 nifty.

manoj
-- 
Behind every great man, there is a woman -- urging him on. Harry Mudd,
"I, Mudd", stardate 4513.3
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

[Manoj Srivastava]

On Fri, May 01 2009, Steve Langasek wrote:

> On Fri, May 01, 2009 at 11:54:15PM +0100, Matthew Johnson wrote:
>> On Sat May 02 00:52, Luk Claes wrote:
>> > It would be a clear indication that the foundation document should get an 
>> > update or that the postition statement should get dropped again.
>
>> I think Manoj's point is that if voting some option X (a position
>> statement in conflict with an FD) means that we have to vote to change
>> the FD or drop X, then why wasn't X a vote to change the FD in the first
>> place? Surely we don't need a vote just to then have another vote...
>
> No one has the authority to declare, a priori, for the entire project, that
> a given position statement is in conflict with a FD.

Does anyone have authority, a posteriori, to declare that any
 given position statement is in contradiction of a foundation document?

Or is it only deliverable by a GR?

This will be interesting. So, in order to determine whether a
 foundation document is being modified, we first ask the  project, via a
 GR, whether it is indeed a contradiction. _THEN_ we hold a vote, with
 or without the 3:1 majority, based o the previous vote, to see if it
 passes or not.

I think Joey Hess is right.

manoj
-- 
Program: Any assignment that cannot be completed with one telephone
call. Kelvin Throop III, "The Management Dictionary"
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

[Manoj Srivastava]

On Fri, May 01 2009, Luk Claes wrote:

> Manoj Srivastava wrote:
>> On Fri, May 01 2009, Don Armstrong wrote:
>>
>>> On Fri, 01 May 2009, Luk Claes wrote:
 A position statement is a decided on proposal that clarifies the
 position of the Debian project, but does not explicitly amend a
 foundation document.
>>> [...]
>>>
 So I don't really see what we should vote on unless someone
 disagrees with above interpretations?
>>> The only question resides with the effect of passing such position
>>> statements. Without modifying foundation documents or the
>>> constitution, they are effectively non-binding advisory statements
>>> when operating within areas that are the remit of foundation documents
>>> or the constitution.
>>
>>> Developers can ignore (or follow) such statements as they wish.
>>
>> If the statements are in contradiction of the foundation
>>  document (which is the case in a couple of prior situations), then are
>>  you saying that anything in the foundation documents can ve worked
>>  around by putting out a position statement, and have the developers
>>  proceed to ignore the foundation document on that basis?
>
> Of course not. If a position statement contradicts a foundation
> document it's time to update the foundation document accordingly or
> drop the position statement again.

Err, so why not do it in one pass? Why this strange two pass
 vote?

How do you want to handle the case where a 51% majority wants
 the position, but no more than that? There is not enough votes to
 actually change the foundation docs in that case.

>
>> That also begs the question: do we _have_ to follow the
>>  foundation documents? Or can one just issue a statement "I do not agree
>>  with the foundation doc" and just ignore it at will?
>
> You do realise that a majority needs to agree with it before it turns
> into a position statement?

Sure. A bare majority, let us suppose.

> It's not because a position statement is not binding that a foundation
> document would also not be binding...

So why do you think the foundation document is not binding? (I
 must confess to having some problems parsing this statement).


>> if that is not the case, what value does a position statement in
>>  contradiction of a foundation document mean?
>
> It would be a clear indication that the foundation document should get
> an update or that the postition statement should get dropped again.

Why this torturous path? Why not see if there are actually votes
 to change the FD, rather than creating and dropping position
 statements? 


>> Can I just set a position statement that redefines all the owrds
>>  used in a  foundation doc to promote my "interpretation" of the
>>  foundation doc, as long as the majority of the people voting rate it
>>  over FD?
>
> This is actually asking if a position statement can clarify a
> foundation document but put in a twisted way AFAICS...

If by clarifying, youmean redefining all the words, sure.

>
>> How binding _are_ the foundation documents?
>
> Interesting question as you seem to be one to take the Constitution
> with a twisted interpretation when it fits you best in some previous
> occasions.

Aha. The first attack on the man, rather than the contents of my
 arguments. Jesus, it sure did not take long  for the conversation to
 descend to the pits.


>
>>  free === does not cost more than USD 1000300.73
>>  distribute == transport over trains between sunday noon and monday
>>morning 8:00am"
>>  Guidelines === something that must be followed in the ides of march
>
> I guess this is a bad attempt at a joke?

What joke? That might me my "interpretation", or, as you put it,
 the "clarification" of the SC.

manoj
-- 
In my experience, if you have to keep the lavatory door shut by
extending your left leg, it's modern architecture.  -- Nancy Banks Smith
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

[Don Armstrong]

On Fri, 01 May 2009, Manoj Srivastava wrote:
> On Fri, May 01 2009, Don Armstrong wrote:
> > Only as binding as we as a group consider them to be.
> 
> Hmm. Certainly puts the social contract in a new light, though.

It really shouldn't; as a group we decide whether we're going to
uphold the social contract. There's no way to force the group to
uphold it. [Given the anguish with which we struggle on -project and
-vote to figure out what the SC says, it's seems clear that large
numbers of us feel that we should be upholding the SC.]

> > As such, people who think differently are free to ignore the
> > position statement in carrying out their duties (though they can
> > of course be overridden by GR.)
> 
> Oh. So this is a way, via two simple majority GR's, for any majority
> to do an end run around the 3:1 constitutional requirements? nifty.

Sure. If we as a project are headed towards self-destruction, there's
really no way for the constitution to stop us. We always have to fall
back on the continued desire of developers to work together to create
the most technically excellent, free operating system possible.


Don Armstrong

-- 
This message brought to you by weapons of mass destruction related
program activities, and the letter G.

http://www.donarmstrong.com  http://rzlab.ucr.edu


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

Re: Firmware

[Paul Wise]

On Sat, May 2, 2009 at 6:10 AM, Joey Schulze  wrote:

> I would rather like to keep binary firmware blobs outside of Debian/main
> and maintain them in Debian/non-free with improved and easy ways to load
> them during the installation.

This is what appears to be happening in Linux upstream, so this vote
might not be needed.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

[Ben Finney]

Don Armstrong  writes:

> On Fri, 01 May 2009, Manoj Srivastava wrote:
> > On Fri, May 01 2009, Don Armstrong wrote:
> > > Only as binding as we as a group consider them to be.
> > 
> > Hmm. Certainly puts the social contract in a new light, though.
> 
> It really shouldn't; as a group we decide whether we're going to
> uphold the social contract. There's no way to force the group to
> uphold it.

That doesn't mean we can't make the explicit expectation that everyone
in the group *will* uphold it, as a condition of being in the group.

I had thought that expectation was embodied in the requirement for all
new members to declare they will uphold it.

-- 
 \  “Software patents provide one more means of controlling access |
  `\  to information. They are the tool of choice for the internet |
_o__) highwayman.” —Anthony Taylor |
Ben Finney


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

Re: Firmware

[Mike Hommey]

On Sat, May 02, 2009 at 12:10:26AM +0200, Joey Schulze wrote:
> Luk Claes wrote:
> > Hi
> >
> > As probably many of you know, the most heard criticism from users and  
> > press on Lenny's release is lost hardware support because of missing  
> > firmware. Users and press are complaining that their servers don't have  
> > network anymore after an upgrade or that their notebooks cannot be  
> > installed via wireless...
> >
> > It's of course possible to load firmware from extra media during  
> > installation or install the right package (from non-free) when booting  
> > back to an older kernel (to have network again) to be able to use the  
> > network with the new kernel...
> >
> > What do people think of a new vote regarding the status of firmware? One  
> > of the options can probably be Peter Palfrader's proposal [1].
> 
> I would rather like to keep binary firmware blobs outside of Debian/main
> and maintain them in Debian/non-free with improved and easy ways to load
> them during the installation.

I think this is less of a problem than making sure *existing*
installations don't break on upgrade because of the lack of some
firmware blobs after the upgrade.

Mike


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