Re: gr_lenny vs gr_socialcontract

[Manoj Srivastava]

On Fri, Dec 19 2008, Anthony Towns wrote:

> On Fri, Dec 19, 2008 at 09:54:08AM -0600, Manoj Srivastava wrote:
>> On Fri, Dec 19 2008, Anthony Towns wrote:
>> >> I tend to come down hard on the side of not compromising my
>> >>  principles for temporary convenience or popularity (or, if you will,
>> >>  market share).
>> >> To paraphrase: Those who give up essential freedoms for
>> >>  temporary convenience and popularity deserve neither.
>> > And, uh, isn't that a bit needlessly argumentative? Marc's not trying to
>> > get anyone to give up essential freedoms, or give them up himself.
>> I did not mean this to be argumentative. A rhetorical flourish,
>>  yes.  The quote is from a US politicial, and the analogy between the
>>  constitutions and bill of rights was amusing.
>
> Uh, surely it's obvious that following any example from a political arena
> is going to be much more argumentative than necessary?

Not to me, it isn't obvious. Ben Franklin was more than just a
 run-of-the-mill  joe politician, and a diplomat before standing for
 public office; and the quote seemed quite apropos, from my view.

However, since offense is in the eye of the beholder, I'll
 withdraw the amusing paraphrase.


>> But I do think that the DFSG represents the essential freedoms
>>  for software, as defined by the Debian project. Shipping stuff that
>>  violates the DFSG is indeed giving up essential freedoms, in my view.
>
> I consider being able to easily install Debian and get it running on
> whatever random hardware I buy an essential freedom, so I see most of

It is a convenience, not a freedom. There is a difference. And
 yes, even now, the ability to install non-free firmware using the
 Debian installer exists (since the user does not appear to care that
 the firmware in question is not actually free), thanks to the d-i team
 accepting a USB key with the firmware.

> this as people trying to take away my freedoms.  Obviously, your
> mileage varies, but that doesn't make either of us popularity seeking
> knaves.

I am not sure I cater to the view that all opinions are always
 correct.  You have a right to an opinion, and I have a right to regard
 that opinion as wrong. Now, I ought to be able  to convey that without
 sliding over into "needlessly argumentative" territory.  As to it being
 populist, I am not seeing that as provicative either; shifting to the
 side of convenience over abstract freedoms is a populist move (most
 people rarely exercise the freedoms that are granted to them by the
 DFSG).  I am not being argumentative here either -- I do think it is
 so, and I think I can defend that view.

I still hold that shipping non-free components as part of the
 Debian system, etc, etc, as above.

manoj
-- 
"He who flames improperly risks making an ash of himself!" Jeff Klumpp
(j...@ficc.uu.net)
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: RFC: General resolution: Clarify the status of the social contract

[Anthony Towns]

On Fri, Dec 19, 2008 at 09:10:25PM +0100, Robert Millan wrote:
> > ,[ The social contract is a goal, not a binding contract ]
> > |  This amends the proposal above, and replaces the text of the proposal
> > |  with: The developers, via a general resolution, determine that the
> > |  social contract is an aspirational document: while we aim to achieve as
> > |  much of it as feasible at all times, we don't expect to get it
> > |  completely right for some time yet. This includes DFSG-freeness of all
> > |  firmware
> > `

> > ,[ The social contract is a non-binding advisory document ]
> > |  This amends the proposal above, and replaces the text of the proposal
> > |  with: The developers, via a general resolution, determine that the
> > |  social contract is a statement of principle only, and has no particular
> > |  force on the day to day operations of Debian, except in so far as it
> > |  influences individual contributors' actions.
> > `
> How does this differ from the previous one in practice?

The main difference is in direction -- the former indicates that current
issues of non-compliance are bugs, that we promise to incrementally fix,
but aren't able to immediately.

The latter indicates the social contract is more of a "vision" or "mission
statement" -- something we might individually look to for guidance when
making decisions, but not something that's of practical influence.

So what's a practical difference? If you file a (valid) bug about some
package not-complying with the social contract (but somehow causing
no other ill-effects that would also justify the bug report), in the
former case the maintainer might reasonably defer it to post-lenny or
post-squeeze (perhaps with an -ignore tag in cooperation with the RMs,
or perhaps just by leaving a note in the bug log), while in the latter
the maintainer might reasonably close it outright, if that's what they
thought was appropriate.

(In none of the other cases could valid bugs about non-compliance with the
social contract reasonably be significantly deferred /or/ closed, where
"reasonably" means "in line with the project's expectations". stable
releases are one reasonable milestone for "significantly deferred",
but not the only one, IMO)

Cheers,
aj



signature.asc
Description: Digital signature

Re: RFC: General resolution: Clarify the status of the social contract

[Anthony Towns]

On Fri, Dec 19, 2008 at 12:18:01PM -0800, Russ Allbery wrote:
> I think these have the same flaw as our current situation: none of them
> state who interprets the Social Contract and the DSFG if there is a
> dispute over what they mean.  

If there is a dispute in Debian, there are three levels at which it's
dealt with formally:

   1) the maintainer asks for advice, and decides

   2) the technical committee reviews the technical impact of the decision,
  and offers advice, adjudicates or overrules (const 6.1(2,3,4))

   3) the developers as a whole decide by general resolution

Informally, the DPL (and others) can influence the people responsible at
point (1) pretty effectively, and the tech-ctte at point (2).

I guess there's some small possibility that there's a relevant impact
to a social contract decision that's both completely non-technical and
in some way enforcable, but I can't think of one. And there's the GR
process as back up then, anyway.

> Witness the arguments that led up to the "editorial changes" GR, for
> example.

Up until that social contract amendment GR, the relevant maintainers
decided (some maintainers split packages, others didn't, and the
ftpmasters accepted packages into main so long as the programs in the
package were DFSG-free). It wasn't referred to the tech ctte iirc,
and eventually there was a GR.

That went fine, with the exception that perhaps people didn't give
enough attention to that GR, in the context of the attempts to freeze
and release sarge, the just finished "don't drop non-free" GR, and the
2004 DPL elections.

Obviously the result of the GR turned out to be arguably ambiguous in
and of itself, though I still don't think I've seen anyone saying that
releasing non-free documentation/firmware/etc complies with the current
text. It certainly turned out to be a surprising result to many, at least.

In any event, at the first stage, my interpretation (as maintainer of
the release and I guess to a lesser extent as one of the ftpmasters)
was it meant we needed to immediately drop non-free stuff and I posted
to -devel to that effect [0], offering all the alternatives I could
see. There were lots of responses, and they quickly got heated enough
[1,2,3,etc] that I metaphorically threw my hands up in the air to let
the other mechanisms operate (and eventually stepped down as RM). The
tech-ctte didn't go anywhere [4], the GR process did [5].

[0] http://lists.debian.org/debian-devel/2004/04/msg01929.html
[1] http://lists.debian.org/debian-devel/2004/04/msg01959.html
[2] http://lists.debian.org/debian-devel/2004/04/msg01996.html
[3] http://lists.debian.org/debian-devel/2004/04/msg02664.html
[4] http://lists.debian.org/debian-ctte/2004/05/msg4.html
[5] http://www.debian.org/vote/2004/vote_004

That seems to me to have been a perfectly adequate way of resolving
disputes then, I don't see why a different one would be needed.

> Otherwise, even if we say the social contract is binding, it doesn't
> resolve the current problem or future problems like it.

Wouldn't it be nice to know if we consider the social contract explicitly
binding though? Not everyone did then [6] or does now [7], eg.

[6] http://lists.debian.org/debian-devel/2004/04/msg02022.html
[7] 
http://www.earth.li/~noodles/blog/2008/12/debian-king-of-procrastination.html

In any event, as far as the current problem is concerned, is there anyone
who thinks the current situation complies with the social contract as it
stands today? If not, in what doesn't knowing that the social contract
is binding (along with what we actually want the social contract to say
wrt this) resolve the current problem?

Cheers,
aj, who personally thinks Debian would already be 100% free stuff in
main (docs, fonts, firmware, blobs, etc), if we hadn't distracted
outselves by promising it prematurely


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

Re: gr_lenny vs gr_socialcontract

[Anthony Towns]

On Fri, Dec 19, 2008 at 09:54:08AM -0600, Manoj Srivastava wrote:
> On Fri, Dec 19 2008, Anthony Towns wrote:
> >> I tend to come down hard on the side of not compromising my
> >>  principles for temporary convenience or popularity (or, if you will,
> >>  market share).
> >> To paraphrase: Those who give up essential freedoms for
> >>  temporary convenience and popularity deserve neither.
> > And, uh, isn't that a bit needlessly argumentative? Marc's not trying to
> > get anyone to give up essential freedoms, or give them up himself.
> I did not mean this to be argumentative. A rhetorical flourish,
>  yes.  The quote is from a US politicial, and the analogy between the
>  constitutions and bill of rights was amusing.

Uh, surely it's obvious that following any example from a political arena
is going to be much more argumentative than necessary?

Politics is the art of making people who disagree with you look stupid
and immoral. Surely we can accept that fellow developers who disagree
on these issues aren't stupid or immoral?

> But I do think that the DFSG represents the essential freedoms
>  for software, as defined by the Debian project. Shipping stuff that
>  violates the DFSG is indeed giving up essential freedoms, in my view.

I consider being able to easily install Debian and get it running on
whatever random hardware I buy an essential freedom, so I see most of
this as people trying to take away my freedoms.  Obviously, your mileage
varies, but that doesn't make either of us popularity seeking knaves.

> Now, you might find my honestly and deeply held views to be off
>  the wall enough to call mere statements of my beliefs needlessly
>  argumentative, but then we have a failure in that we can't even discuss
>  things rationally.

If I did find your honestly and deeply held views off the wall, maybe
we couldn't discuss things rationally. I don't however. All I did was
critique the way you expressed yourself.

Cheers,
aj


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

Re: RFC: General resolution: Clarify the status of the social contract

[Anthony Towns]

> On Fri Dec 19 21:10, Robert Millan wrote:
> > > ,[ The social contract is binding but may be overridden by a simple 
> > > GR ]
> > > |  This amends the proposal above, and replaces the text of the proposal
> > > |  with: The developers, via a general resolution, determine that the
> > > |  social contract should apply to /almost/ everything Debian does, now
> > > |  and in the future; _AND_ for the few cases where it should not apply
> > > |  now, there should be an explicit GR affirming that variation (by simple
> > > |  majority)
> > > `
> > I don't like the "workaround" approach to supermajority requirements.  If
> > we don't want 3:1, why don't we ammend the Constitution instead?

If you don't like an option, preference a different one. That's the way
(preferential) voting works.

The reason some people might like the workaround option is it makes it
clear what the goal is, and requires specific, clear, repeated effort to
/not/ meet the goal. They might like that either because you think it'll
make people think it's easier to meet the goal than not, or because it
puts the focus where we want it (front and centre in the social contract:
100% free), but still makes it clear to everyone what's going on (project
wide vote acknowledging we haven't freed some firmware yet, eg).

On Fri, Dec 19, 2008 at 08:31:34PM +, Matthew Johnson wrote:
> I assume any final proposal would explicitly amend the SC/constitution
> to state this. In fact, I'm tempted to say that _all_ of these should
> include SC/Constitution amendments to make them explicitly state that
> position

All of those proposals are "position statements on issues of the day",
they don't purport to modify the social contract or the DFSG or the
constitution; they just give the project's understanding of where things
are at. As such they only require a simple majority to pass.

As far as voting for a position statement along the lines of "the social
contract doesn't matter, we'll upload Microsoft Word into main, yay!",
I believe that would also require a simple majority (1:1) to pass, and
would hope that a vast majority of the project would join me in voting
against it. If a majority of developers are making position statements
out of line with the social contract, I don't think there's much point
being part of some honourable minority trying to keep them in check.

Cheers,
aj



signature.asc
Description: Digital signature

Re: gr_lenny vs gr_socialcontract

[Steve Langasek]

On Fri, Dec 19, 2008 at 05:00:59PM +, Ian Lynagh wrote:

> "We need some time to solve the problems that are in main" the first
> time round I can live with, but uploading new instances of the same
> problems to main,

I think this is a strawman that doesn't correspond either to what has
actually happened in the archive, or to the declared intentions of the
release team.

-- 
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: RFC: General resolution: Clarify the status of the social contract

[Raphael Geissert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

Manoj Srivastava wrote:
> Hi,
> 
> I like the idea of clarifying what the principles of the project
>  actually are, since, as aj said, all the decisions about lenny would
>  fall out from the position the project take about the foundation
>  documents. While I have always thought that "foundation" implied  the
>  proposal below, apparently this is not a universally held view.
> 

+1!

[...]
> 
> ,[ The social contract is a non-binding advisory document ]
> |  This amends the proposal above, and replaces the text of the proposal
> |  with: The developers, via a general resolution, determine that the
> |  social contract is a statement of principle only, and has no particular

I think "is a statement of principle only" weakens too much the pourpose of the
SC.

What about:

 ,[ nice title here ]
 |  The developers, via a general resolution, hold true the promise made in
 |  point one of the social contract, and determine that everyday work including
 |  the one that turns in to the so called releases, include their best efforts
 |  to accomplish the promise.
 `

Goal: accomplish the promise, as it has not yet been fully accomplished.

Cheers,
- -- 
Raphael Geissert - Debian Maintainer
www.debian.org - get.debian.net

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAklMXpoACgkQYy49rUbZzloOoACgmxl5ryslRhD2fBPMBisEhA5j
NhIAnjFPvqhixdfYbt9DpRHgDkuiWnQ6
=V0/u
-END PGP SIGNATURE-


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

Re: First call for votes for the Lenny release GR

[Steve Langasek]

On Fri, Dec 19, 2008 at 05:09:32PM +, Matthew Johnson wrote:

> > Yes, that's perfectly fine - and also non-binding, so the 80% of the DDs who
> > didn't vote, the 47% of the voters who voted against it, and the 2% of the
> > voters who didn't read before voting can ignore that position statement and
> > continue doing things just as they were before.

> So... you're saying there's no point at all in such a GR? The GR says
> "we will do X" but even after we pass it we still can't do X because it
> would contravene the SC or DFSG? How is that a useful thing at all?
> What's the point?

The point in *allowing* this is to have a simple system by which the
project's majority view can be expressed.

On Fri, Dec 19, 2008 at 08:20:30PM +, Matthew Johnson wrote:
> But... _how_ can it be the case that having the NVidia drivers in main
> (sorry to keep on with this example, but I want something where it's
>  clear whether it meets the DFSG or not) is what the project wants when
> it's clearly going against our foundation documents. There's an inherent
> contradition. The SC says "we won't ship non-free stuff" and the GR says
> "actually we will ship non-free stuff (except we can't really because
> the SC says we can't)". It makes no sense.

In this hypothetical case which is not at all analogous to the complex issue
currently under discussion:  if a majority of voters vote that we should put
Nvidia drivers in main, then your fundamental problem is that you have a
majority of people (or at least, voters) in Debian who think it's ok to put
Nvidia drivers in main.  Your only real choices, then, are to persuade them
that they're wrong, live with it, drive them off, or leave.

The other option you're proposing here, to prevent them from doing what they
want to unless they have a 3:1 majority, reduces to "coerce the majority to
do what you say they should do, even though they don't think you're right".

Do you really think that's a solution to the above pathological scenario?


> NVidia drivers are just a placeholder to illustrate the point. You
> definitely _can't_ claim that they meet the DFSG (but you could change
> it to allow them anyway). However, you do raise something here which
> people may be confusing. A vote that said "we will assume that firmware
> is in source form" is very different to one which says "we don't care
> whether or not it is source form". The former says "we keep the DFSG as
> it is, but we are asserting that they comply unless we can prove
> otherwise" and the latter says "even if we can prove otherwise we will
> change the DFSG so that it is allowed" The former is 1:1 and the latter
> is 3:1. It may be a subtle difference, but it's an important one,
> because it sets precedent for future issues where the difference is not
> so subtle.

I think the difference between the two is that in the former we're blatantly
lying to ourselves about whether we're in compliance and rewarding people
for not providing evidence of non-compliance by giving them a timely release
in return, and in the latter is being honest with ourselves and our users.
I don't see why we should be encouraged to lie to ourselves.

-- 
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: Results for Project membership procedures

[Joey Hess]

aj wrote:
>   Joey Hess

Hmm, I have the ballot (3341) that I sent in on Dec 14th right here. I
have logs indicating it got to master[1] half an hour before deadline. I
see I got an ACK for the other ballot, sent at the same time, but not
for this one.

Anyway, it's always interesting to see your vote analysis. Managing to
make this vote actually mean something is quit an accomplishment.

-- 
see shy jo

[1] Dec 14 23:24:34 wren postfix/smtp[10681]: 1216131437A: 
to=, relay=master.debian.org[70.103.162.29]:25, 
delay=6.7, delays=2.3/0.02/3.5/0.79, dsn=2.0.0, status=sent (250 OK 
id=1LC50U-0004Tc-EZ)


signature.asc
Description: Digital signature

Re: RFC: General resolution: Clarify the status of the social contract

[Manoj Srivastava]

On Fri, Dec 19 2008, Luk Claes wrote:

> Manoj Srivastava wrote:
>> Hi,
>> 
>> I like the idea of clarifying what the principles of the project
>>  actually are, since, as aj said, all the decisions about lenny would
>>  fall out from the position the project take about the foundation
>>  documents. While I have always thought that "foundation" implied  the
>>  proposal below, apparently this is not a universally held view.
>
> You want to clarify what the principles of the project really are and
> all you talk about is point 1 of the Social Contract??!
>
> Maybe you take the other points for granted, though it surely looks
> strange to me.

So, where is your proposed wording which will not appear strange
 to you?

> I also think it's rather strange to talk about binding and non-binding
> regarding 'Guidelines'. As long as it are guidelines, the question will
> always remain how to interprete them in any circumstance AFAICS.

The social contract is supposedly a contract. Also, the last two
 of thte options in the mail seem to be where you are coming from. If
 not feel free to suggest other options or better wording.

manoj
-- 
Sometimes I worry about being a success in a mediocre world. Lily Tomlin
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: First call for votes for the Lenny release GR

[Manoj Srivastava]

On Fri, Dec 19 2008, Russ Allbery wrote:

> Matthew Johnson  writes:

> Furthermore, by my reading of the constitution, even if a delegate
> override or a position statement clearly and obviously contradicted the
> DFSG, as long as it doesn't actually change or set aside the DFSG, it's
> still just a 1:1 majority.  Success of the GR would overturn that
> decision, even in a direction that contradicts the DFSG, because in
> practice there's no higher authority in Debian to declare that the
> decision contradicts the DFSG and a majority of developers just said, in
> effect, that it doesn't.

This sounds like weaseling around our foundation documents. We
 won't do what the social contract says, but in out NewSpeak, we are not
 changing the SC. We are, uhhh, just going to do something else, but,
 err, the contract is valid.

While the constitution might not prohibit this behaviour, I
 would find actually doing this very dishonest, and just plain lying.

If we  have sunk so low as to require some entity to keep us
 away from NewSpeak, so be it, I just find that makes trusting the
 project impossible.

manoj
-- 
New members are urgently needed in the Society for Prevention of Cruelty
to Yourself.  Apply within.
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: First call for votes for the Lenny release GR

[Manoj Srivastava]

On Fri, Dec 19 2008, Steve Langasek wrote:

> On Fri, Dec 19, 2008 at 09:50:42PM +, Matthew Johnson wrote:
>> Then the 3:1 requirement is nonsense and the SC and DFSG effectively
>> optional. I don't believe that was the intention when they were drafted.
>
> They were drafted before the constitution was and their binding power does
> *not* flow *from* the constitution.

Sorry, no. I do not find that logically follows. Before we
 accepted the constitution, the allocation of powers was all ad-hoc.  We
 even had project leaders and "delegates" before the constitution too.

When the constitution was adopted, the ad-hoc power structure
 was swept away, and the new power structure detailed in the
 constitution came into effect. Saying that we had DPL's and ftp-masters
 before so theya re above the constitution does not hold. Heck, we had
 developers before, so those of us who were inducted in before we had a
 constitution are somehow not bound by it, unless we voted in favour? I
 do not see the logic here.

manoj
-- 
If God had wanted us to be concerned for the plight of the toads, he
would have made them cute and furry.  -- Dave Barry
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: First call for votes for the Lenny release GR

[Manoj Srivastava]

On Fri, Dec 19 2008, Russ Allbery wrote:


> However, you can also override *individual decisions*, and that requires
> only a simple majority.  So it would be possible, under the constitution,
> to get NVidia drivers into main with a set of 1:1 delegate overrides: you
> override the ftp-master's decision that it's non-free, and then you
> override the release team's decision that it's non-free, and so forth.
> Those overrides aren't binding on any future developer decisions, only on
> those specific ones.

So your position is essentially that the foundation documents
 are not really binding on any developer, and even in cases where the
 developer thinks they are binding, a simple majoiry can effectively
 vacate that.

Does not sound like much of a contract to me, and I must reject
 this interpretation.

manoj
-- 
In order to live free and happily, you must sacrifice boredom. It is not
always an easy sacrifice.
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: RFC: General resolution: Clarify the status of the social contract

[Luk Claes]

Manoj Srivastava wrote:
> Hi,
> 
> I like the idea of clarifying what the principles of the project
>  actually are, since, as aj said, all the decisions about lenny would
>  fall out from the position the project take about the foundation
>  documents. While I have always thought that "foundation" implied  the
>  proposal below, apparently this is not a universally held view.

You want to clarify what the principles of the project really are and
all you talk about is point 1 of the Social Contract??!

Maybe you take the other points for granted, though it surely looks
strange to me.

I also think it's rather strange to talk about binding and non-binding
regarding 'Guidelines'. As long as it are guidelines, the question will
always remain how to interprete them in any circumstance AFAICS.

Cheers

Luk


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

Re: First call for votes for the Lenny release GR

[Matthew Johnson]

On Fri Dec 19 14:00, Russ Allbery wrote:
> Matthew Johnson  writes:
> > On Fri Dec 19 13:08, Russ Allbery wrote:
> 
> >> This is the root of the argument, really, and is what I'm trying to get
> >> across.  Foundation documents do not have some sort of Platonic True
> >> Meaning that exists outside of the governance process.  The words mean
> >> what people with the authority to make decisions decide they mean, and
> >> those decisions have no special protection or role in the constitution.
> >> Therefore, in a very real sense the DFSG and SC mean whatever a simple
> >> majority of developers decide that they mean in each specific case
> >> where a GR is applied.
> 
> > Then the 3:1 requirement is nonsense
> 
> No, a 3:1 requirement is still required to change or replace those
> documents, and as long as they're not changed or replaced, they will have
> a powerful persuasive effect on voting.  This was also Raphael's point.
> We all agreed to follow them.  This is not a negligible effect.

I mean that you can effectively ignore them through a series of 1:1
votes which have the same effect as rewriting them. The repeated
'release X with firmware' votes we've had are an example of this. We
could rewrite the DFSG to always allow them which would need 3:1, but
why bother when we could just have a 1:1 vote every release.

> > I don't believe that was the intention when they were drafted.
> 
> Whether it's the intent or not, I believe what I've spelled out is the
> practical effect.  If you want some other effect, you *have* to spell out
> who decides what the meaning is.  You cannot rely on everyone "just
> knowing" the meaning.  People aren't going to agree, and someone has to
> pick which meaning is correct.

Sure, which is what we have now. Hence I will be seconding all options
on Manoj's RFC because I think we need to pick a position and spell it
out explicitly. We clearly disagree about what the current position is.

matt
-- 
Matthew Johnson


signature.asc
Description: Digital signature

Re: First call for votes for the Lenny release GR

[Steve Langasek]

On Fri, Dec 19, 2008 at 09:50:42PM +, Matthew Johnson wrote:
> Then the 3:1 requirement is nonsense and the SC and DFSG effectively
> optional. I don't believe that was the intention when they were drafted.

They were drafted before the constitution was and their binding power does
*not* flow *from* the constitution.

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

Freedom and pragmatism (was: I hereby resign as secretary)

[Ben Finney]

Noah Meyerhans  writes:

> On Fri, Dec 19, 2008 at 05:04:55PM +, Ian Lynagh wrote:
> > I believe that part of the problem is that we are not all here to
> > create "a free operating system". I have the impression that some
> > developers merely wish to create "an operating system", or perhaps
> > a "'free-enough-for-me' operating system".
> 
> OTOH, it seems to me that there are people with varying degrees of
> pragmatism.

That implies a (lamentably common) false dichotomy. Free software
goals *are* pragmatic goals. They directly affect how we interact with
the digital information that infuses our lives; essential freedom in
that sphere is a highly pragmatic goal.

There may be reasons that compel us to reduce our freedom, and they
may also be described as “pragmatic”. But it's wrong to imply that
those who strive for freedom don't do so for very pragmatic reasons.

-- 
 \“We cannot solve our problems with the same thinking we used |
  `\   when we created them.” —Albert Einstein |
_o__)  |
Ben Finney


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

Re: First call for votes for the Lenny release GR

[Russ Allbery]

Matthew Johnson  writes:
> On Fri Dec 19 13:08, Russ Allbery wrote:

>> This is the root of the argument, really, and is what I'm trying to get
>> across.  Foundation documents do not have some sort of Platonic True
>> Meaning that exists outside of the governance process.  The words mean
>> what people with the authority to make decisions decide they mean, and
>> those decisions have no special protection or role in the constitution.
>> Therefore, in a very real sense the DFSG and SC mean whatever a simple
>> majority of developers decide that they mean in each specific case
>> where a GR is applied.

> Then the 3:1 requirement is nonsense

No, a 3:1 requirement is still required to change or replace those
documents, and as long as they're not changed or replaced, they will have
a powerful persuasive effect on voting.  This was also Raphael's point.
We all agreed to follow them.  This is not a negligible effect.

> and the SC and DFSG effectively optional.

Majority rule is not equivalent to optional.

> I don't believe that was the intention when they were drafted.

Whether it's the intent or not, I believe what I've spelled out is the
practical effect.  If you want some other effect, you *have* to spell out
who decides what the meaning is.  You cannot rely on everyone "just
knowing" the meaning.  People aren't going to agree, and someone has to
pick which meaning is correct.

-- 
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: First call for votes for the Lenny release GR

[Matthew Johnson]

On Fri Dec 19 13:08, Russ Allbery wrote:
> There's nothing in the consititution that prohibits passing nonsensical
> GRs or GRs that contradict foundation documents, as long as they don't
> actually alter the foundation documents.

Given a ballot option which does not explicitly specify whether or not
it is a. pointless or b. overriding the foundation document with which
it clearly conflicts I think for sanity's sake it should be assumed to
be the latter and hence have a 3:1 majority requirement. Either that or
the secretary should refuse to list any options which do not explicitly
resolve their conflict with a foundation document

> > Nvidia drivers are just a placeholder here. Insert firmware or anything
> > else which might have support. I wanted an example that was clear I'm
> > talking about definitely non-free stuff, not arguing whether binary
> > vectors in header files are defacto source form.
> 
> Unfortunately, by simplifying, you're removing the factor that makes this
> vote so problematic, namely the disagreement over whether what the GR says
> is contradictory or not.  One of the many sides in the current debate is
> the position that putting source-less firmware into main does *not*
> contradict the DFSG.

Indeed and the option which said that was 1:1. The options which said
that even though they contradicted the DFSG we would let them through
were 3:1

> > NVidia drivers are just a placeholder to illustrate the point. You
> > definitely _can't_ claim that they meet the DFSG (but you could change
> > it to allow them anyway). However, you do raise something here which
> > people may be confusing. A vote that said "we will assume that firmware
> > is in source form" is very different to one which says "we don't care
> > whether or not it is source form". The former says "we keep the DFSG as
> > it is, but we are asserting that they comply unless we can prove
> > otherwise" and the latter says "even if we can prove otherwise we will
> > change the DFSG so that it is allowed" The former is 1:1 and the latter
> > is 3:1.
> 
> I agree with this, since the latter says that you're going to change the
> DFSG.  But the firmware case doesn't necessarily say that.  One of the
> positions held about firmware is that it's not a program provided by
> Debian in the sense used in the SC and DFSG.  Holding that position
> doesn't require changing the DFSG.

Sure, that's fine, but not what I'm talking about

> This is the root of the argument, really, and is what I'm trying to get
> across.  Foundation documents do not have some sort of Platonic True
> Meaning that exists outside of the governance process.  The words mean
> what people with the authority to make decisions decide they mean, and
> those decisions have no special protection or role in the constitution.
> Therefore, in a very real sense the DFSG and SC mean whatever a simple
> majority of developers decide that they mean in each specific case where a
> GR is applied.

Then the 3:1 requirement is nonsense and the SC and DFSG effectively
optional. I don't believe that was the intention when they were drafted.

Matt

-- 
Matthew Johnson


signature.asc
Description: Digital signature

Re: RFC: General resolution: Clarify the status of the social contract

[Charles Plessy]

Le Fri, Dec 19, 2008 at 01:38:33PM -0600, Manoj Srivastava a écrit :
> 
>  [  ] The Social contract is a binding contract
>  [  ] The social contract is binding, but currently flawed
>  [  ] The social contract is binding but may be overridden by a simple GR
>  [  ] The social contract is a goal, not a binding contract
>  [  ] The social contract is a non-binding advisory document

Dear all,

I think that we all show signs of exhaustion, frustration and demotivation. For
some it is because important issues are not settled, for others it is because
we do not relase, and for others it is because our mailboxes explode (by the
way, please stop cross-posting).

I think that starting another GR now will do more harm than good. Maybe the
best opportunity to test if the Project is in the mood for formal reforms is
the next DPL election.

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: First call for votes for the Lenny release GR

[Russ Allbery]

Matthew Johnson  writes:
> On Fri Dec 19 12:04, Russ Allbery wrote:

>> The only point of non-binding resolutions of the sense of the project
>> is to try to persuade people who might otherwise not think that's what
>> the project wants.  They don't, in and of themselves, *do* anything.

> But... _how_ can it be the case that having the NVidia drivers in main
> (sorry to keep on with this example, but I want something where it's
> clear whether it meets the DFSG or not) is what the project wants when
> it's clearly going against our foundation documents.  There's an
> inherent contradition. The SC says "we won't ship non-free stuff" and
> the GR says "actually we will ship non-free stuff (except we can't
> really because the SC says we can't)". It makes no sense.

There's nothing in the consititution that prohibits passing nonsensical
GRs or GRs that contradict foundation documents, as long as they don't
actually alter the foundation documents.

> Nvidia drivers are just a placeholder here. Insert firmware or anything
> else which might have support. I wanted an example that was clear I'm
> talking about definitely non-free stuff, not arguing whether binary
> vectors in header files are defacto source form.

Unfortunately, by simplifying, you're removing the factor that makes this
vote so problematic, namely the disagreement over whether what the GR says
is contradictory or not.  One of the many sides in the current debate is
the position that putting source-less firmware into main does *not*
contradict the DFSG.

>> However, you can also override *individual decisions*, and that
>> requires only a simple majority.  So it would be possible, under the
>> constitution, to get NVidia drivers into main with a set of 1:1
>> delegate overrides: you override the ftp-master's decision that it's
>> non-free, and then you override the release team's decision that it's
>> non-free, and so forth.  Those overrides aren't binding on any future
>> developer decisions, only on those specific ones.

> See, I see no way to justify this position.

I'm justifying it by reading the text of the constitution, rather than by
trying to apply some sort of common-sense guidelines.  :)

> 1:1 delegate/developer overrides are for two choices where either would
> meet the foundation documents.

The constitution doesn't say this.  This would be a perfectly reasonable
governance process, but it's not the governance process we have right now.
The only limit written into the consititution on what a delegate override
can be used to decide is that it has to be a decision authorized by the
powers of the delegate, and determining the meaning and application of
foundation documents, since it's not called out anywhere in the
constitution, falls to the normal decision-making process and hence is a
decision authorized by the powers of delegates.

> Voting to allow us to ship non-free stuff is completely different. If we
> had those votes you suggest then I would immediately be filing a serious
> bug against the package because it is in violation of Debian policy.

And with a delegate override, the project with a 1:1 GR can force adding a
lenny-ignore tag to that bug.

You'd need a ton of delegate override GRs to do this sort of thing in
practice, which is yet another reason why it's not a real threat, since
there are many separate delegates who have the power to stop it from
happening.  But I don't see anything in the consititution that would
prohibit the project, in theory, from passing all those overrides.

> NVidia drivers are just a placeholder to illustrate the point. You
> definitely _can't_ claim that they meet the DFSG (but you could change
> it to allow them anyway). However, you do raise something here which
> people may be confusing. A vote that said "we will assume that firmware
> is in source form" is very different to one which says "we don't care
> whether or not it is source form". The former says "we keep the DFSG as
> it is, but we are asserting that they comply unless we can prove
> otherwise" and the latter says "even if we can prove otherwise we will
> change the DFSG so that it is allowed" The former is 1:1 and the latter
> is 3:1.

I agree with this, since the latter says that you're going to change the
DFSG.  But the firmware case doesn't necessarily say that.  One of the
positions held about firmware is that it's not a program provided by
Debian in the sense used in the SC and DFSG.  Holding that position
doesn't require changing the DFSG.

Furthermore, by my reading of the constitution, even if a delegate
override or a position statement clearly and obviously contradicted the
DFSG, as long as it doesn't actually change or set aside the DFSG, it's
still just a 1:1 majority.  Success of the GR would overturn that
decision, even in a direction that contradicts the DFSG, because in
practice there's no higher authority in Debian to declare that the
decision contradicts the DFSG and a majority of developers just said, in
effect

Re: RFC: General resolution: Clarify the status of the social contract

[Steve Langasek]

On Fri, Dec 19, 2008 at 12:18:01PM -0800, Russ Allbery wrote:
> If we're going to have a vote on this topic, I feel quite strongly that
> every option which states the social contract is binding should include in
> it a constitutional amendment specifying *who* decides for the project
> what those documents mean and what the procedure is to override that
> decision (can't be overridden, requires a 3:1 majority to override, etc.).

While formally I agree that this should be a requirement for such a system,
I will vote against any such GR because all this does is add another layer
of indirection to our decision-making process that we don't need.

The heart of the dispute over the current ballot is that the secretary has
assumed the power to intervene in the very process of how the project takes
decisions.  Regardless of whether this is acceptable under the constitution
(which I don't believe it is), I think it's a very wrong model, and that if
we're to make any changes at all they should be to *correct* this instead of
codifying it.

> * Each individual developer when doing their own work (advantage: what we
>   have now, according to my reading, but gives rise to lots of debate when
>   those scopes overlap, such as when a GR is proposed and the secretary
>   has to prepare the ballot)

Given the privileged position of the secretary (immune even to direct recall
by the developers), I think it should be made unequivocally clear that the
secretary should not be interpreting the SC at all as part of the ballot
drafting, and should be interpreting the constitution parsimoniously.  But
given that the constitution already calls for the secretary to engage in
consensus-driven decision-making, I'm not sure how the latter can be made
any more clear.

-- 
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: RFC: General resolution: Clarify the status of the social contract

[Russ Allbery]

Manoj Srivastava  writes:

> I do ont think that determining who interprets the
>  non-constitution foundation documents belongs on the same ballot.

That seems entirely reasonable to me, and I agree on the undesireability
of combinatorial explosion of the ballot.

>  It is a flaw in the constitution, and should be fixed, I would second
>  proposals that let the secretary not just interpret the constitution,
>  but all other foundation documents as well. This seems in line with the
>  constitution already handing tot hte secretary the role of interpreting
>  the constitution.

In theory, I agree.  In practice, if we vote the SC as binding, it puts
the secretary in the unenviable position of delaying releases or rejecting
package uploads without having a popular mandate.  There are major
advantages to that for stability of decisions, but socially, there are
also major disadvantages personally for the secretary.  It sets up the
secretary to be the project whipping boy.  I certainly would not want that
job.

That's one of the reasons why I think the DPL may be a better choice.  At
least there's a clear vote for the DPL and the feeling that the DPL is
supported by the project as a whole in a real and concrete way every year,
which gives the DPL more social authority to make hard decisions while
hopefully making it less likely (although not completely unlikely) that
they'll have to deal with the sort of crap that you've dealt with over the
last week or two.

-- 
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: RFC: General resolution: Clarify the status of the social contract

[Manoj Srivastava]

 [  ] The Social contract is a binding contract, DPL interprets
 [  ] The Social contract is a binding contract, secretary interprets
 [  ] The Social contract is a binding contract, tech ctte interprets
 [  ] The Social contract is a binding contract, individuals interpret
 [  ] The Social contract is a binding contract, new ctte interprets

 [  ] The social contract is binding, but currently flawed, DPL interprets
 [  ] The social contract is binding, but currently flawed, secretary interprets
 [  ] The social contract is binding, but currently flawed, tech ctte interprets
 [  ] The social contract is binding, but currently flawed, individuals 
interpret
 [  ] The social contract is binding, but currently flawed, new ctte interprets

 [  ] The social contract is binding but may be overridden by a simple GR, DPL 
interprets
 [  ] The social contract is binding but may be overridden by a simple GR, 
secretary interprets
 [  ] The social contract is binding but may be overridden by a simple GR, tech 
ctte interprets
 [  ] The social contract is binding but may be overridden by a simple GR, 
individuals interpret
 [  ] The social contract is binding but may be overridden by a simple GR, new 
ctte interprets

 [  ] The social contract is a goal, not a binding contract
 [  ] The social contract is a non-binding advisory document

 [  ] Further Discussion

I would hate to have to run that vote.

I strongly suggest we separate these orthogonal issues.

manoj
-- 
Any discovery is more likely to be exploited by the wicked than applied
by the virtuous.  -- Marion J. Levy, Jr.
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: RFC: General resolution: Clarify the status of the social contract

[Manoj Srivastava]

On Fri, Dec 19 2008, Russ Allbery wrote:

> Manoj Srivastava  writes:
>
>> I think we will keep coming back to this biennial spate of
>>  disagreement we have, as we determine whether or not we can release
>>  with firmware blobs or what have you. This also would help developers,
>>  the ftp-masters, and the release team with a clear cut expression of
>>  the projects goals and clarifies how the project has decided to view
>>  the social contract.
>>
>> Given that, I suggest we have a series of proposals and
>>  amendments, each in a separate email, sponsored and seconded
>>  independently, that could look something like this below:
>
> I think these have the same flaw as our current situation: none of them
> state who interprets the Social Contract and the DSFG if there is a
> dispute over what they mean.  We know there will be such disputes.  Just
> saying that they're binding (or not binding) doesn't resolve those
> disputes.

I do ont think that determining who interprets the
 non-constitution foundation documents belongs on the same ballot. It is
 a flaw in the constitution, and should be fixed, I would second
 proposals that let the secretary not just interpret the constitution,
 but all other foundation documents as well. This seems in line with the
 constitution already handing tot hte secretary the role of interpreting
 the constitution.

I also like the fact that then the secretary is given the role
 of interpreting the foundation documents, and determining final form of
 the ballots; I would suggest that the secretary be stripped of the
 power to run the actual vote (a wee bit of automation to devotee will
 allow somewone else to run it. This way the secretary has no more
 access to the votes that people cast than any other developer.

Again, a constitutional amendment modifying the powers of the
 secretary should be discussed independently of deciding what the role
 of the SC is.

manoj
-- 
There are two ways of disliking poetry; one way is to dislike it, the
other is to read Pope.  -- Oscar Wilde
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: RFC: General resolution: Clarify the status of the social contract

[Matthew Johnson]

On Fri Dec 19 21:10, Robert Millan wrote:
> > ,[ The social contract is binding but may be overridden by a simple GR ]
> > |  This amends the proposal above, and replaces the text of the proposal
> > |  with: The developers, via a general resolution, determine that the
> > |  social contract should apply to /almost/ everything Debian does, now
> > |  and in the future; _AND_ for the few cases where it should not apply
> > |  now, there should be an explicit GR affirming that variation (by simple
> > |  majority)
> > `
> 
> I don't like the "workaround" approach to supermajority requirements.  If
> we don't want 3:1, why don't we ammend the Constitution instead?

I assume any final proposal would explicitly amend the SC/constitution
to state this. In fact, I'm tempted to say that _all_ of these should
include SC/Constitution amendments to make them explicitly state that
position (and hence 3:1. I _really_ hope we can make 3:1 on this vote,
the project is in a sad state if we can't)

Matt

-- 
Matthew Johnson


signature.asc
Description: Digital signature

Re: First call for votes for the Lenny release GR

[Matthew Johnson]

On Fri Dec 19 12:04, Russ Allbery wrote:
> Here's the way I see it, which I think is similar to how Steve is seeing
> it:
> 
> The only point of non-binding resolutions of the sense of the project is
> to try to persuade people who might otherwise not think that's what the
> project wants.  They don't, in and of themselves, *do* anything.

But... _how_ can it be the case that having the NVidia drivers in main
(sorry to keep on with this example, but I want something where it's
 clear whether it meets the DFSG or not) is what the project wants when
it's clearly going against our foundation documents. There's an inherent
contradition. The SC says "we won't ship non-free stuff" and the GR says
"actually we will ship non-free stuff (except we can't really because
the SC says we can't)". It makes no sense.

Nvidia drivers are just a placeholder here. Insert firmware or anything
else which might have support. I wanted an example that was clear I'm
talking about definitely non-free stuff, not arguing whether binary
vectors in header files are defacto source form.

> However, you can also override *individual decisions*, and that requires
> only a simple majority.  So it would be possible, under the constitution,
> to get NVidia drivers into main with a set of 1:1 delegate overrides: you
> override the ftp-master's decision that it's non-free, and then you
> override the release team's decision that it's non-free, and so forth.
> Those overrides aren't binding on any future developer decisions, only on
> those specific ones.

See, I see no way to justify this position. 1:1 delegate/developer
overrides are for two choices where either would meet the foundation
documents. Including wordpress in etch, for example (which went to the
TC rather than GR), declassifying debian-private, overriding Joerg's
membership proposal. In all these cases either course of action meets
the foundation documents. Voting to allow us to ship non-free stuff is
completely different. If we had those votes you suggest then I would
immediately be filing a serious bug against the package because it is in
violation of Debian policy.

> I agree wholeheartedly with Raphael: I don't see this as any real threat.
> Even people who think we should ship NVidia drivers in main aren't going
> to vote in sufficient numbers for a GR that says they meet the DFSG.  (And
> if they did, we have other problems that voting rules aren't going to fix,
> no matter what rules we're trying to apply.)

NVidia drivers are just a placeholder to illustrate the point. You
definitely _can't_ claim that they meet the DFSG (but you could change
it to allow them anyway). However, you do raise something here which
people may be confusing. A vote that said "we will assume that firmware
is in source form" is very different to one which says "we don't care
whether or not it is source form". The former says "we keep the DFSG as
it is, but we are asserting that they comply unless we can prove
otherwise" and the latter says "even if we can prove otherwise we will
change the DFSG so that it is allowed" The former is 1:1 and the latter
is 3:1. It may be a subtle difference, but it's an important one,
because it sets precedent for future issues where the difference is not
so subtle.

Matt
-- 
Matthew Johnson


signature.asc
Description: Digital signature

Re: RFC: General resolution: Clarify the status of the social contract

[Russ Allbery]

Manoj Srivastava  writes:

> I think we will keep coming back to this biennial spate of
>  disagreement we have, as we determine whether or not we can release
>  with firmware blobs or what have you. This also would help developers,
>  the ftp-masters, and the release team with a clear cut expression of
>  the projects goals and clarifies how the project has decided to view
>  the social contract.
>
> Given that, I suggest we have a series of proposals and
>  amendments, each in a separate email, sponsored and seconded
>  independently, that could look something like this below:

I think these have the same flaw as our current situation: none of them
state who interprets the Social Contract and the DSFG if there is a
dispute over what they mean.  We know there will be such disputes.  Just
saying that they're binding (or not binding) doesn't resolve those
disputes.

Witness the arguments that led up to the "editorial changes" GR, for
example.  I'm quite certain that we've not resolved all ambiguity for all
future issues.

If we're going to have a vote on this topic, I feel quite strongly that
every option which states the social contract is binding should include in
it a constitutional amendment specifying *who* decides for the project
what those documents mean and what the procedure is to override that
decision (can't be overridden, requires a 3:1 majority to override, etc.).

Some possible options for that body:

* The DPL (advantage: most directly representative governance figure)

* The Secretary (advantage: not directly representative and hence somewhat
  akin to a Supreme Court judge in the US legal system, able to make
  independent decisions without being beholden to an electorate)

* Each individual developer when doing their own work (advantage: what we
  have now, according to my reading, but gives rise to lots of debate when
  those scopes overlap, such as when a GR is proposed and the secretary
  has to prepare the ballot)

* The Technical Committee (probably not the right body, but has the
  advantage of having override machinery already built into the
  constitution)

* Some new body (probably a really bad idea, but included for completeness)

Otherwise, even if we say the social contract is binding, it doesn't
resolve the current problem or future problems like it.

-- 
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: RFC: General resolution: Clarify the status of the social contract

[Robert Millan]

On Fri, Dec 19, 2008 at 01:38:33PM -0600, Manoj Srivastava wrote:
> 
> ,[ The Social contract is a binding contract ]
> | The developers, via a general resolution, determine that the social
> | contract should apply to everything Debian does, now and in the future;
> | _AND_ the social contract should stop us from including anything that
> | doesn't comply with the DFSG in main
> `

"main" is just the name of an archive section.  The SC says that "Debian"
is 100% free, so I think we should go with that instead, regardless of how
DAK calls it.

> ,[ The social contract is binding, but currently flawed ]
> |  This amends the proposal above, and replaces the text of the proposal with:
> |  The developers, via a general resolution, determine that the social
> |  contract should apply to everything Debian does, now and in the future;
> |  _AND_ it is and was a mistake to have the DFSG  cover firmware because
> |  we have not yet been able to limit Debian to  only DFSG-free firmware
> |  in a suitable way. This mistake should be corrected by amending the
> |  social contract.
> `

Would probably be a good idea to define firmware here.  Besides, isn't there
an option in the gr_lenny vote that is basicaly equivalent to this?

> ,[ The social contract is binding but may be overridden by a simple GR ]
> |  This amends the proposal above, and replaces the text of the proposal
> |  with: The developers, via a general resolution, determine that the
> |  social contract should apply to /almost/ everything Debian does, now
> |  and in the future; _AND_ for the few cases where it should not apply
> |  now, there should be an explicit GR affirming that variation (by simple
> |  majority)
> `

I don't like the "workaround" approach to supermajority requirements.  If
we don't want 3:1, why don't we ammend the Constitution instead?

> ,[ The social contract is a goal, not a binding contract ]
> |  This amends the proposal above, and replaces the text of the proposal
> |  with: The developers, via a general resolution, determine that the
> |  social contract is an aspirational document: while we aim to achieve as
> |  much of it as feasible at all times, we don't expect to get it
> |  completely right for some time yet. This includes DFSG-freeness of all
> |  firmware
> `

Doesn't that contradict the definition of "contract" ?  Maybe a rename would
be in order.

> ,[ The social contract is a non-binding advisory document ]
> |  This amends the proposal above, and replaces the text of the proposal
> |  with: The developers, via a general resolution, determine that the
> |  social contract is a statement of principle only, and has no particular
> |  force on the day to day operations of Debian, except in so far as it
> |  influences individual contributors' actions.
> `

How does this differ from the previous one in practice?

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."


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

Re: First call for votes for the Lenny release GR

[Russ Allbery]

Matthew Johnson  writes:

> So... you're saying there's no point at all in such a GR? The GR says
> "we will do X" but even after we pass it we still can't do X because it
> would contravene the SC or DFSG? How is that a useful thing at all?
> What's the point?

Here's the way I see it, which I think is similar to how Steve is seeing
it:

The only point of non-binding resolutions of the sense of the project is
to try to persuade people who might otherwise not think that's what the
project wants.  They don't, in and of themselves, *do* anything.

To make a change that's binding on all developers going forward, you have
to alter a foundation document and get a 3:1 majority.

However, you can also override *individual decisions*, and that requires
only a simple majority.  So it would be possible, under the constitution,
to get NVidia drivers into main with a set of 1:1 delegate overrides: you
override the ftp-master's decision that it's non-free, and then you
override the release team's decision that it's non-free, and so forth.
Those overrides aren't binding on any future developer decisions, only on
those specific ones.

I agree wholeheartedly with Raphael: I don't see this as any real threat.
Even people who think we should ship NVidia drivers in main aren't going
to vote in sufficient numbers for a GR that says they meet the DFSG.  (And
if they did, we have other problems that voting rules aren't going to fix,
no matter what rules we're trying to apply.)

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

RFC: General resolution: Clarify the status of the social contract

[Manoj Srivastava]

Hi,

I like the idea of clarifying what the principles of the project
 actually are, since, as aj said, all the decisions about lenny would
 fall out from the position the project take about the foundation
 documents. While I have always thought that "foundation" implied  the
 proposal below, apparently this is not a universally held view.

I think we will keep coming back to this biennial spate of
 disagreement we have, as we determine whether or not we can release
 with firmware blobs or what have you. This also would help developers,
 the ftp-masters, and the release team with a clear cut expression of
 the projects goals and clarifies how the project has decided to view
 the social contract.

Given that, I suggest we have a series of proposals and
 amendments, each in a separate email, sponsored and seconded
 independently, that could look something like this below:

,[ The Social contract is a binding contract ]
| The developers, via a general resolution, determine that the social
| contract should apply to everything Debian does, now and in the future;
| _AND_ the social contract should stop us from including anything that
| doesn't comply with the DFSG in main
`

,[ The social contract is binding, but currently flawed ]
|  This amends the proposal above, and replaces the text of the proposal with:
|  The developers, via a general resolution, determine that the social
|  contract should apply to everything Debian does, now and in the future;
|  _AND_ it is and was a mistake to have the DFSG  cover firmware because
|  we have not yet been able to limit Debian to  only DFSG-free firmware
|  in a suitable way. This mistake should be corrected by amending the
|  social contract.
`

,[ The social contract is binding but may be overridden by a simple GR ]
|  This amends the proposal above, and replaces the text of the proposal
|  with: The developers, via a general resolution, determine that the
|  social contract should apply to /almost/ everything Debian does, now
|  and in the future; _AND_ for the few cases where it should not apply
|  now, there should be an explicit GR affirming that variation (by simple
|  majority)
`

,[ The social contract is a goal, not a binding contract ]
|  This amends the proposal above, and replaces the text of the proposal
|  with: The developers, via a general resolution, determine that the
|  social contract is an aspirational document: while we aim to achieve as
|  much of it as feasible at all times, we don't expect to get it
|  completely right for some time yet. This includes DFSG-freeness of all
|  firmware
`

,[ The social contract is a non-binding advisory document ]
|  This amends the proposal above, and replaces the text of the proposal
|  with: The developers, via a general resolution, determine that the
|  social contract is a statement of principle only, and has no particular
|  force on the day to day operations of Debian, except in so far as it
|  influences individual contributors' actions.
`

If all these variations get sponsored and seconded, the ballot
 would look like:

 [  ] The Social contract is a binding contract
 [  ] The social contract is binding, but currently flawed
 [  ] The social contract is binding but may be overridden by a simple GR
 [  ] The social contract is a goal, not a binding contract
 [  ] The social contract is a non-binding advisory document

I think we need this clarification, so people no longer accuse
 other people of malfeasance based on a flawed understanding on the
 correct status of foundation documents.

I do have an ulterior motive: clarifying this will help those of
 us currently evaluating whether this is the project they signed up for,
 and whether we want to continue to be a part of it. Some of the options
 above, if they passed, would be a clear proof that the project might
 have moved on from the principles that were in effect when we joined
 the project.

manoj
-- 
May you do Good Magic with Perl. Larry Wall's blessing
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


pgpvzCpaNmUZX.pgp
Description: PGP signature

Re: Re: I hereby resign as secretary

[Noah Meyerhans]

On Fri, Dec 19, 2008 at 05:04:55PM +, Ian Lynagh wrote:
> > project atmosphere.  The only way we can "get things back on track"
> > and re-focus our energy on the real reason we are all here... to
> > create a free operating system...
> 
> I believe that part of the problem is that we are not all here to create
> "a free operating system". I have the impression that some developers
> merely wish to create "an operating system", or perhaps a
> "'free-enough-for-me' operating system".

OTOH, it seems to me that there are people with varying degrees of
pragmatism.  I believe that we are all here to create a free operating
system.  However, there are those for whom an imperfect release is
better than no release at all, while there are others who believe that
if the release can't be made 100% free then it is not ready.
Personally, I'm quite happy to stand in the former group.  While I
believe that shipping non-free blobs is distasteful and unfortunate, I
believe that our users are better served by timely and functional
releases.

But then again, I also believe it to be insane that we don't allow
ourselves to include, for example, RFCs as a part of our OS.  Clearly
I'm not a true supporter of free software. 

noah



signature.asc
Description: Digital signature

Re: I hereby resign as secretary

[Robert Millan]

On Thu, Dec 18, 2008 at 08:44:11AM -0600, Manoj Srivastava wrote:
> 
> As to the people who emailed me that they are putting together a
>  petition for the DAM to have me removed from the project, I hear you
>  too. I am going to spend the next few days evaluating how important the
>  project is to me, and whether I should save you the bother or an
>  expulsion process.

Hi Manoj,

I'm not going to argue on your decision to resign as secretary, because I
understand how hard it must have been to go through all this pressure just
to do what is, in your judgement, your obligation in this position [1].

OTOH, triing to have you removed from the project looks a lot like a purely
emotional response, which IMO cannot be justified even if we take as granted
that you acted irresponsibly as secretary (which, btw, I don't).

Because this response is completely unjustified, I'd like to ask that you
don't vindicate them as you suggest you would.  Please force them to go
through it themselves.  Force them to provide non-sense arguments to the
DAM, and to make up silly excuses for everyone to read.  In the end, they'll
make fools of themselves no matter if they succeed or not, and I believe
it's what they deserve.  Let them make their own karma.

[1] For those who believe that I'm an uncompromising zealot (you guys know who
you are ;-) ), notice that I vocally disagreed with Manoj's decision not to
split the votes in separate ballots.  This doesn't change anything I said
in this mail, nor make me feel that his decisions as secretary are somehow
illegitimate.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."


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

Re: First call for votes for the Lenny release GR

[Matthew Johnson]

On Fri Dec 19 08:58, Steve Langasek wrote:
> On Fri, Dec 19, 2008 at 02:12:01PM +, Matthew Johnson wrote:
> > On Fri Dec 19 14:24, Raphael Hertzog wrote:
> 
> > > It is. Does the resolution say what the new version of the foundation
> > > document will look like if it's accepted ? If yes, then it supersedes the
> > > document. Otherwise it doesn't.
> 
> > So, if someone proposes a GR saying "we will ship the binary NVidia
> > drivers in main and make them the default so that people can use compiz"
> > but doesn't say they are overriding the DFSG or provide the wdiff for it
> > then that's fine and only needs 1:1 to pass?
> 
> Yes, that's perfectly fine - and also non-binding, so the 80% of the DDs who
> didn't vote, the 47% of the voters who voted against it, and the 2% of the
> voters who didn't read before voting can ignore that position statement and
> continue doing things just as they were before.
 
So... you're saying there's no point at all in such a GR? The GR says
"we will do X" but even after we pass it we still can't do X because it
would contravene the SC or DFSG? How is that a useful thing at all?
What's the point?

Matt

-- 
Matthew Johnson


signature.asc
Description: Digital signature

Re: Re: I hereby resign as secretary

[Ian Lynagh]

On Fri, Dec 19, 2008 at 07:47:50AM -0700, Bdale Garbee wrote:
> 
> project atmosphere.  The only way we can "get things back on track"
> and re-focus our energy on the real reason we are all here... to
> create a free operating system...

I believe that part of the problem is that we are not all here to create
"a free operating system". I have the impression that some developers
merely wish to create "an operating system", or perhaps a
"'free-enough-for-me' operating system".


Thanks
Ian


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

Re: gr_lenny vs gr_socialcontract

[Ian Lynagh]

On Fri, Dec 19, 2008 at 05:28:20PM +0100, Josselin Mouette wrote:
> 
> In short, the ongoing GR isn’t about this disagreement, for which a
> suitable compromise already exists; it is about imposing more
> restrictions on the stable release than on the unstable suite.

I do not know about anyone else, but personally, as someone who doesn't
believe we should be releasing non-free stuff, I also don't think that
developers should be uploading it to unstable.

"We need some time to solve the problems that are in main" the first
time round I can live with, but uploading new instances of the same
problems to main, and then continuing to allow ourselves to ignore them,
doesn't sound like the path to a Free operating system to me.


Thanks
Ian


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

Re: First call for votes for the Lenny release GR

[Steve Langasek]

On Fri, Dec 19, 2008 at 02:12:01PM +, Matthew Johnson wrote:
> On Fri Dec 19 14:24, Raphael Hertzog wrote:

> > It is. Does the resolution say what the new version of the foundation
> > document will look like if it's accepted ? If yes, then it supersedes the
> > document. Otherwise it doesn't.

> So, if someone proposes a GR saying "we will ship the binary NVidia
> drivers in main and make them the default so that people can use compiz"
> but doesn't say they are overriding the DFSG or provide the wdiff for it
> then that's fine and only needs 1:1 to pass?

Yes, that's perfectly fine - and also non-binding, so the 80% of the DDs who
didn't vote, the 47% of the voters who voted against it, and the 2% of the
voters who didn't read before voting can ignore that position statement and
continue doing things just as they were before.

Just like, *constitutionally*, any individual developer can already ignore
the Social Contract or DFSG at their discretion.

This is not an argument that it's ok for developers to ignore the SC.  I'm
merely pointing out that adherence to the SC does *not* follow from the
constitution, so *constitutional* arguments about why decisions to set aside
the SC should require the same supermajority as superseding the SC are
invalid!

So please stop trying to use the constitution for an easy out when you want
to override the conscience of your fellow developers.  You still need a
simple majority of people *in favor* of your GR in order to accomplish that;
blocking an expression of the majority opinion by imposing a supermajority
requirement that doesn't follow from the letter of the constitution does not
accomplish that.  The default is still that each developer is going to do
what they personally believe is right.

-- 
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: gr_lenny vs gr_socialcontract

[Josselin Mouette]

Le vendredi 19 décembre 2008 à 12:36 +0100, Marc Haber a écrit :
> This is something we need to agree to disagree on. There are people
> who still focus on "The Universal Operating System", and who are
> willing to make compromises in freedom without being willing to make a
> totally non-free OS.

And both categories should already be happy since it is easy to load
firmware distributed in non-free. I’m amazed by the number of posts who
completely ignore this fact and focus on issues that have already solved
technically.

In short, the ongoing GR isn’t about this disagreement, for which a
suitable compromise already exists; it is about imposing more
restrictions on the stable release than on the unstable suite.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: I hereby resign as secretary

[Michael Banck]

On Thu, Dec 18, 2008 at 11:00:26PM +0100, Pierre Habouzit wrote:
> > On Thu, Dec 18, 2008 at 08:44:11AM -0600, Manoj Srivastava wrote:
> > > As to the people who emailed me that they are putting together a
> > >  petition for the DAM to have me removed from the project, I hear you
> > >  too. I am going to spend the next few days evaluating how important the
> > >  project is to me, and whether I should save you the bother or an
> > >  expulsion process.
 
> Huh, who talked about expelling Manoj !?

Doesn't the above paragraph imply that?


Michael, skipping the expel vs. expulse joke


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

Re: gr_lenny vs gr_socialcontract

[Manoj Srivastava]

On Fri, Dec 19 2008, Anthony Towns wrote:

> On Fri, Dec 19, 2008 at 08:12:28AM +0100, Marc Haber wrote:
>> Putting an USB key into most of my servers requires some hours of
>> driving and jumping through security hoops to get datacenter access.
>> [...]
>> I'd prefer an OS which allows full remote installation that does not
>> need some kind of physical access.
>
> On Fri, Dec 19, 2008 at 01:50:40AM -0600, Manoj Srivastava wrote:
>> I suspect it would not be hard to create a non-free installer CD
>>  that obviates the requirement of a separate USB key for remote
>>  installs.
>
> So isn't this exactly why we have a voting system? Everyone understands
> both points of view here, don't they? We just need to choose which one
> Debian's going to adopt, because we haven't implemented a way of having
> our cake and eating it too on this score.

Sure. 

>> I tend to come down hard on the side of not compromising my
>>  principles for temporary convenience or popularity (or, if you will,
>>  market share).
>> 
>> To paraphrase: Those who give up essential freedoms for
>>  temporary convenience and popularity deserve neither.
>
> And, uh, isn't that a bit needlessly argumentative? Marc's not trying to
> get anyone to give up essential freedoms, or give them up himself.

I did not mean this to be argumentative. A rhetorical flourish,
 yes.  The quote is from a US politicial, and the analogy between the
 constitutions and bill of rights was amusing.

But I do think that the DFSG represents the essential freedoms
 for software, as defined by the Debian project. Shipping stuff that
 violates the DFSG is indeed giving up essential freedoms, in my view.

Now, you might find my honestly and deeply held views to be off
 the wall enough to call mere statements of my beliefs needlessly
 argumentative, but then we have a failure in that we can't even discuss
 things rationally.

manoj
-- 
The average nutritional value of promises is roughly zero.
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: gr_lenny vs gr_socialcontract

[Simon Richter]

Hi,

On Fri, Dec 19, 2008 at 12:36:54PM +0100, Marc Haber wrote:
> On Fri, Dec 19, 2008 at 01:50:40AM -0600, Manoj Srivastava wrote:

> > To paraphrase: Those who give up essential freedoms for
> >  temporary convenience and popularity deserve neither.

> This is something we need to agree to disagree on. There are people
> who still focus on "The Universal Operating System", and who are
> willing to make compromises in freedom without being willing to make a
> totally non-free OS.

System-on-a-Chip designs which already provide the necessary interfaces
have become the cheapest option in hardware design, and the most robust way
to drive this hardware is indeed to load the firmware at startup because it
brings the "hardware" into a known state.

The firmware problem will never go away, because there is always new
hardware being built.

For some chips (e.g. the FX2 USB controllers), there is a chance that we
might get free firmware for certain device classes soonish, since these are
well documented, but until that happens, I think seeing the interface
presented by the firmware as the "hardware" interface and requiring that
all drivers talking to this interface be free software is enough for us.

   Simon


signature.asc
Description: Digital signature

Re: First call for votes for the Lenny release GR

[Manoj Srivastava]

On Fri, Dec 19 2008, Raphael Hertzog wrote:

> On Fri, 19 Dec 2008, Matthew Johnson wrote:
>> On Fri Dec 19 14:24, Raphael Hertzog wrote:
>> 
>> > It is. Does the resolution say what the new version of the foundation
>> > document will look like if it's accepted ? If yes, then it supersedes the
>> > document. Otherwise it doesn't.
>> 
>> So, if someone proposes a GR saying "we will ship the binary NVidia
>> drivers in main and make them the default so that people can use compiz"
>> but doesn't say they are overriding the DFSG or provide the wdiff for it
>> then that's fine and only needs 1:1 to pass?
>
> Yes. 
>
> But try it, you will see that it won't even get the required seconds to
> start the vote. And if it does, it will largely fail anyway. 

> As I said, we all have agreed to abide by the social contract, you'd need
> a serious rationale to convince me that this is coherent with our
> long-term goal.

Hmm. All that says is that you have drawn the line at one
 point, not that the project has. I find it hard to see how shipping
 non-free blobs in main is coherent with our long-term goal; but
 obviously people in the project do not.  Therefore, I find it
 unconvincing to say that people will behave or vote a particular way.


> Either we trust the democracy or we don't. The 3:1 ratio is not here to
> protect us from insanity, it's only a matter of making sure that we all
> agree if we want to change the direction in which we're headed.

My take on it was that if we resolve to do something that is
 contradiction of the foundation document, the only logical way to
 interpret that is to accept that we are, if only temporarily, changing
 the direction we are headed in. We might intend to turn back to the
 path later, but for not, the direction is being changed.

manoj
-- 
In Hollywood, if you don't have happiness, you send out for it. Rex Reed
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: First call for votes for the Lenny release GR

[Manoj Srivastava]

On Fri, Dec 19 2008, Raphael Hertzog wrote:


> And please don't assume that a majority of developers are insane
> and want to pervert the project. If that is the case, we're all in
> a bad situation anyway. :-)

Insanity is subjective.  In some sense, some of the the
 interpretations of our foundation documents brings to my mind shades of
 NewSpeak. I know that is not how other people meant it to be; so we
 have enough differences in opinion that acts of inasnity by some are
 rational behaviour by others, and we have grown to the point that there
 is no single definition of insanity that would govern the statement
 above.

I have seen either side in the firmware debate staunchly believe
 the other side was, err, insane.

manoj
-- 
I am not a politician and my other habits are also good. Ward
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: First call for votes for the Lenny release GR

[Matthew Johnson]

On Fri Dec 19 16:03, Raphael Hertzog wrote:
> On Fri, 19 Dec 2008, Matthew Johnson wrote:
> > On Fri Dec 19 14:24, Raphael Hertzog wrote:
> > 
> > > It is. Does the resolution say what the new version of the foundation
> > > document will look like if it's accepted ? If yes, then it supersedes the
> > > document. Otherwise it doesn't.
> > 
> > So, if someone proposes a GR saying "we will ship the binary NVidia
> > drivers in main and make them the default so that people can use compiz"
> > but doesn't say they are overriding the DFSG or provide the wdiff for it
> > then that's fine and only needs 1:1 to pass?
> 
> Yes. 
> 
> But try it, you will see that it won't even get the required seconds to
> start the vote. And if it does, it will largely fail anyway. 

Well, sure, I don't think it'll get seconds nor do I think it will pass,
that wasn't the point. My point was that it is clearly lunacy to say
that it's not a 3:1 option, it's _clearly_ in direct violation of a
foundation document. Either it passes but we can't do it anyway because
there's an immediate RC bug against it or it must de facto be
superceeding a foundation document.

> Either we trust the democracy or we don't. The 3:1 ratio is not here to
> protect us from insanity, it's only a matter of making sure that we all
> agree if we want to change the direction in which we're headed.

Yes, and shipping the NVidia drivers in main would be such a change of
direction, whether exact wording of the GR option claims to modify the
DFSG or not.

Matt
-- 
Matthew Johnson


signature.asc
Description: Digital signature

Re: gr_lenny vs gr_socialcontract

[Didier Raboud]

Didier Raboud wrote:

> Providing a guaranteed (as much of Debian's knowledge) free Linux kernel
> and installer in main would be really fulfilling Debian's promises. This
> does not necessarily exclude providing a "contaminated" installer and/or
> kernel in contrib (or elsewhere).

I just forgot some warnings…

This is obviously a "perfect world" goal, where everybody is paid to work on
Free Software projects. This was not to say "Debian-{Boot,Kernel} team has
to do the work needed to make it possible"

More something like a statement of principles…

Regards, OdyX
-- 
Swisslinux.org − Le carrefour GNU/Linux en Suisse −
http://www.swisslinux.org


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

Re: gr_lenny vs gr_socialcontract

[Didier Raboud]

Mike O'Connor wrote:
> 
> If we make users have to decide between the "100% free installer" and
> the "installer with non-free", and it makes the user have to think about
> "what is this non-free stuff, and why should I care".  I think it is an
> added side benefit.  If a user at some point decides to "vote with their
> pocketbook", by choosing a piece of hardware based on its compatibility
> with debian, I think that could also be a benefit.

+1

Having a "really free-software" install path would be really good, even if
not working on every hardware out there

Some hardware already need non-free stuff from the beginning on; why not
providing a -dfsg (or "normal") and a -contrib (or whatever) one for all
the non-free hardware out there ?

Where is the difference between:

* using a contaminated installer from main and not adding non-free firmware
* using a non-contaminated installer from main and adding non-free firmware 

In any case, for a firmware-needing hardware, either non-free firmwares or
presumably non-free blobs have to be used.

In swiss-french, we say: "Il ne faut pas cacher la merde au chat"
(approximatively: "Don't hide the shit to the cat")

Providing a guaranteed (as much of Debian's knowledge) free Linux kernel and
installer in main would be really fulfilling Debian's promises. This does
not necessarily exclude providing a "contaminated" installer and/or kernel
in contrib (or elsewhere).

This, in my user's eyes, would be "not hiding the shit to the cat"…

> A line has to be drawn somewhere. 

+1

> The arguments about "we are losing users to [other distro] becuase of
> this"  Hold very little weight.  "Be a popular distro" is not a goal of
> debian, "Be a free distro" is.  "Let's include non-free software because
> everyone else is" is a counter-argument to me.  If we are the only ones
> left that cares so much, all the more reason to stick to our principles.
> 
> stew

+1 again.

OdyX

-- 
Swisslinux.org − Le carrefour GNU/Linux en Suisse −
http://www.swisslinux.org


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

Re: First call for votes for the Lenny release GR

[Raphael Hertzog]

On Fri, 19 Dec 2008, Matthew Johnson wrote:
> On Fri Dec 19 14:24, Raphael Hertzog wrote:
> 
> > It is. Does the resolution say what the new version of the foundation
> > document will look like if it's accepted ? If yes, then it supersedes the
> > document. Otherwise it doesn't.
> 
> So, if someone proposes a GR saying "we will ship the binary NVidia
> drivers in main and make them the default so that people can use compiz"
> but doesn't say they are overriding the DFSG or provide the wdiff for it
> then that's fine and only needs 1:1 to pass?

Yes. 

But try it, you will see that it won't even get the required seconds to
start the vote. And if it does, it will largely fail anyway. 

As I said, we all have agreed to abide by the social contract, you'd need
a serious rationale to convince me that this is coherent with our
long-term goal.

Either we trust the democracy or we don't. The 3:1 ratio is not here to
protect us from insanity, it's only a matter of making sure that we all
agree if we want to change the direction in which we're headed.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


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

Re: First call for votes for the Lenny release GR

[Patrick Schoenfeld]

Hi,

On Fri, Dec 19, 2008 at 02:24:35PM +0100, Raphael Hertzog wrote:
> > > Superseding a document is easily recognizable: it's when you explicitely
> > > say that you're going to change its _content_ (ex:
> > > http://www.debian.org/vote/2004/vote_003 ).
> > 
> > I wouldn't say that it is that easy. 
> 
> It is. Does the resolution say what the new version of the foundation
> document will look like if it's accepted ? If yes, then it supersedes the
> document. Otherwise it doesn't.

Well, I could now they "No, its not" but that wouldn't help us.
I guess we need to agree to disagree in this point.
My opinion stays the same: The effect of superseding a foundation
document and temporary overriding it is the same, except that the latter
is timely limited.

> > We do not have rules for temporary overriding a foundation document, 
> > therefore
> > we need to apply one of the rules we have. 
> 
> I'm sorry, you don't have to pick one of the existing rules and stretch it
> to cover some unexpected case. The default rule for position statement
> applies and it's a GR with a 1:1 ratio.

Its not stretching, it is following the spirit of the rule.

> No. In one case, we alter our (long-term) goal, in the other we don't.

No. We _do_ alter a (long-term) goal in both cases. You seem to forget
that every point in our DFSG is a goal in itself. The only difference is
that the altering becomes undone automagically.

> Anthony Towns is right. Some people take the social contract as a law.
> Other take it as a goal. We probably need to clear up this. But even if
> we consider it as law, the social contract is written in such a way that
> there's room for interpretation, whereas the constitution is much more
> precise in all our rules.

Well, the "room for interpretation" is the biggest problem. As we see
our interpretation is different for something where no explicit rule
exists. There is no "default case" explicitly spelled out in the document
and so I think we should decide consistent with the existing rules.

And I really disagree that this is just a "Position Statement".
IMHO you cannot override rules with "Position Statements", you can only spell
out how you think rules are to be applied. For example you can say
that from your point of view Firmware does match the Source
Requirements, because it *is* the preferred form of modification, but
you cannot say "No, I don't care that we need source for everything, let
them (the firmwares) in."

So I think we probably should amend the consitution instead of endlessly
discussing about our different interpretations. We should decide which
rules shall apply for cases that are not yet described in the
constitution, like for example the "What majority is required to
temporary override a DFSG-rule?".

And I tell you: I'd vote for a single majority requirement. But I don't
think that a single majority requirement is right *right now*.

> I'm at a loss… I don't know how I can better explain the problem. I'll thy
> nevertheless:
> 
> If you consider that we all agree on the goals (and for me this is a
> given, we all agreed to the social contract), imposing a 3:1 ratio
> on any vote that should decide how we will handle the next step (that
> should bring us closer to our goals) is an effective way to block
> any progress: we've seen at numerous occasions that consensus is
> almost unachievable and that we need fair decision-making process.

Its nice that you try to make your point better understandable, but its
not neccessary. I do understand the problem. I know that it is _hard_ to
get a 3:1 majority. But it is _possible_ if the (!) majority of the
developers have the same opinion. And its exactly what is wanted by
having a 3:1 requirement for changing any kind of rule: making it hard
to change/replace that rule.

If you say that we need a "fair decision-making process" that implicits
that we don't have that already. This means we would need to
change/alter the consitution. But we cannot simply forget about it and
decide as we see fit, when there are others who have a different
opinion.

> Imposing consensus is okay when it comes to changing/altering our
> objectives. But it's not okay when it comes to decisions on how we want to
> reach our objectives. 

We do not decide about how to reach our objectives. We decide
weither we want to ignore a certain objective, or not. That is a big
difference.

> I hope this clears it up.

No. It only shows, that we disagree in interpretation of our foundation
documents and the constitution. Thats not that bad, because binding is only the
interpretation of the majority or existing rules.

BTW. I really would like to see a pro-firmware decision, but I have a
different view on how easy it should be.

Best Regards,
Patrick


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

Re: gr_lenny vs gr_socialcontract

[Mike O'Connor]

On Fri, Dec 19, 2008 at 02:44:46PM +0100, Johannes Wiedersich wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Manoj Srivastava wrote:
> > I suspect it would not be hard to create a non-free installer CD
> >  that obviates the requirement of a separate USB key for remote
> >  installs.
> 
> If (almost?) everyone will use non-free stuff anyway, why not just make
> live more easy for everyone and include it on all the installer images.
> People still have the freedom to buy freely supported hardware or to not
> use non-free firmware.

So then debian becomes the "100% Free Operating System (some
restrictions apply.  see details*)

(* Operating system deosn't include installer images, or kernel.  Freedom
only guaranteed on one CPU.)

> 
> I don't think that any computer will be more 'free' whether some
> non-free code is loaded on boot from hard disk (kernel firmware blob) or
> whether the non-free code is loaded from ROM like the BIOS. IMHO, it
> also does not contribute in any way to freedom to force users to load
> the firmware blobs from a separate installation medium.  Or to drive them
> into buying hardware with on board ROM chips for the then still non-free
> firmware/software.

The point isn't to try to force users to only have free software on
their machines, the point is to only have free software in debian.

In my eyes, it is important to make a very clear distinction between
what is free and what is not free, even If it means some inconvenience.
It would be nice to be able to say with more confidence,  "If you get it
from debian main, you can be assured it is free.  Debian worries about
the licenses, so you don't have to."

If we make users have to decide between the "100% free installer" and
the "installer with non-free", and it makes the user have to think about
"what is this non-free stuff, and why should I care".  I think it is an
added side benefit.  If a user at some point decides to "vote with their
pocketbook", by choosing a piece of hardware based on its compatibility
with debian, I think that could also be a benefit.

> 
> I don't understand the clout around the fight for removing the little
> bits of non-free firmware for the network cards, while practically no
> one is able to run his/her computer without much more non-free code
> hidden in all the other places.

Because if its software, and its not free software, it just doens't
belong in debian.  Read the last paragraph of the social contract:

"We acknowledge that some of our users require the use of works
that do not conform to the Debian Free Software Guidelines. We have
created "contrib" and "non-free" areas in our archive for these works"

We can still acknowlege that some our users require the use of non-free
software during the install process, without having to keep main
contaminated.  

A line has to be drawn somewhere.  If we don't fight for the line, I
worry about it becoming a slippery slope that starts with firmware, then
starts to include all kinds of binary blobs like the non-free nvidia
drivers, then who knows what, a non-free userspace Then stuff like
ipw3945d, then at some point the discussion we are having is "why not
include rar, since we already have all of this other non-free stuff.

The arguments about "we are losing users to [other distro] becuase of
this"  Hold very little weight.  "Be a popular distro" is not a goal of
debian, "Be a free distro" is.  "Let's include non-free software because
everyone else is" is a counter-argument to me.  If we are the only ones
left that cares so much, all the more reason to stick to our principles.

stew


signature.asc
Description: Digital signature

Re: Re: I hereby resign as secretary

[Bdale Garbee]

> Now if only we could say positive things about people BEFORE they
> resign, wouldn't this be a better place?

+1E6

John, thank you for taking the time to write and post that note.  I couldn't 
agree more.

When Manoj and I joined the Debian project, there were only a couple dozen of 
us, and 
we indeed had a very different and more positive atmosphere.  That was a 
different time,
and in some senses a very different place.  It might therefore be easy to 
accept the idea 
that "things have changed" and that as a result we just have to live with the 
current 
situation.

I don't believe that.  Those of you who know me know that I've never believed 
that.  
There is a quote from Margaret Mead that I often include in the presentation 
materials
when I've giving public talks that I think deserves repeating here:

Never doubt that a small group of thoughtful, committed citizens can 
change the world; indeed, it's the only thing that ever has.

I've often used this quote to help explain why Free Software has been as 
successful
as it has been to date.  I think it also applies here.  Each of us, 
individually, must 
accept personal responsibility for the contribution we make to the overall 
Debian 
project atmosphere.  The only way we can "get things back on track" and 
re-focus our
energy on the real reason we are all here... to create a free operating 
system... is
to assume that each of us has the power to change things and make them better!

In hockey, there is a statistic kept about each player.  If they are on the ice 
when 
a goal is scored by their team, they get a plus one.  If they are on the ice 
when a 
goal is scored against their team, they get a minus one.  In this way, there is 
a 
rough measure of whether having that player on the ice was an overall benefit or
detriment to the team.  Players with a big positive number are highly valued, 
players
with a big negative number are likely to get traded or not have their contracts
renewed for another season.

We don't really have metrics as crisp as goals scored by and against us in the 
Debian
project.  But I believe that each of us has the responsibility to keep a 
personal
"plus/minus" tally in our heads about our own participation in the project.  If 
we
all do that, and all work hard to make sure our personal participation is a net 
benefit to the project, then I honestly believe we can and will achieve better 
results.

Bdale


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

Re: I hereby resign as secretary

[Daniel Jacobowitz]

On Thu, Dec 18, 2008 at 11:57:06PM -0600, John Goerzen wrote:
> Well, I haven't left, but I do far less with Debian now than I used
> to.
> 
> It is still my preferred OS for a variety of reasons.  I probably
> shouldn't write this tired at 11:30PM, but here goes.
> 
> I get no joy whatsoever out of the current mailing list discussions.
> It is sad to see people arguing so bitterly about pedantic matters in
> constitutions and guidlines and policy when that stuff is NOT why
> we're here.  We're here to make a Free operating system, dammit.
> People that are not here to make a Free operating system shouldn't be
> here.

[...]

> I have considered leaving the project several times this year.  The
> fun of being a Debian developer went away long ago.  I maintain
> packages for my own utility now, at home and at work, and that's it.

+1.  I'm dropping about a mailing list a year, which is a pretty slow
exit...

-- 
Daniel Jacobowitz
CodeSourcery


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

Re: First call for votes for the Lenny release GR

[Matthew Johnson]

On Fri Dec 19 14:24, Raphael Hertzog wrote:

> It is. Does the resolution say what the new version of the foundation
> document will look like if it's accepted ? If yes, then it supersedes the
> document. Otherwise it doesn't.

So, if someone proposes a GR saying "we will ship the binary NVidia
drivers in main and make them the default so that people can use compiz"
but doesn't say they are overriding the DFSG or provide the wdiff for it
then that's fine and only needs 1:1 to pass?

Matt

-- 
Matthew Johnson


signature.asc
Description: Digital signature

Re: First call for votes for the Lenny release GR

[Patrick Schoenfeld]

On Fri, Dec 19, 2008 at 02:32:51PM +0100, Raphael Hertzog wrote:
> > If that is the case, why would anyone propose changing a foundation
> > document, and risk failing to meet the 3:1 requirement, when they could
> > simply declare that they interpret it to say what they would like it to
> > say, and have a 1:1 vote?
> 
> Because they really want to change the goal/values of the project?

Ehh.. so what? If I dislike certain projects goals or values and I'd
like to enforce another meaning and I can reach this either with a
hard-to-reach 3:1 majority or with a temporary easy-to-reach
single-majority each time I need it, why should I bother going the hard
way?

> And please don't assume that a majority of developers are insane
> and want to pervert the project. If that is the case, we're all in
> a bad situation anyway. :-)

Nobody is talking about insanity. As the threads around those firmware
thing showed up different people have different opinions. The
goals/values might be *similar*, but obvious they are not identical.

> I'm convinced that a majority of developers would vote against any
> proposition that contradicts the social contract if there's no
> (good) rationale for the decision that justifies to temporary
> shift away from our goals.

Most likely, yes. But that is no hard fact, it is a anticipation.
Therefore consitutional laws exist, to control that in principle questions
this can be proofed.

Best Regards,
Patrick


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

Re: gr_lenny vs gr_socialcontract

[Johannes Wiedersich]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Manoj Srivastava wrote:
> I suspect it would not be hard to create a non-free installer CD
>  that obviates the requirement of a separate USB key for remote
>  installs.

If (almost?) everyone will use non-free stuff anyway, why not just make
live more easy for everyone and include it on all the installer images.
People still have the freedom to buy freely supported hardware or to not
use non-free firmware.

[snip]
> To paraphrase: Those who give up essential freedoms for
>  temporary convenience and popularity deserve neither.

I don't think that any computer will be more 'free' whether some
non-free code is loaded on boot from hard disk (kernel firmware blob) or
whether the non-free code is loaded from ROM like the BIOS. IMHO, it
also does not contribute in any way to freedom to force users to load
the firmware blobs from a separate installation medium. Or to drive them
into buying hardware with on board ROM chips for the then still non-free
firmware/software.

I don't understand the clout around the fight for removing the little
bits of non-free firmware for the network cards, while practically no
one is able to run his/her computer without much more non-free code
hidden in all the other places.

I really hope not to offend anyone with this opinion, it's just the less
than 2 cts worth of thought of a non-DD. ;-)

Cheers,

Johannes
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAklLpU4ACgkQC1NzPRl9qEX/BgCfToyPuyvQRfIVibKqZp/UzK2Z
45wAniq0UBSugB4yM5pqmWalwaqPZlbE
=u7YE
-END PGP SIGNATURE-


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

Re: First call for votes for the Lenny release GR

[Guilherme de S. Pastore]

On Thu, Dec 18, 2008 at 09:35:23PM -0800, Steve Langasek wrote:
> On Thu, Dec 18, 2008 at 08:15:25PM -0600, Guilherme de S. Pastore wrote:
> > Avoiding getting too technical about it, it is still illogical. You 
> > cannot produce the same effects of an amendment, even though 
> > temporarily, bypassing the requirements to an amendment. Creating an 
> > exception by means of General Resolution is equivalent to adding a 
> > little line to the document stating that "this does not apply to the 
> > Lenny release", except for the fact that we leave it in another official 
> > document for convenience reasons.
> 
> If the effect in question here is the release of lenny with sourceless
> firmware included in main, you certainly can get that effect without an
> amendment - precisely because under the constitution and in the absence of a
> GR to the contrary, interpretation and enforcement of the foundation
> documents devolves to the individual developers whose work it touches.

Then we get back to my other point, the Congress x Police Officer 
example. If there had been no General Resolution, that's fine, and the 
whole issue of interpreting and enforcing our foundation documents would 
be subject to the sole judgement of the Release Team. Great. Not saying 
they did - again, I am trying to touch the abstract considerations made 
here, not the Lenny release case concretely -, but assuming that the 
Release Team's decisions did go against the foundation documents, once 
you have our official decision-making body vouching for it (saying 
"forget that and release Lenny!"), it is no longer a matter of 
overruling a developer's call and externally enforcing what the Project 
deems to be the correct interpretation, but it reaches the level of 
institutionally *derogating* the document. We would not be refraining 
from stopping the release, we would be explicitly authorizing it.


> You (appear to) happen to agree with Manoj's understanding of the 
> implications of the DFSG for the lenny release.  That's fine; I'm not
> going to tell you that you're wrong to think that.  But that doesn't 
> make it ok for you, or the secretary, to impose this interpretation on 
> the project except *by way of* the GR process.

Now *you* are saying that the Secretary needs to run a GR as a 
pre-condition to do his job. :)

Regardless of the implications of whichever foundation document for the 
upcoming release or whomever I may agree with, I am rather concerned of
how Debian deals with this kind of problem and will deal with it in the
future. That's why I'm trying to shed some light on hermeneutics here.

--
Guilherme de S. Pastore
gpast...@debian.org


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

Re: First call for votes for the Lenny release GR

[Raphael Hertzog]

On Fri, 19 Dec 2008, Ian Lynagh wrote:
> On Fri, Dec 19, 2008 at 09:28:27AM +0100, Raphael Hertzog wrote:
> > 
> > Superseding a document is easily recognizable: it's when you explicitely
> > say that you're going to change its _content_ (ex:
> > http://www.debian.org/vote/2004/vote_003 ). Any time that this is not the
> > case, you should assume that we're not changing our common goal but that
> > we're discussing the interpretation that we make of it
> 
> If that is the case, why would anyone propose changing a foundation
> document, and risk failing to meet the 3:1 requirement, when they could
> simply declare that they interpret it to say what they would like it to
> say, and have a 1:1 vote?

Because they really want to change the goal/values of the project?

And please don't assume that a majority of developers are insane
and want to pervert the project. If that is the case, we're all in
a bad situation anyway. :-)

I'm convinced that a majority of developers would vote against any
proposition that contradicts the social contract if there's no
(good) rationale for the decision that justifies to temporary
shift away from our goals.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


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

poisoned atmosphere (Re: I hereby resign as secretary)

[Holger Levsen]

Hi John,

very well said, thanks. I suggest everyone to go back and read his mail.

http://www.jonobacon.org/?p=1483 is also a nice read about what working 
together nicely can achieve. I miss that in Debian. 

I have now decided to unsubscribe from -vote and -devel, the gain/pain ratio 
has become totally unacceptable for me. I guess -project will follow soon.


cheers,
Holger


signature.asc
Description: This is a digitally signed message part.

Re: First call for votes for the Lenny release GR

[Raphael Hertzog]

On Fri, 19 Dec 2008, Patrick Schoenfeld wrote:
> On Fri, Dec 19, 2008 at 09:28:27AM +0100, Raphael Hertzog wrote:
> > No. The constitution doesn't say that the secretary's job is to interpret
> > the DFSG and decide if the 3:1 majority requirement applies. And the job
> > of the secretary (contrary to the job of most delegates and debian
> > packagers) is expressly defined by the constitution.
> 
> Its not neccessary to interpret the DFSG in order to set majority
> requirements.

I agree with this. But Manoj doesn't.

> 
> > The constitution says: 
> > “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.“
> > 
> > Superseding a document is easily recognizable: it's when you explicitely
> > say that you're going to change its _content_ (ex:
> > http://www.debian.org/vote/2004/vote_003 ).
> 
> I wouldn't say that it is that easy. 

It is. Does the resolution say what the new version of the foundation
document will look like if it's accepted ? If yes, then it supersedes the
document. Otherwise it doesn't.

> We do not have rules for temporary overriding a foundation document, therefore
> we need to apply one of the rules we have. 

I'm sorry, you don't have to pick one of the existing rules and stretch it
to cover some unexpected case. The default rule for position statement
applies and it's a GR with a 1:1 ratio.

> abrogating it and yes its permanent. But if you abrogate it temporary
> the effect is still the same.

No. In one case, we alter our (long-term) goal, in the other we don't.

Anthony Towns is right. Some people take the social contract as a law.
Other take it as a goal. We probably need to clear up this. But even if
we consider it as law, the social contract is written in such a way that
there's room for interpretation, whereas the constitution is much more
precise in all our rules.

> > Any time that this is not the
> > case, you should assume that we're not changing our common goal but that
> > we're discussing the interpretation that we make of it or that we're
> > discussing the compromise that we can currently accept in order to
> > reach our common objective (as defined by the foundation document).
> 
> No, thats a inherently wrong way to work with a constitution. Somebody

I was not speaking of the constitution but of the “Foundation documents”.

Quoting the constitution:
“The Foundation Documents are the works entitled "Debian Social Contract"
and "Debian Free Software Guidelines".”

The constitution is not a foundation document although it is subject to
the same rules for its modification.

> > And this is a prerogative of the project: we as a whole (as defined by a
> > simple majority), should be able do make decisions on how Debian will
> > achieve its goals without fearing to be blocked by the interpretation of
> > one of its member (be it the secretary).
> 
> That is right, but consider your wording: You say that we as a *whole* should
> be able to make decisions on how Debian will achieve its goals and thats 
> exactly
> why there are majority requirements. A whole project wouldn't have a problem
> fitting the 3:1 majority if it were the decision of the whole project. This
> argumentation therefore is kind of odd. Saying its one person who does block 
> it
> is not fair either. Manoj did not say "Our consitution does not allow to vote,
> my opinion is binding according to our consitution" so your wording is a bad
> allegation.

I'm at a loss… I don't know how I can better explain the problem. I'll thy
nevertheless:

If you consider that we all agree on the goals (and for me this is a
given, we all agreed to the social contract), imposing a 3:1 ratio
on any vote that should decide how we will handle the next step (that
should bring us closer to our goals) is an effective way to block
any progress: we've seen at numerous occasions that consensus is
almost unachievable and that we need fair decision-making process.

Imposing consensus is okay when it comes to changing/altering our
objectives. But it's not okay when it comes to decisions on how we want to
reach our objectives. 

I hope this clears it up.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


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

Re: First call for votes for the Lenny release GR

[Ian Lynagh]

On Fri, Dec 19, 2008 at 09:28:27AM +0100, Raphael Hertzog wrote:
> 
> Superseding a document is easily recognizable: it's when you explicitely
> say that you're going to change its _content_ (ex:
> http://www.debian.org/vote/2004/vote_003 ). Any time that this is not the
> case, you should assume that we're not changing our common goal but that
> we're discussing the interpretation that we make of it

If that is the case, why would anyone propose changing a foundation
document, and risk failing to meet the 3:1 requirement, when they could
simply declare that they interpret it to say what they would like it to
say, and have a 1:1 vote?


Thanks
Ian


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

Re: gr_lenny vs gr_socialcontract

[Anthony Towns]

On Fri, Dec 19, 2008 at 08:12:28AM +0100, Marc Haber wrote:
> Putting an USB key into most of my servers requires some hours of
> driving and jumping through security hoops to get datacenter access.
> [...]
> I'd prefer an OS which allows full remote installation that does not
> need some kind of physical access.

On Fri, Dec 19, 2008 at 01:50:40AM -0600, Manoj Srivastava wrote:
> I suspect it would not be hard to create a non-free installer CD
>  that obviates the requirement of a separate USB key for remote
>  installs.

So isn't this exactly why we have a voting system? Everyone understands
both points of view here, don't they? We just need to choose which one
Debian's going to adopt, because we haven't implemented a way of having
our cake and eating it too on this score.

> I tend to come down hard on the side of not compromising my
>  principles for temporary convenience or popularity (or, if you will,
>  market share).
> 
> To paraphrase: Those who give up essential freedoms for
>  temporary convenience and popularity deserve neither.

And, uh, isn't that a bit needlessly argumentative? Marc's not trying to
get anyone to give up essential freedoms, or give them up himself.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Results for Project membership procedures

[Anthony Towns]

On Mon, Dec 15, 2008 at 11:54:30PM +, Matthew Johnson wrote:
> On Tue Dec 16 06:55, Anthony Towns wrote:
> > Of the various people involved in the topic, many voted in ways you
> > (or at least I) mightn't expect.
> > ...
> >   Matthew Johnson - voted for implementation
> I'm not too surprised by this. 

I'd hope you wouldn't be surprised by how you voted... :)

> I think it's entirely logically
> consistent to second something then vote against it. Seconding an option
> (particularly an amendment) just means "I think this should be voted on"
> not "I'm going to vote for it". 

That's what it means to the person doing it, and to people who follow
-vote.  When you haven't followed -vote, and are trying to grok some
options based on the vote.d.o page and the post to d-d-a, you tend to
go by who proposed/seconded the proposals. When the RMs names appear,
eg, that tends to add weight to a proposal, as does having seconds from
a bunch of people you know of and don't think are daft.

Fortunately it's still a somewhat accurate measure, so it doesn't tend to
completely misinform DDs who don't follow -vote, #debian-devel, etc and
have to use that sort of heuristic to be even moderately informed, but it
seems useful to keep track of just how far off heuristics like that are.

There are probably ways to improve the vote.d.o page so that people less
engrossed in the process can be better informed, but until that happens,
we've got what we've got...

Cheers,
aj



signature.asc
Description: Digital signature

Re: gr_lenny vs gr_socialcontract

[Marc Haber]

On Fri, Dec 19, 2008 at 01:50:40AM -0600, Manoj Srivastava wrote:
> Let us face it: there are always going to be bits of hardware
>  that can not be supported with free software; users might always have
>  to deal with either refraining from buying such hardware (which is not
>  always feasible), using a non-free installer,  going a more
>  inconvenient route, or using a different OS. As always, Debian is nto
>  for everyone, and our commitment to the freedom, and just not being
>  windows, means there are going to be people who can not use Debian.
> 
> I tend to come down hard on the side of not compromising my
>  principles for temporary convenience or popularity (or, if you will,
>  market share).
> 
> To paraphrase: Those who give up essential freedoms for
>  temporary convenience and popularity deserve neither.

This is something we need to agree to disagree on. There are people
who still focus on "The Universal Operating System", and who are
willing to make compromises in freedom without being willing to make a
totally non-free OS.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 3221 2323190


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

Re: First call for votes for the Lenny release GR

[Patrick Schoenfeld]

Hi,

On Fri, Dec 19, 2008 at 09:28:27AM +0100, Raphael Hertzog wrote:
> No. The constitution doesn't say that the secretary's job is to interpret
> the DFSG and decide if the 3:1 majority requirement applies. And the job
> of the secretary (contrary to the job of most delegates and debian
> packagers) is expressly defined by the constitution.

Its not neccessary to interpret the DFSG in order to set majority
requirements.

> The constitution says: 
> “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.“
> 
> Superseding a document is easily recognizable: it's when you explicitely
> say that you're going to change its _content_ (ex:
> http://www.debian.org/vote/2004/vote_003 ).

I wouldn't say that it is that easy. We do not have rules for temporary
overriding a foundation document, therefore we need to apply one of the
rules we have. Its not so easy as you make it: "Its no supersession, lets
just apply what is on our mood". In fact superseding a document means
abrogating it and yes its permanent. But if you abrogate it temporary
the effect is still the same.

> Any time that this is not the
> case, you should assume that we're not changing our common goal but that
> we're discussing the interpretation that we make of it or that we're
> discussing the compromise that we can currently accept in order to
> reach our common objective (as defined by the foundation document).

No, thats a inherently wrong way to work with a constitution. Somebody
earlier in one of the related threads brought a good example. He
compared the consitution of Debian with the consititution of a state.
The important thing about a constitution is that one has to be careful
with it. Its not a law that you change or interpret like you want if you
see fit. Its something you must interpret as carefully and conservative
as possible, so you don't break the basis of a society (e.g. human
rights). Now our consitution does not protect human rights, but still
they name consitution has been used, while we could have namd it.. hmm..
"Manifesto" or somewhat like that. That is, because people wanted to
have this document a special meaning. We should really act like that.

> And this is a prerogative of the project: we as a whole (as defined by a
> simple majority), should be able do make decisions on how Debian will
> achieve its goals without fearing to be blocked by the interpretation of
> one of its member (be it the secretary).

That is right, but consider your wording: You say that we as a *whole* should
be able to make decisions on how Debian will achieve its goals and thats exactly
why there are majority requirements. A whole project wouldn't have a problem
fitting the 3:1 majority if it were the decision of the whole project. This
argumentation therefore is kind of odd. Saying its one person who does block it
is not fair either. Manoj did not say "Our consitution does not allow to vote,
my opinion is binding according to our consitution" so your wording is a bad
allegation.

Regards,
Patrick


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

Re: First call for votes for the Lenny release GR

[Raphael Hertzog]

On Fri, 19 Dec 2008, Manoj Srivastava wrote:
> This, then, should also apply for the developer who is serving
>  as the secretary. Or you shpould amend your statement here, to say that
>  all developers, with the exception of the secretary, interpret the DFSG
>  in performing their duties.

No. The constitution doesn't say that the secretary's job is to interpret
the DFSG and decide if the 3:1 majority requirement applies. And the job
of the secretary (contrary to the job of most delegates and debian
packagers) is expressly defined by the constitution.

The constitution says: 
“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.“

Superseding a document is easily recognizable: it's when you explicitely
say that you're going to change its _content_ (ex:
http://www.debian.org/vote/2004/vote_003 ). Any time that this is not the
case, you should assume that we're not changing our common goal but that
we're discussing the interpretation that we make of it or that we're
discussing the compromise that we can currently accept in order to
reach our common objective (as defined by the foundation document).

And this is a prerogative of the project: we as a whole (as defined by a
simple majority), should be able do make decisions on how Debian will
achieve its goals without fearing to be blocked by the interpretation of
one of its member (be it the secretary).

And I know that it's the job of the secretary to rule dispute about
interpretation of the constitution but the constitution also says:
“The Project Secretary should make decisions which are fair and
reasonable, and preferably consistent with the consensus of the
Developers.“

And I believe that your interpretation doesn't fit the above rule.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


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

Re: I hereby resign as secretary

[Michael Casadevall]

The problem is you can't wave a magic wand, and fix the community.
It's a self-feeding cycle which goes on and on and on. Even if we had
a Code of Conduct for Debian, unless it was strongly enforced, its the
same problem.

Whether the ballot was valid or not was immaterial, the response to it
was clearly inappropriate. If we flamed people to hell and called for
their removal for every mistake, we won't have a single developer or
user left. Maybe its worth considering adopting a CoC for Debian, and
actually enforcing it, but that's someone for the community to decide,
should we ever get past flaming each other to get something done.
Michael

On Fri, Dec 19, 2008 at 3:18 AM, Lionel Elie Mamane  wrote:
> On Thu, Dec 18, 2008 at 11:57:06PM -0600, John Goerzen wrote:
>
>> Well, I haven't left, but I do far less with Debian now than I used
>> to.
>
>> It is still my preferred OS for a variety of reasons. (...)
>
>> I get no joy whatsoever out of the current mailing list
>> discussions. (...) We're here to make a Free operating system, dammit.
>> People that are not here to make a Free operating system shouldn't be
>> here.
>
>> I have considered leaving the project several times this year.  The
>> fun of being a Debian developer went away long ago.  I maintain
>> packages for my own utility now, at home and at work, and that's it.
>
> I do recognise in me the same symptoms as those you describe. I
> haven't really analysed much to have an opinion on whether I ascribe
> them to the same causes as you or not.
>
> Several of my DD friends have solved the problem by unsubscribing from
> d-de...@l.d.o, d-v...@l.d.o, etc.
>
> --
> Lionel
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
>
>


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

Re: I hereby resign as secretary

[Lionel Elie Mamane]

On Thu, Dec 18, 2008 at 11:57:06PM -0600, John Goerzen wrote:

> Well, I haven't left, but I do far less with Debian now than I used
> to.

> It is still my preferred OS for a variety of reasons. (...)

> I get no joy whatsoever out of the current mailing list
> discussions. (...) We're here to make a Free operating system, dammit.
> People that are not here to make a Free operating system shouldn't be
> here.

> I have considered leaving the project several times this year.  The
> fun of being a Debian developer went away long ago.  I maintain
> packages for my own utility now, at home and at work, and that's it.

I do recognise in me the same symptoms as those you describe. I
haven't really analysed much to have an opinion on whether I ascribe
them to the same causes as you or not.

Several of my DD friends have solved the problem by unsubscribing from
d-de...@l.d.o, d-v...@l.d.o, etc.

-- 
Lionel


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

Re: gr_lenny vs gr_socialcontract

[Manoj Srivastava]

On Fri, Dec 19 2008, Marc Haber wrote:

> On Fri, Dec 19, 2008 at 12:09:55AM -0600, Manoj Srivastava wrote:
>> For what it is worth, at work we had to install Lenny on
>>  machines which have the broadcom netextreme 2 ethernet cards (bnx2
>>  firmware needed). The netinst installer worked wonderfully, grabbing
>>  the firmware from a usb key loaded with non-free firmware.
>
> Putting an USB key into most of my servers requires some hours of
> driving and jumping through security hoops to get datacenter access.
> In some cases, it may be possible to mail the USB key and to pay
> outrageous fees for remote hands.
>
> I'd prefer an OS which allows full remote installation that does not
> need some kind of physical access.

I suspect it would not be hard to create a non-free installer CD
 that obviates the requirement of a separate USB key for remote
 installs.

Let us face it: there are always going to be bits of hardware
 that can not be supported with free software; users might always have
 to deal with either refraining from buying such hardware (which is not
 always feasible), using a non-free installer,  going a more
 inconvenient route, or using a different OS. As always, Debian is nto
 for everyone, and our commitment to the freedom, and just not being
 windows, means there are going to be people who can not use Debian.

I tend to come down hard on the side of not compromising my
 principles for temporary convenience or popularity (or, if you will,
 market share).

To paraphrase: Those who give up essential freedoms for
 temporary convenience and popularity deserve neither.

manoj
-- 
"The highest form of pure thought is in mathematics." Plato
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