What does FD Mean (was: Re: Call for votes on «Statement regarding Richard Stallman's readmission to the FSF board»)

[Mathias Behrle]

* Russ Allbery: " Re: Call for votes on «Statement regarding Richard Stallman's
  readmission to the FSF board»" (Fri, 02 Apr 2021 16:49:21 -0700):

> Mathias Behrle  writes:
> 
> > I consider the really great value of current option E that I can indeed
> > vote explicitely that nothing should be done on behalf of the project
> > and that further discussion is *not* needed.
> 
> I consider the naming of "further discussion" a wry joke on the fact that
> the above outcome is, uh, unlikely.  Good luck getting everyone in Debian
> to stop discussing something.

I am aware of the fact htat I won't stop discussions, but at least I do not
want to be forced to say 'further discussion' if I just want the contrary.
 
> I have no real objections to renaming "further discussion" to "none of the
> above"; I just doubt it would accomplish anything and therefore am not
> sure it's worth the effort.

I would be glad if we would put more precise options on the ballot as I put it
in my answer to Sam. Using 'None of the above' instead of 'FD' would be at
least a first step into that direction.

> And personally, not that anyone should make any decisions on this basis, I'm
> kind of fond of the self-aware joke. It's good for us as a project to poke
> fun at our own weaknesses, since it helps us keep them in mind.

Yes, but joke aside it gives me really a hard time to say FD if I want exactly
the contrary.




-- 

Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BBF6

Re: Call for votes on «Statement regarding Richard Stallman's readmission to the FSF board»

[Russ Allbery]

Mathias Behrle  writes:

> I consider the really great value of current option E that I can indeed
> vote explicitely that nothing should be done on behalf of the project
> and that further discussion is *not* needed.

I consider the naming of "further discussion" a wry joke on the fact that
the above outcome is, uh, unlikely.  Good luck getting everyone in Debian
to stop discussing something.

I have no real objections to renaming "further discussion" to "none of the
above"; I just doubt it would accomplish anything and therefore am not
sure it's worth the effort.  And personally, not that anyone should make
any decisions on this basis, I'm kind of fond of the self-aware joke.
It's good for us as a project to poke fun at our own weaknesses, since it
helps us keep them in mind.

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

Re: Call for votes on «Statement regarding Richard Stallman's readmission to the FSF board»

[Mathias Behrle]

* Gunnar Wolf: " Re: Call for votes on «Statement regarding Richard Stallman's
  readmission to the FSF board»" (Fri, 2 Apr 2021 12:57:09 -0600):


Thank you Gunnar for pushing this forward.

> Nicolas Dandrimont dijo [Fri, Apr 02, 2021 at 06:27:48PM +0200]:
> > > (...)
> > > [A] Call for the FSF board removal, as in rms-open-letter.github.io
> > > (proposed by Steve Langasek, currently base proposal)
> > > 
> > > [B] Call for Stallman's resignation from FSF all bodies
> > > (proposed by Sruthi Chandran, currently proposal B)
> > > 
> > > [C] Discurage collaboration with the FSF while Stallman is in a leading
> > > position (proposed by Santiago Ruano Rincón, currently proposal C)
> > > 
> > > [D] Call on the FSF to further its governance processes
> > > (proposed by Jonathan Wiltshire, currently proposal D)
> > > 
> > > [E] Debian will not issue a public statement on this issue
> > > (proposed by Timo Weingärtner, currently proposal E)
> > > 
> > > [F] Support Stallman's reinstatement, as in rms-support-letter.github.io
> > > (proposed by Timo Weingärtner, currently proposal A)
> > > (...)  
> > 
> > I would suggest moving proposal E to the top or to the bottom of the
> > ballot, as one can argue that this "status quo" option doesn't
> > really fit within the "condemn → support" axis you've proposed. I
> > think I agree with how the other options are ordered.  
> 
> Makes sense. OTOH, we usually take FD as "preserve status quo"; FD
> usually appears (and should appear this time as well, sorry for not
> capturing it in my ballot proposal) as the last option.

I don't get that. Is this really common sense that FD means/meant "preserve
status quo"? For me voting this option definitely should mean that further
discussion on the topic is needed.

> I understand, option E is not semantically identical to FD, but is
> equivalent in the way that it means "do nothing project-wide, either
> for or against".

I consider the really great value of current option E that I can indeed
vote explicitely that nothing should be done on behalf of the project and that
further discussion is *not* needed.

I agree that option E as the counterpart to all other options should be first
or last, and my personal preference would be first.



-- 

Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BBF6

Re: Call for votes on «Statement regarding Richard Stallman's readmission to the FSF board»

[Kurt Roeckx]

On Fri, Apr 02, 2021 at 09:53:30AM -0600, Gunnar Wolf wrote:
> Kurt Roeckx dijo [Fri, Apr 02, 2021 at 09:29:06AM +0200]:
> > On Fri, Apr 02, 2021 at 01:06:49AM -0600, Gunnar Wolf wrote:
> > > Dear Debian Project Secretary,
> > > 
> > > Given the DPL authorized a shortened discussion period, and that, while
> > > said discussion period allowed for a wide range of voting choices to
> > > be accepted in the ballots, the tone of the discussion is highly
> > > confrontational and I judge we will not gain any further insights or
> > > wordings merely by giving it more time.
> > > 
> > > So, by following the Debian constitution (A.2), as a sponsor for one
> > > of the amendments, I call for a vote, and ask you to draft the
> > > corresponding ballot.
> > 
> > Please suggest names and maybe an order of the options.
> 
> Better done with the morning coffee than late at night :-)
> 
> I suggest the following options and ordering to appear on the ballot:
> 
> [A] Call for the FSF board removal, as in rms-open-letter.github.io
> (proposed by Steve Langasek, currently base proposal)
> 
> [B] Call for Stallman's resignation from FSF all bodies
> (proposed by Sruthi Chandran, currently proposal B)
> 
> [C] Discurage collaboration with the FSF while Stallman is in a leading 
> position
> (proposed by Santiago Ruano Rincón, currently proposal C)
> 
> [D] Call on the FSF to further its governance processes
> (proposed by Jonathan Wiltshire, currently proposal D)
> 
> [E] Debian will not issue a public statement on this issue
> (proposed by Timo Weingärtner, currently proposal E)
> 
> [F] Support Stallman's reinstatement, as in rms-support-letter.github.io
> (proposed by Timo Weingärtner, currently proposal A)

I've committed this to the webpage. The ballot will probably look
like:
[   ] Choice 1: Call for the FSF board removal, as in rms-open-letter.github.io
[   ] Choice 2: Call for Stallman's resignation from all FSF bodies
[   ] Choice 3: Discourage collaboration with the FSF while Stallman is in a 
leading position
[   ] Choice 4: Call on the FSF to further its governance processes
[   ] Choice 5: Support Stallman's reinstatement, as in 
rms-support-letter.github.io
[   ] Choice 6: Debian will not issue a public statement on this issue
[   ] Choice 7: Further Discussion


Kurt

Re: Call for votes on «Statement regarding Richard Stallman's readmission to the FSF board»

[Gunnar Wolf]

Nicolas Dandrimont dijo [Fri, Apr 02, 2021 at 06:27:48PM +0200]:
> > (...)
> > [A] Call for the FSF board removal, as in rms-open-letter.github.io
> > (proposed by Steve Langasek, currently base proposal)
> > 
> > [B] Call for Stallman's resignation from FSF all bodies
> > (proposed by Sruthi Chandran, currently proposal B)
> > 
> > [C] Discurage collaboration with the FSF while Stallman is in a leading 
> > position
> > (proposed by Santiago Ruano Rincón, currently proposal C)
> > 
> > [D] Call on the FSF to further its governance processes
> > (proposed by Jonathan Wiltshire, currently proposal D)
> > 
> > [E] Debian will not issue a public statement on this issue
> > (proposed by Timo Weingärtner, currently proposal E)
> > 
> > [F] Support Stallman's reinstatement, as in rms-support-letter.github.io
> > (proposed by Timo Weingärtner, currently proposal A)
> > (...)
> 
> I would suggest moving proposal E to the top or to the bottom of the
> ballot, as one can argue that this "status quo" option doesn't
> really fit within the "condemn → support" axis you've proposed. I
> think I agree with how the other options are ordered.

Makes sense. OTOH, we usually take FD as "preserve status quo"; FD
usually appears (and should appear this time as well, sorry for not
capturing it in my ballot proposal) as the last option.

I understand, option E is not semantically identical to FD, but is
equivalent in the way that it means "do nothing project-wide, either
for or against".

Re: Call for votes on «Statement regarding Richard Stallman's readmission to the FSF board»

[Nicolas Dandrimont]

On Fri, Apr 2, 2021, at 17:53, Gunnar Wolf wrote:
> Better done with the morning coffee than late at night :-)
> 
> I suggest the following options and ordering to appear on the ballot:
> 
> [A] Call for the FSF board removal, as in rms-open-letter.github.io
> (proposed by Steve Langasek, currently base proposal)
> 
> [B] Call for Stallman's resignation from FSF all bodies
> (proposed by Sruthi Chandran, currently proposal B)
> 
> [C] Discurage collaboration with the FSF while Stallman is in a leading 
> position
> (proposed by Santiago Ruano Rincón, currently proposal C)
> 
> [D] Call on the FSF to further its governance processes
> (proposed by Jonathan Wiltshire, currently proposal D)
> 
> [E] Debian will not issue a public statement on this issue
> (proposed by Timo Weingärtner, currently proposal E)
> 
> [F] Support Stallman's reinstatement, as in rms-support-letter.github.io
> (proposed by Timo Weingärtner, currently proposal A)
> 
> My reasoning for this suggested ordering is to present the options
> ordered, from most strongly against to most strongly in support of
> Stallman. They could also be presented in the inverse order, if it
> seems that proposed options [E] and [F] are too underrepresented and
> left to the endto the end.

I would suggest moving proposal E to the top or to the bottom of the ballot, as 
one can argue that this "status quo" option doesn't really fit within the 
"condemn → support" axis you've proposed. I think I agree with how the other 
options are ordered.

Thanks,
-- 
Nicolas Dandrimont

Re: Call for votes on «Statement regarding Richard Stallman's readmission to the FSF board»

[Gunnar Wolf]

Kurt Roeckx dijo [Fri, Apr 02, 2021 at 09:29:06AM +0200]:
> On Fri, Apr 02, 2021 at 01:06:49AM -0600, Gunnar Wolf wrote:
> > Dear Debian Project Secretary,
> > 
> > Given the DPL authorized a shortened discussion period, and that, while
> > said discussion period allowed for a wide range of voting choices to
> > be accepted in the ballots, the tone of the discussion is highly
> > confrontational and I judge we will not gain any further insights or
> > wordings merely by giving it more time.
> > 
> > So, by following the Debian constitution (A.2), as a sponsor for one
> > of the amendments, I call for a vote, and ask you to draft the
> > corresponding ballot.
> 
> Please suggest names and maybe an order of the options.

Better done with the morning coffee than late at night :-)

I suggest the following options and ordering to appear on the ballot:

[A] Call for the FSF board removal, as in rms-open-letter.github.io
(proposed by Steve Langasek, currently base proposal)

[B] Call for Stallman's resignation from FSF all bodies
(proposed by Sruthi Chandran, currently proposal B)

[C] Discurage collaboration with the FSF while Stallman is in a leading position
(proposed by Santiago Ruano Rincón, currently proposal C)

[D] Call on the FSF to further its governance processes
(proposed by Jonathan Wiltshire, currently proposal D)

[E] Debian will not issue a public statement on this issue
(proposed by Timo Weingärtner, currently proposal E)

[F] Support Stallman's reinstatement, as in rms-support-letter.github.io
(proposed by Timo Weingärtner, currently proposal A)

My reasoning for this suggested ordering is to present the options
ordered, from most strongly against to most strongly in support of
Stallman. They could also be presented in the inverse order, if it
seems that proposed options [E] and [F] are too underrepresented and
left to the endto the end.


signature.asc
Description: PGP signature

Re: Call for votes on «Statement regarding Richard Stallman's readmission to the FSF board»

[Kurt Roeckx]

On Fri, Apr 02, 2021 at 01:06:49AM -0600, Gunnar Wolf wrote:
> Kurt Roeckx dijo [Fri, Apr 02, 2021 at 08:56:33AM +0200]:
> > There is also this in 4.2:
> > 4. The minimum discussion period is 2 weeks, but may be varied by up
> >to 1 week by the Project Leader. The Project Leader has a casting
> >vote. There is a quorum of 3Q.
> > 
> > The DPL changed the minimum time for the discussion period to 1 week.
> > The discussion period is over when a vote is called.
> 
> Dear Debian Project Secretary,
> 
> Given the DPL authorized a shortened discussion period, and that, while
> said discussion period allowed for a wide range of voting choices to
> be accepted in the ballots, the tone of the discussion is highly
> confrontational and I judge we will not gain any further insights or
> wordings merely by giving it more time.
> 
> So, by following the Debian constitution (A.2), as a sponsor for one
> of the amendments, I call for a vote, and ask you to draft the
> corresponding ballot.

Please suggest names and maybe an order of the options.



Kurt

Re: Call for Votes on the Initit Systems GR

[Kurt Roeckx]

On Tue, Dec 03, 2019 at 10:09:26AM -0500, Sam Hartman wrote:
> 
> The minimum discussion period lapsed sometime Saturday.
> So, as one of the authors of a proposal, I ask the secretary to please
> prepare a ballot and start the vote.
> As the DPL, I ask the secretary to extend the voting period by a week.

So I will most likely start the vote the 7th at 0 UTC, making the
end time the 27th at 23:59:59 UTC.

I will try to make the ballot tomorrow.


Kurt

Re: Call for Votes on the Initit Systems GR

[Micha Lenk]

Hi all,

just because there are some voices complaining about Sam's call for vote, I 
feel the need to raise my otherwise more silent voice. All in all I concur with 
Sam's assessment that all options are covered well enough to form opinions. Now 
let's vote and see where we are today. And it's not like we can't evolve in the 
future from where we are today.

Regards,
Micha

Re: Call for Votes on the Initit Systems GR

[Wouter Verhelst]

Hi Sam,

On Tue, Dec 03, 2019 at 10:09:26AM -0500, Sam Hartman wrote:
> 
> The minimum discussion period lapsed sometime Saturday.
> So, as one of the authors of a proposal, I ask the secretary to please
> prepare a ballot and start the vote.
> As the DPL, I ask the secretary to extend the voting period by a week.

This is the first time in the history of the project[1] that a call for
vote is done *while people are still actively drafting options*. Usually
we wait for discussion to die out before we call for votes.

Even if that isn't the process set out in the constitution, it feels
very disingenious and dishonest to not allow people to finalize their
options. It is a break with precedent, and one that I think is not
necessary.

The sky isn't going to fall, and the world isn't going to end, if we
postpone this a bit more. Even if you don't want this to be voted on
over the holidays, you can still postpone it so that the vote happens
*after* the holidays.

Please don't make a bad situation worse.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: Call for Votes on the Initit Systems GR

[Matthew Vernon]

Sam Hartman  writes:

> The minimum discussion period lapsed sometime Saturday.
> So, as one of the authors of a proposal, I ask the secretary to please
> prepare a ballot and start the vote.

I think this is an error, and urge you to reconsider; there is clearly
an active process to try and refine one of the options on the ballot
paper. The vote call could wait 'til the weekend and still achieve the
objective of giving people time to vote before the holiday period
arrives. 

> I appreciate that Ian wishes to have an opportunity to explore other
> things based on option G.
> In other circumstances, I might have had a hard decision about whether
> to wait longer to let that discussion progress.
>
> Today, though, Ian's message is contributing to the souring tone of the
> discussion.

In particular, you give the very unfortunate impression that calling the
CFV now while Ian and Guillem are still refining the proposal Guillem
wrote is being done to in effect punish Ian for his use of language.

Please, please reconsider: this is an important vote on a complex and
challenging issue that many people in Debian feel strongly about - it's
vital that we get as good a set of options on the ballot as possible. I
know there is a concern about letting people vote before Christmas, but
that aim is still coherent with letting the option drafting finish.

Regards,

Matthew

-- 
"At least you know where you are with Microsoft."
"True. I just wish I'd brought a paddle."
http://www.debian.org

Re: Call for Votes on the Initit Systems GR

[Sam Hartman]

It was pointed out to me off-list that the constitution  says that in
calling for a vote I am supposed to say what I think the options are.
That feels kind of presumptuous given the work the secretary has done.
Kurt and I discussed off list much earlier and he doesn't need me to say
what I think the ballot options are.
But for the avoidance of doubt,
As of the time of this message, I believe that Proposals  F, B, A, D, E,
and G from
https://www.debian.org/vote/2019/vote_002

represent what we've discussed as a ballot.
I did not re-read each proposal today, but I did read them Sunday.

--Sam


signature.asc
Description: PGP signature

Re: Call for votes: Repeal the 2005 vote for declassification of the debian-private mailing list

[Kurt Roeckx]

On Tue, Oct 04, 2016 at 11:11:32PM -0500, Gunnar Wolf wrote:
> [ Amazing as it might seem for this issue, I forgot to sign my
>   mail. Here it is again. Apologies for the duplication ]
> 
> Debian Project Secretary,
> 
> It has been two weeks since I posted my GR proposal [1] to the
> debian-vote mailing list, containing the text that follows:

I'm going to start the vote on Saturday the 8th.

I'll try to get the vote page updated this evening, but I'm rather
busy.


Kurt

Re: Call for votes: Declassifying parts of -private of historical interest

[Kurt Roeckx]

On Tue, Aug 02, 2016 at 12:18:04PM +0200, Nicolas Dandrimont wrote:
> 
> Dear Secretary,
> 
> It has been two weeks since I accepted this amendment. I would like to call 
> for
> votes on this General Resolution.

I'll let the vote start on 2016-08-07 00:00 UTC.


Kurt

Re: Call for Votes: General Resolution: Init system coupling

[Neil McGovern]

On Tue, Nov 04, 2014 at 05:53:36PM +, Neil McGovern wrote:
 - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
 57dd4d7c-3e92-428f-8ab7-10de5172589e
 [   ] Choice 1: Packages may not (in general) require a specific init system
 [   ] Choice 2: Support alternative init systems as much as possible
 [   ] Choice 3: Packages may require specific init systems if maintainers 
 decide
 [   ] Choice 4: General Resolution is not required
 [   ] Choice 5: Further Discussion
 - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-

All,

For avoidance of doubt, and as I've been asked on IRC, all options have
a 1:1 majority requirement.

Neil
-- 


signature.asc
Description: Digital signature

Re: Call for Votes: General Resolution: Init system coupling

[Lucas Nussbaum]

Hi Neil,

On 04/11/14 at 17:53 +, Neil McGovern wrote:
 - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
 57dd4d7c-3e92-428f-8ab7-10de5172589e
 [   ] Choice 1: Packages may not (in general) require a specific init system
 [   ] Choice 2: Support alternative init systems as much as possible
 [   ] Choice 3: Packages may require specific init systems if maintainers 
 decide
 [   ] Choice 4: General Resolution is not required
 [   ] Choice 5: Further Discussion
 - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-

I must say that I am quite surprised by you choice of summary for Choice 2.

First, that's the only one not to include a verb. It could be understood
as Packages *must* support alternative init systems as much as
possible, which is clearly misleading. Also as much as possible is
not part of the amendment.

Second, after asking for an accurate summary, I replied in
20141017202805.ga10...@xanadu.blop.info (private mail to you+Ian, as
was your initial query) with: support for alternative init systems is
desirable but not mandatory. If you disagreed with the suggestion, why
didn't you say so since Oct 17th?

If my suggestion is too long, you could have used any of the following,
which are all shorter or the same size as the summary for Choice 3:
- Support for alternative init systems is desirable, not mandatory
- Maintainers are encouraged to support alternative init systems

I think that it would be better to update the CfV.

Also, it's a much more minor problem, but it seems that you missed my
second for the fourth proposal in 20141022054027.ga30...@xanadu.blop.info.

Lucas


signature.asc
Description: Digital signature

Re: Call for Votes: General Resolution: Init system coupling

[Ian Jackson]

Lucas Nussbaum writes (Re: Call for Votes: General Resolution: Init system 
coupling):
 Second, after asking for an accurate summary, I replied in
 20141017202805.ga10...@xanadu.blop.info (private mail to you+Ian, as
 was your initial query) with: support for alternative init systems is
 desirable but not mandatory. If you disagreed with the suggestion, why
 didn't you say so since Oct 17th?

I concur with Lucas's comments.

 If my suggestion is too long, you could have used any of the following,
 which are all shorter or the same size as the summary for Choice 3:
 - Support for alternative init systems is desirable, not mandatory
 - Maintainers are encouraged to support alternative init systems
 
 I think that it would be better to update the CfV.

I agree.

I think this is still possible.  It's a shame that this slightly odd
pre-CFV (CFV posted before voting period opens) wasn't explicitly a
draft, and posted only to -vote.

Sorry,
Ian.


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21593.9457.965325.538...@chiark.greenend.org.uk

Re: Call for Votes: General Resolution: Init system coupling

[Neil McGovern]

On Tue, Nov 04, 2014 at 07:54:46PM +0100, Lucas Nussbaum wrote:
 Hi Neil,
 
 On 04/11/14 at 17:53 +, Neil McGovern wrote:
  - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
  57dd4d7c-3e92-428f-8ab7-10de5172589e
  [   ] Choice 1: Packages may not (in general) require a specific init system
  [   ] Choice 2: Support alternative init systems as much as possible
  [   ] Choice 3: Packages may require specific init systems if maintainers 
  decide
  [   ] Choice 4: General Resolution is not required
  [   ] Choice 5: Further Discussion
  - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
 
 I must say that I am quite surprised by you choice of summary for Choice 2.
 
 First, that's the only one not to include a verb. It could be understood
 as Packages *must* support alternative init systems as much as
 possible, which is clearly misleading. Also as much as possible is
 not part of the amendment.
 

Choice 2 seems to be about 4 things:
* The default init system on all arches should be supported, 
* maintainers should merge support for init systems, 
* sysvinit support should be maintained for all packages which
worked before and any the release team should accept changes during the
freeze which preserve or enhance this support

This is obviously quite hard to put into one line.

 
 Second, after asking for an accurate summary, I replied in
 20141017202805.ga10...@xanadu.blop.info (private mail to you+Ian, as
 was your initial query) with: support for alternative init systems is
 desirable but not mandatory. If you disagreed with the suggestion, why
 didn't you say so since Oct 17th?
 

Quite frankly, there's been one hell of a lot of mail during this
process, which I've done my best to read and digest. The other option in
that mail which you suggested was also quite contentious. I'd be happy
with you sending the entire thread to the list if you and Ian agree.

That entire thread seemed to then devolve with various accusations, and
then you confusing my suggestions for Ian's text for your own.

 If my suggestion is too long, you could have used any of the following,
 which are all shorter or the same size as the summary for Choice 3:
 - Support for alternative init systems is desirable, not mandatory
 - Maintainers are encouraged to support alternative init systems

That doesn't appear to capture the paragraph starting For the Jessie
release... accurately.

I discussed the final summaries with Kurt before the CfV, and we think
that this is about as accurate as we could do given the very short
amount of space available. This is also the reason I added a separate
paragraph encouraging people to go and read the full proposals.

 I think that it would be better to update the CfV.
 

Given the above, I don't believe that this would help the process. I
feel that the summaries are as accurate as they can be at this time.

 Also, it's a much more minor problem, but it seems that you missed my
 second for the fourth proposal in 20141022054027.ga30...@xanadu.blop.info.
 

Updated thanks, should be live when the website updates.

Neil


signature.asc
Description: Digital signature

Re: Call for Votes: General Resolution: Init system coupling

[Neil McGovern]

On Tue, Nov 04, 2014 at 07:11:45PM +, Ian Jackson wrote:
 I think this is still possible.  It's a shame that this slightly odd
 pre-CFV (CFV posted before voting period opens) wasn't explicitly a
 draft, and posted only to -vote.
 

This vote has currently used up about 15 hours of my time, plus the time
to read -vote, and I really didn't want to wait up until gone midnight
to post the CfV.

For the draft ballot, although there's no requirement to do so, I do
indeed think it's a good idea in general. I've added it to
https://wiki.debian.org/Secretary/StartAVote which is also an attempt
to document how to run a vote, which didn't exist before.

Neil
-- 


signature.asc
Description: Digital signature

Re: Call for Votes: General Resolution: Init system coupling

[Ian Jackson]

Neil McGovern writes (Re: Call for Votes: General Resolution: Init system 
coupling):
 Choice 2 seems to be about 4 things:
...
 This is obviously quite hard to put into one line.

It is more important not to be misleading, than it is to capture
everything in the proposal.

The summary you have written is misleading, because there is in fact
no requirement in Lucas's proposal for anything to support
alternatives `as much as possible' (whatever that might mean).

Lucas's proposal puts heavy emphasis on support for the _default_ init
system, and generally treats alternatives as second class citizens.

As for alternatives, Lucas's proposal merely says that maintainers are
encouraged to _merge_ support.  It does not even mildly encourage
maintainers or upstreams to provide such support themselves.

Ian.


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21593.11237.799844.151...@chiark.greenend.org.uk

Re: Call for Votes: General Resolution: Init system coupling

[Lucas Nussbaum]

On 04/11/14 at 19:27 +, Neil McGovern wrote:
 On Tue, Nov 04, 2014 at 07:54:46PM +0100, Lucas Nussbaum wrote:
  Hi Neil,
  
  On 04/11/14 at 17:53 +, Neil McGovern wrote:
   - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
   57dd4d7c-3e92-428f-8ab7-10de5172589e
   [   ] Choice 1: Packages may not (in general) require a specific init 
   system
   [   ] Choice 2: Support alternative init systems as much as possible
   [   ] Choice 3: Packages may require specific init systems if maintainers 
   decide
   [   ] Choice 4: General Resolution is not required
   [   ] Choice 5: Further Discussion
   - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
  
  I must say that I am quite surprised by you choice of summary for Choice 2.
  
  First, that's the only one not to include a verb. It could be understood
  as Packages *must* support alternative init systems as much as
  possible, which is clearly misleading. Also as much as possible is
  not part of the amendment.
  
 
 Choice 2 seems to be about 4 things:
 * The default init system on all arches should be supported, 
 * maintainers should merge support for init systems, 
 * sysvinit support should be maintained for all packages which
 worked before and any the release team should accept changes during the
 freeze which preserve or enhance this support

I cannot parse the last bullet point, sorry (and any the release
team?). Also, the proposal does not mention the release team.
Reasonable changes to preserve or improve sysvinit support should be
accepted through the jessie release. is not meant as an override of the
release team: the maintainer should accept such changes, not necessarily
the release team (normal rules for the freeze should apply).
If I intended to override the release team here, I would obviously have
made it explicit.

I am sorry you did not use the discussion period to clarify this, it
could have resulted in an improved proposal.

 This is obviously quite hard to put into one line.
 
  
  Second, after asking for an accurate summary, I replied in
  20141017202805.ga10...@xanadu.blop.info (private mail to you+Ian, as
  was your initial query) with: support for alternative init systems is
  desirable but not mandatory. If you disagreed with the suggestion, why
  didn't you say so since Oct 17th?
  
 
 Quite frankly, there's been one hell of a lot of mail during this
 process, which I've done my best to read and digest. The other option in
 that mail which you suggested was also quite contentious. I'd be happy
 with you sending the entire thread to the list if you and Ian agree.

Oh, I would be fine with that. But to summarize, I originally suggested
make each package support all alternative init systems for Ian's.
At the time, it was not clear to me that Ian meant at least one
alternative and not all alternative. I wasn't the only one making
that mistake, and Ian later improved his proposal to clarify this. I also
apologized for this misunderstanding in 
20141021125657.ga12...@xanadu.blop.info.

 That entire thread seemed to then devolve with various accusations, and
 then you confusing my suggestions for Ian's text for your own.

That's not an accurate summary of the discussion. See
20141020111714.ga18...@halon.org.uk, 3165381.DVHk3vBgWs@gyllingar,
20141021083354.gk18...@halon.org.uk,
20141021125657.ga12...@xanadu.blop.info (all on debian-vote@).
(anyway, I don't think it's important in that current discussion)

  If my suggestion is too long, you could have used any of the following,
  which are all shorter or the same size as the summary for Choice 3:
  - Support for alternative init systems is desirable, not mandatory
  - Maintainers are encouraged to support alternative init systems
 
 That doesn't appear to capture the paragraph starting For the Jessie
 release... accurately.

That paragraph could be summarized as support wheezy-jessie upgrades
nicely, as was detailed in e.g.
20141021131459.ga13...@xanadu.blop.info. This is not the core of the
proposal.

 I discussed the final summaries with Kurt before the CfV, and we think
 that this is about as accurate as we could do given the very short
 amount of space available. This is also the reason I added a separate
 paragraph encouraging people to go and read the full proposals.

[...]

 Given the above, I don't believe that this would help the process. I
 feel that the summaries are as accurate as they can be at this time.

I strongly disagree, and urge you to reconsider.

However, if you decide not to change the summary for this proposal to
something that I would consider an accurate summary of it, I
ask you to include a title at the start of my proposal (under Choice
2:, but before Debian has decided [...]), that should read:

| Support for alternative init systems is desirable, not mandatory
| 

That's only a compromise solution, and clearly not one I'm satisfied

Re: Call for Votes: General Resolution: Init system coupling

[Neil McGovern]

On Tue, Nov 04, 2014 at 09:17:51PM +0100, Lucas Nussbaum wrote:
 I cannot parse the last bullet point, sorry (and any the release
 team?). Also, the proposal does not mention the release team.
 Reasonable changes to preserve or improve sysvinit support should be
 accepted through the jessie release. is not meant as an override of the
 release team: the maintainer should accept such changes, not necessarily
 the release team (normal rules for the freeze should apply).
 If I intended to override the release team here, I would obviously have
 made it explicit.


Well, any enhancement for sysvinit support would certainly be against
the freeze policy. However, as these are decisions which in theory the
release team has not yet made (it's done on a case by case basis) then
there's no decision to override yet, hence the 1:1 requirement.

Additionally, after the Jessie release date, if a bug comes in that
improves support for the stable version of a package, what is the
maintainer supposed to do?

 I am sorry you did not use the discussion period to clarify this, it
 could have resulted in an improved proposal.
 

I'm not sure it's really my position to try and amend your text in this
case, I've not been asked to do so. It is, however, regrettable that I
haven't had time to continue to discuss the summary lines.
Would you be happy with me simply cancelling the entire vote to allow
that discussion to take place? I'm not keen to adjust the ballot before
midnight, I'd rather send out a new CfV if that's the case.

   If my suggestion is too long, you could have used any of the following,
   which are all shorter or the same size as the summary for Choice 3:
   - Support for alternative init systems is desirable, not mandatory
   - Maintainers are encouraged to support alternative init systems
  
  That doesn't appear to capture the paragraph starting For the Jessie
  release... accurately.
 
 That paragraph could be summarized as support wheezy-jessie upgrades
 nicely, as was detailed in e.g.
 20141021131459.ga13...@xanadu.blop.info. This is not the core of the
 proposal.
 

However, it's in the text. If you didn't want it to be part of the
proposal, it should have not been there, or been as a summary outside of
the resolution to be passed. The fact remains that it's in there,
whether your intention or not.

  I discussed the final summaries with Kurt before the CfV, and we think
  that this is about as accurate as we could do given the very short
  amount of space available. This is also the reason I added a separate
  paragraph encouraging people to go and read the full proposals.
 
 [...]
 
  Given the above, I don't believe that this would help the process. I
  feel that the summaries are as accurate as they can be at this time.
 
 I strongly disagree, and urge you to reconsider.
 
 However, if you decide not to change the summary for this proposal to
 something that I would consider an accurate summary of it, I
 ask you to include a title at the start of my proposal (under Choice
 2:, but before Debian has decided [...]), that should read:
 
 | Support for alternative init systems is desirable, not mandatory
 | 
 
 That's only a compromise solution, and clearly not one I'm satisfied
 with -- I still think that this should be used as the summary.

I think that the web pages and the ballot not matching would be the
worst of all worlds to be honest. Unless I'm mis-understanding?

Neil


signature.asc
Description: Digital signature

Re: Call for Votes: General Resolution: Init system coupling

[Don Armstrong]

On Tue, 04 Nov 2014, Lucas Nussbaum wrote:
 On 04/11/14 at 17:53 +, Neil McGovern wrote:
  - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
  57dd4d7c-3e92-428f-8ab7-10de5172589e
  [   ] Choice 1: Packages may not (in general) require a specific init system
  [   ] Choice 2: Support alternative init systems as much as possible
  [   ] Choice 3: Packages may require specific init systems if maintainers 
  decide
  [   ] Choice 4: General Resolution is not required
  [   ] Choice 5: Further Discussion
  - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-

Why not just make Choice 2:

Packages should support sysvinit for jessie.

Otherwise, if you all aren't able to agree, just:

Choice 1: Proposal
Choice 2: Amendment A
Choice 3: Amendment B
Choice 4: Amendment C
Choice 5: Further Discussion

and we can get on with the voting.

-- 
Don Armstrong  http://www.donarmstrong.com

People selling drug paraphernalia ... are as much a part of drug
trafficking as silencers are a part of criminal homicide.
 -- John Brown, DEA Chief


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141104213018.gx24...@rzlab.ucr.edu

Re: Call for Votes: General Resolution: Init system coupling

[Dimitri John Ledkov]

On 4 November 2014 21:30, Don Armstrong d...@debian.org wrote:
 On Tue, 04 Nov 2014, Lucas Nussbaum wrote:
 On 04/11/14 at 17:53 +, Neil McGovern wrote:
  - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
  57dd4d7c-3e92-428f-8ab7-10de5172589e
  [   ] Choice 1: Packages may not (in general) require a specific init 
  system
  [   ] Choice 2: Support alternative init systems as much as possible
  [   ] Choice 3: Packages may require specific init systems if maintainers 
  decide
  [   ] Choice 4: General Resolution is not required
  [   ] Choice 5: Further Discussion
  - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-

 Why not just make Choice 2:

 Packages should support sysvinit for jessie.

 Otherwise, if you all aren't able to agree, just:

 Choice 1: Proposal
 Choice 2: Amendment A
 Choice 3: Amendment B
 Choice 4: Amendment C
 Choice 5: Further Discussion

 and we can get on with the voting.


+1, I was also expecting the ballot to be like this, which indeed
would force people to read the full texts of the vote, as I do not
think the summaries are fair (they are either under or over stating
the actual choice text)

-- 
Regards,

Dimitri.


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CANBHLUhER_9=s56djpkuogjbjc61pqnxfr7vzt1l+fxqjm2...@mail.gmail.com

Re: Call for Votes: General Resolution: Init system coupling

[Neil McGovern]

On Tue, Nov 04, 2014 at 01:30:18PM -0800, Don Armstrong wrote:
 On Tue, 04 Nov 2014, Lucas Nussbaum wrote:
  On 04/11/14 at 17:53 +, Neil McGovern wrote:
   - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
   57dd4d7c-3e92-428f-8ab7-10de5172589e
   [   ] Choice 1: Packages may not (in general) require a specific init 
   system
   [   ] Choice 2: Support alternative init systems as much as possible
   [   ] Choice 3: Packages may require specific init systems if maintainers 
   decide
   [   ] Choice 4: General Resolution is not required
   [   ] Choice 5: Further Discussion
   - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
 
 Why not just make Choice 2:
 
 Packages should support sysvinit for jessie.
 
 Otherwise, if you all aren't able to agree, just:
 

Long story short, we've come to an agreement on: Support for other init
systems is recommended, but not mandatory

I'll send out a new CfV once voting opens.

Neil


signature.asc
Description: Digital signature

How about always sending a copy of proposals, amendements, secondes etc. to the Secretary ? (Re: Call for Votes: General Resolution: Init system coupling)

[Charles Plessy]

Le Tue, Nov 04, 2014 at 07:32:36PM +, Neil McGovern a écrit :
 
 This vote has currently used up about 15 hours of my time, plus the time
 to read -vote, and I really didn't want to wait up until gone midnight
 to post the CfV.

Hi Neil and everybody,

first, thank you Neil for the hard work on managing the vote on this GR.

Would it help to amend point 4.2.5 of our constitution, to request that in
addition to the announcement on a publicly-readable electronic mailing list,
a copy of proposals, amendments, sponsors, etc. must also be sent to the
Secretary ?  It seems unfair to request the Secretary to read each and every
email on debian-vote...

I understand that changing the Consitituion is hard, but since there are other
general changes under discussion, maybe there is an opportunity to bundle the
most consensual ones...

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141105004031.gb12...@falafel.plessy.net

Re: call for votes on code of conduct GR

[Michael Banck]

Hi,

On Sun, Apr 06, 2014 at 02:23:39PM +0200, Wouter Verhelst wrote:
 I'd like to call for votes on the code of conduct GR.

Just a question - the CoC we are voting on is the one from
https://lists.debian.org/debian-vote/2014/02/msg2.html or which one
is it?  Were any of the numerous objections and comments since then
taken into account at all?


Michael


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140417225718.gc19...@raptor.chemicalconnection.dyndns.org

Re: call for votes on code of conduct GR

[Russ Allbery]

Michael Banck mba...@debian.org writes:
 On Sun, Apr 06, 2014 at 02:23:39PM +0200, Wouter Verhelst wrote:
 I'd like to call for votes on the code of conduct GR.

 Just a question - the CoC we are voting on is the one from
 https://lists.debian.org/debian-vote/2014/02/msg2.html or which one
 is it?  Were any of the numerous objections and comments since then
 taken into account at all?

It's the one linked on the official vote notification at:

https://www.debian.org/vote/2014/vote_002

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87ppkfy31m@windlord.stanford.edu

Re: call for votes on code of conduct GR

[Dominique Dumont]

On Monday 14 April 2014 20:22:41 Dominique Dumont wrote:
 On Sunday 13 April 2014 19:21:18 Kurt Roeckx wrote:
  - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-

Argh. Looks like I tend to juggle with too many topics...

Sorry about the noise.

All the best

-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/2744868.P4myHxBkDp@ylum

Re: call for votes on code of conduct GR

[Dominique Dumont]

On Sunday 13 April 2014 19:21:18 Kurt Roeckx wrote:
 - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
 a6966a7c-75e9-4f93-a50e-fd6b331012e4
 [ 1  ] Choice 1: Accept CoC, DPL can update it
 [ 2  ] Choice 2: Accept CoC, updates via GR
 [   ] Choice 3: Further Discussion
 - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-

-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

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

Re: call for votes on code of conduct GR

[Kurt Roeckx]

On Sun, Apr 06, 2014 at 09:37:57PM +0200, Kurt Roeckx wrote:
 On Sun, Apr 06, 2014 at 02:23:39PM +0200, Wouter Verhelst wrote:
  Hi,
  
  I'd like to call for votes on the code of conduct GR.
 
 I'm going to start the vote next weekend, starting on the 13th.
 The dpl vote and this vote will overlap for 1 days.

I forgot about it yesterday, so I'm doing it today.  The ballot is
below.


 Voting period starts  00:00:00 UTC on Monday, April 14th, 2014
 Votes must be received by 23:59:59 UTC on Sunday, April 27nd, 2014

The following ballot is for voting on a code of conduct.
This vote is being conducted as required by the Debian Constitution.
You may see the constitution at http://www.debian.org/devel/constitution.
For voting questions or problems contact secret...@debian.org.

The details of the general resolution can be found at:
http://www.debian.org/vote/2014/vote_002

Also, note that you can get a fresh ballot any time before the end of
the vote by sending a signed mail to
   bal...@vote.debian.org
with the subject codeofconduct.

To vote you need to be a Debian Developer.

HOW TO VOTE

First, read the full text of the platform.

To cast a vote, it is necessary to send this ballot filled out to a
dedicated e-mail address, in a signed message, as described below.
The dedicated email address this ballot should be sent to is:

  codeofcond...@vote.debian.org

The form you need to fill out is contained at the bottom of this
message, marked with two lines containing the characters
'-=-=-=-=-=-'. Do not erase anything between those lines, and do not
change the choice names.

There are 3 choices in the form, which you may rank with numbers between
1 and 3. In the brackets next to your preferred choice, place a 1.
Place a 2 in the brackets next to your next choice. Continue until you
reach your last choice.  Do not enter a number smaller than 1 or larger
than 3.

You may skip numbers, leave some choices unranked, and rank options
equally.  Unranked choices are considered equally the least desired
choices, and ranked below all ranked choices.

To vote no, no matter what, rank Further Discussion as more desirable
than the unacceptable choices, or you may rank the Further Discussion
choice and leave choices you consider unacceptable blank.  (Note: if the
Further Discussion choice is unranked, then it is equal to all other
unranked choices, if any -- no special consideration is given to the
Further Discussion choice by the voting software).

Finally, mail the filled out ballot to: codeofcond...@vote.debian.org.

Don't worry about spacing of the columns or any quote characters () that
your reply inserts.

NOTE: The vote must be GPG signed (or PGP signed) with your key that is
in the Debian keyring.  You may, if you wish, choose to send a signed,
encrypted ballot: use the vote key appended below for encryption.

The voting software (Devotee) accepts mail that either contains only an
unmangled OpenPGP message (RFC 2440 compliant), or a PGP/MIME mail
(RFC 3156 compliant).  To avoid problems I suggest you use PGP/MIME.

- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
a6966a7c-75e9-4f93-a50e-fd6b331012e4
[   ] Choice 1: Accept CoC, DPL can update it
[   ] Choice 2: Accept CoC, updates via GR
[   ] Choice 3: Further Discussion
- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-

--

The responses to a valid vote shall be signed by the vote key created
for this vote. The public key for the vote, signed by the Project
secretary, is appended below.

-BEGIN PGP PUBLIC KEY BLOCK-
Version: GnuPG v1

mQINBFNKxdMBEADAVpjLKUC/9vyXwWjlfwUAhJqLoCSRjNInfZIV+Y5GekAY5CSC
BttpFjVpUPofKQMbbyMS19/c6B07bQYNNg9Wrf7zMKFYCiaMrPEUSC7EECHD1YTY
bFnN6Bsn5/a3RkhPhyC+YRR6YH2X4pklbl2fAN9nf6+RdPc+s/kIqc7TYCDuKmIQ
cJD+P2qVUVejFDIQu1kQyQC0e0h+ucB4G2mdws5Gl/42uxa3Lg/5vn1O6nley9wy
TuiIDp5yGZT2IucU/urPTpDNF/OxPqnkbNENqpgOCnOYgZl8M6h4w+ol7dzOIyWc
NteuRW2qUbl8JPpZhiIWroIo6hFR8mkmVk5tqKVfZRjB/fohfo8721eZcGiELwYU
37COjDvKU7ag48dn2h+y7VawoP1XFztEkb3CNquxzf7lKvoRJM6LvKeYu35schGH
LgWA/iySPhNyz2vr8Gev9kSsQjyCarbk6qakXCBjKfVW/tI/n2UgXkgTLe/BNeVj
rRiklmYXX7TM6MMdIDAVhm3xEoWNQNEeEcW2dYRBri9Pi64S2aq3+Xx5s/8UIAFu
3euuAdB+3faP0AlOwfYZhiHumtbUOzfrbSiCcvb0TLQtBc9D3hXIrN3Wfbr3Z1N7
17MYO4T+cy1LAF4mWpUZE3uB3N91fVhpvcHhk08E7q/3KJpQySpzhPpZQwARAQAB
tC9Db2RlIG9mIGNvbmR1Y3QgPGNvZGVvZmNvbmR1Y3RAdm90ZS5kZWJpYW4ub3Jn
PokCPgQTAQIAKAUCU0rF0wIbAwUJABuvgAYLCQgHAwIGFQgCCQoLBBYCAwECHgEC
F4AACgkQEyvXRTBTzcDFjg/+PSRunvLsmG85XIy8oOp/LlHh52HWfiJwZDIB5up3
7a2lHspIh2uxfN2b9tAYD3mnnhca0NOscc/ZMntSKq3uKnKp3XRG/idZnVQekzeS
KX3bCkkMfnojMyrRkoUv3hriHPmdmcxBAKniXIzj4a5FmKsG3R3SV9eVB4IbkV8O
8YEDPeJl/d+8OwOjghjtbgYALWvU6OMPYgLqq400TWpk7VholA30YTJ3meOgn42V
1GkMK1F+eC09qJ5ScIwUdzmTSw7biXsxAcPFlnWRUtSMLUxQ78OUJ4orypjdalLG
x39QiOehw0wdLb3h6ZJuHo8+AImtlPP4T3bjqJv8RcuGcJfJHwgCAH6ZxHseJUVa
T83kJhoGEJVtZddOK4/jDZTgcrE3iKtyz1eidtSD8DFRSa2rmJVwImLNG4qKsuNz

Re: call for votes on code of conduct GR

[Kurt Roeckx]

On Mon, Apr 07, 2014 at 12:02:20AM +0200, Holger Levsen wrote:
 Hi,
 
 On Sonntag, 6. April 2014, Kurt Roeckx wrote:
  I'm going to start the vote next weekend, starting on the 13th.
 
 does that mean there is still time to amend it?

No.

You already had 4 weeks since the last amendent was accepted,
which is the point I would withdrawn it.


Kurt


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140407161204.ga4...@roeckx.be

Re: call for votes on code of conduct GR

[Holger Levsen]

Hi,

On Sonntag, 6. April 2014, Kurt Roeckx wrote:
 I'm going to start the vote next weekend, starting on the 13th.

does that mean there is still time to amend it?


cheers,
Holger





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

Re: Call for Votes - GR: Debian project members

[Andrei Popescu]

On Ma, 05 oct 10, 15:47:05, Bernhard R. Link wrote:
 * Bernhard R. Link brl...@debian.org [101005 11:55]:
  My best guess yet is that this proposal is to tell DAM that we do not oppose
  second-class Debian Developers with less privileges, so that they may add
  second-class DDs in the hope that this will encourage more non-packagers to
  become DDs (albeit then second class ones).
 
 Okay, second try after I got some replies in private discussion. Trying
 to move this to debian-vote in the hope that I am not the only one so
 slow on the uptake, so others might benefit from it:
 
 This proposal is to tell DAM we are not opposed to having Debian
 Developers with less privileges than DDs currently get by default,
 so that DAM is more likely to implement something were people may get
 only a subset of the current initial privileges in the hope that this
 will encourage more non-packagers to become DD (with then less privileges
 than currently but in a way they do not feel like second class citizens).

I might be mistaken, since I'm not a native English speaker, but you 
seem to imply that having DDs with less privileges can be a bad thing. 

If my hunch was right, do you think that people might not want to join 
the Project due to the fear of becoming second-class citizens or are 
there some other problems that you expect?

Regards,
Andrei
-- 
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic


signature.asc
Description: Digital signature

Re: Call for Votes - GR: Debian project members

[Bernhard R. Link]

* Roland Stigge sti...@antcom.de [101004 22:26]:
 On 04/10/10 21:47, Debian Project Secretary - Neil McGovern wrote:
  [   ] Choice 1: Welcome non-packaging contributors as project members
  [   ] Choice 2: Further discussion

 Sorry, I'm late. :-(

 I just got the ballot, but I'm not sure how to vote because we already
 have non-packaging developers as DDs (find examples in db.debian.org).

 So maybe it's not really necessary to change anything if this is already
 common practice for years now.

 But maybe I missed some of the discussion where this issue was already
 discussed.

 So please just point me (and maybe others, too) to it so I can vote. :-)

There is a long thread on debian-vote about this. I had the same
question and that thread did not really answer it for me.

My best guess yet is that this proposal is to tell DAM that we do not oppose
second-class Debian Developers with less privileges, so that they may add
second-class DDs in the hope that this will encourage more non-packagers to
become DDs (albeit then second class ones).

Did I guess that approximately right?
If not I'd like getting some more information, too.

Bernhard R. Link

Please reply to debian-vote only...


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20101005095502.ga21...@pcpool00.mathematik.uni-freiburg.de

Re: Call for Votes - GR: Debian project members

[Stefano Zacchiroli]

On Tue, Oct 05, 2010 at 11:55:02AM +0200, Bernhard R. Link wrote:
  So please just point me (and maybe others, too) to it so I can vote. :-)
 
 There is a long thread on debian-vote about this. I had the same
 question and that thread did not really answer it for me.

As far as I can tell you did get your answer, in fact twice. Once in a
direct follow-up to your question provided by Margarita Manterola [1]; I
did not follow-up to that message, but I AOL her text word by word.
Moreover, I did actually answer your question—possibly even before you
asked, modulo some timezone gymnastic—in my followup at [2].

Cheers.

[1] http://lists.debian.org/debian-vote/2010/09/msg00093.html
[2] http://lists.debian.org/debian-vbefore, ote/2010/09/msg00052.html

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, |  .  |. I've fans everywhere
ti resta John Fante -- V. Caposella ...| ..: |.. -- C. Adams


signature.asc
Description: Digital signature

Re: Call for Votes - GR: Debian project members

[Stefano Zacchiroli]

On Tue, Oct 05, 2010 at 12:15:10PM +0200, Stefano Zacchiroli wrote:
 [2] http://lists.debian.org/debian-vbefore, ote/2010/09/msg00052.html

Urgh, bad URL, that should have been (thanks jcristau for noticing):

  http://lists.debian.org/debian-vote/2010/09/msg00052.html

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, |  .  |. I've fans everywhere
ti resta John Fante -- V. Caposella ...| ..: |.. -- C. Adams


signature.asc
Description: Digital signature

Re: Call for Votes - GR: Debian project members

[Bernhard R. Link]

* Bernhard R. Link brl...@debian.org [101005 11:55]:
 My best guess yet is that this proposal is to tell DAM that we do not oppose
 second-class Debian Developers with less privileges, so that they may add
 second-class DDs in the hope that this will encourage more non-packagers to
 become DDs (albeit then second class ones).

Okay, second try after I got some replies in private discussion. Trying
to move this to debian-vote in the hope that I am not the only one so
slow on the uptake, so others might benefit from it:

This proposal is to tell DAM we are not opposed to having Debian
Developers with less privileges than DDs currently get by default,
so that DAM is more likely to implement something were people may get
only a subset of the current initial privileges in the hope that this
will encourage more non-packagers to become DD (with then less privileges
than currently but in a way they do not feel like second class citizens).

Did I get this correct this time? (If I got it, I guess your reply
answered my question).

Bernhard R. Link


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20101005134705.ga27...@pcpool00.mathematik.uni-freiburg.de

Re: Call for votes for GR: : Handling source-less firmware in the Linux kernel

[MJ Ray]

Manoj Srivastava [EMAIL PROTECTED] wrote:
 On Tue, 10 Oct 2006 17:59:38 +0100 (BST), MJ Ray [EMAIL PROTECTED] said: 
  Manoj Srivastava [EMAIL PROTECTED] wrote:
  Commentary is one thing. Hysterical overreaction to the magnitude
  of the error is another.
 
  Quite.  Neither These instructions are self-contradictory nor
  name the amendment on the ballot are hysterical overreaction,
  whereas Does anyone themselves have had problems figuring out what
  this was all about and Rubish. You have tow overlapping
  constraints seem closer to hysterical: so keen to flame that
  spelling and grammar went out the window.
 
 Jumping to conclusions as usual. The stutter in messages is
  due to the hotel network randomly dropping packets, to the point
  where typing is often painful.  However, don't let trying to discover
  facts get in your way.

I'm telling how it looks from here, but I bow to others' expertise
in jumping to conclusions.

I don't know what computer power is available locally, but offline
reading and composing may help.  It just took three weeks to get a
telephone line to my side of the hill, so I've been doing that
recently.

 Secondly, hectoring me does not solvce anything; I note that
  no one actually has done _anything_ to reduce the discombobulation;
  no one even mailed d-d-a, which is something I can't do without
  access to my keys.

Like the whole NMU thing, there's often a feeling that people should at
least be given a chance to fix their own mistakes.  How should anyone
know when someone doesn't have access to their keys?  Was anyone asked
to mail d-d-a and correct the Secretary in full view of all the press
and so on who read that list but not this one?

[...]
 Actually, it might have something to do with your ability to
  be a team player.

It might, but I consider it unlikely, because of the well-functioning
and successful teams that I have been part of.  That said, I know
that the almost genetic-algorithm-like heavy approach of the debian
project is rather different from the cooperatives and collectives I've
been working with lately.  I doubt that the debian project has many
good (open, autonomous, informative and so on) teams today - and DPL
candidates who advocated more good teamwork have been roundly rejected
in recent elections.

  That works both ways.  People should stop treating fellow volunteers
  as faceless workers and use the power of their role to encourage
  them, rather than seeming to spend equivalent effort on discouraging
  them.  
 
 Why on earth should I encourage behaviour that is merely
  obstructive rather than helping role players in doing their job? [...]

What a way to extend the suggestion into something daft! Encourage good
behaviour instead of only discouraging bad.

Hope that explains,
-- 
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Call for votes for GR: : Handling source-less firmware in the Linux kernel

[MJ Ray]

Manoj Srivastava [EMAIL PROTECTED] wrote:
 On Tue, 10 Oct 2006 10:43:03 +0100 (BST), MJ Ray [EMAIL PROTECTED] said: 
  Frank =?iso-8859-1?Q?K=FCster?= [EMAIL PROTECTED] wrote:
  [...] And how about your offering him to proofread the ballot?  Or
  just doing it, since he actually posted it in public for that very
  purpose?
 
  I thought it was posted so that everyone could see the Secretary had
  shown it to the Proposer and Seconders.
 
 Why on earth would I just show people stuff?

Transparency.  If not for that or comment, why is it posted?

  The most common response to other comments recently is suggesting
  that the commenter is too thick to vote.
 
 Commentary is one thing. Hysterical overreaction to the
  magnitude of the error is another.

Quite.  Neither These instructions are self-contradictory nor name the
amendment on the ballot are hysterical overreaction, whereas Does anyone
themselves have had problems figuring out what this was all about and
Rubish. You have tow overlapping constraints seem closer to hysterical:
so keen to flame that spelling and grammar went out the window.

 I think this phenomena stems from
  people no longer treating Debian as a fun project that a group of
  volunteers got together to do -- the paradigm has shifted to people
  wanting service. This might be a result of Debian growing too large
  and anonymous -- now people want services, and complain if the
  service does not meet their standards.
 
 This is true also of other role aspects -- DAM, FTP-master,
  etc.  When you are expecting a service, you are the most important
  component -- your needs must be met. there is no room for erros on
  the part of the so called service provider. You know, the customer is
  always right.

At least for me, it's not like that.  As with LUGs, I thank people when
they help and I expect people holding roles to be polite in reply to
polite requests, to be reasonably open and to clean up their own mistakes
promptly once asked.  If they can't cope with such basic teamwork any
longer, they should seek assistance, resign or be replaced.  At worst,
it should take less than 3 years to fix a simple error or grant those
affected power to fix it.

Unlike LUGs, I've seldom seen thanks for any debian things I do.  In one
way, that's OK - I do debian tasks for pragmatic reasons and I've only
twice been offered small extra roles AFAICR - but it does suggest to me
that something's rotten in the debian world.  I think more small teams,
more egalitarianism and more openness are the way forwards, but that
seems to be opposite of the current direction of travel - for now.

  shame
 
 Indeed.  People whould stop treating fellow volunteers as
  faceless workers, and realize that mistakes happen, and help work
  around them, rather than raising the roof about how the sky is
  falling.

That works both ways.  People should stop treating fellow volunteers
as faceless workers and use the power of their role to encourage them,
rather than seeming to spend equivalent effort on discouraging them.
-- 
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Call for votes

[Sven Luther]

On Tue, Oct 10, 2006 at 11:56:12PM -0500, Manoj Srivastava wrote:
 On Tue, 10 Oct 2006 21:51:32 +0200, Sven Luther [EMAIL PROTECTED] said: 
 
 
  Given the way the secretary has hurried the vote, and the way
  everyone is ignoring the more mature proposal at :
 
http://lists.debian.org/debian-vote/2006/10/msg00183.html
 
  i now release the call for vote, and ask for a vote to be held with
  the original proposal from Frederik, which has had enough seconds
  since August 31.
 
 
 Frederik accepted the formal amendment, so there is no
  original proposal. There was no objection from anyone,  and the GR

There was objection, at least from me.

  has already been put to vote.
 
 If you and at least 5 other people feel that there needs to be
  a vote on  the initial version of Frederik's proposal, feel free to
  repropose it independently.

Everyone is ignoring me anyway, so you perfectly know that this will never
happen, thanks very much.

I feel strongly that the way things are currently going is dishonest on your
part, as well as on the part of the DPL, who asked me to delay the call for
vote.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Call for votes (Was: kernel firmwares: GR proposal)

[Steve Langasek]

On Tue, Oct 10, 2006 at 09:51:32PM +0200, Sven Luther wrote:
 i now release the call for vote, and ask for a vote to be held with the
 original proposal from Frederik, which has had enough seconds since August 31.

As a point of order, the original proposal from Frederik was superseded once
he accepted Manoj's amendment, and several of the seconders of the original
proposal also seconded the amended proposal, indicating their acceptance of
the amendment.  Under the constitution, this means the proposal must get a
new proposer and the seconds must be re-established in order to have a
formal proposal.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Call for votes (Was: kernel firmwares: GR proposal)

[Sven Luther]

On Tue, Oct 10, 2006 at 09:20:37PM -0500, Steve Langasek wrote:
 On Tue, Oct 10, 2006 at 09:51:32PM +0200, Sven Luther wrote:
  i now release the call for vote, and ask for a vote to be held with the
  original proposal from Frederik, which has had enough seconds since August 
  31.
 
 As a point of order, the original proposal from Frederik was superseded once
 he accepted Manoj's amendment, and several of the seconders of the original
 proposal also seconded the amended proposal, indicating their acceptance of
 the amendment.  Under the constitution, this means the proposal must get a
 new proposer and the seconds must be re-established in order to have a
 formal proposal.

Yeah, i know, Manoj told that. I wonder why it is not possible to keep the old
proposal ongoing, the same way a seconder can retake a proposal the original
proposer retire, not sure this makes sense.

That said, i consider that this proposal currently under vote is not a good
one, that i have been wronged when i agreed to delay the original call to vote
on the DPLs urging, since it is clear that all the effort i have done is now
showed in the trashcan, since we are voting on Manoj's proposal, which will
mean we have to get ride of a number of firmwares, among them the tg3
firmware, which is contrary to the result of the kernel team position
statement and will.

Frederik i don't understand why you did let that happen, and why you didn't at
least second the proposal we worked on together.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Call for votes for GR: : Handling source-less firmware in the Linux kernel

[Sven Luther]

On Sat, Oct 07, 2006 at 06:52:41PM -0500, Debian Project Secretary wrote:
 - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
 c2d43675-9efa-4809-a4aa-af042b62786e
 [   ] Choice 1: Release Etch even with kernel firmware issues

Manoj, you have again overstepped your Secretarial position, by issuing a
misleading title for the proposal you propose.

The proposal of Frederik would have allowed etch to release, while the one
amended by you, will cause more problems that it solves, in particular it will
mean many firmwares will have to go, among them the tg3 one, and so we either
drop support for the users of those hardware (and there was general outcry for
this one, even inside the kernel team when this was first proposed), or we
delay etch until the d-i folk get the support for non-free firmware going.

So, given this poorly worded ballot, i suppose the vote will be void anyway,
and i strongly call for everyone to vote further discussion over the other
solutions.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Call for votes for GR: : Handling source-less firmware in the Linux kernel

[Don Armstrong]

On Wed, 11 Oct 2006, Sven Luther wrote:
 On Sat, Oct 07, 2006 at 06:52:41PM -0500, Debian Project Secretary wrote:
  - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
  c2d43675-9efa-4809-a4aa-af042b62786e
  [   ] Choice 1: Release Etch even with kernel firmware issues
 
 Manoj, you have again overstepped your Secretarial position, by
 issuing a misleading title for the proposal you propose.

When Frederik accepted the proposed amendment, Manoj was no longer the
proposer. Furthermore, the title of a voting option on the ballot is
perfectly meaningless. Attempts by the secretary to make them
informative are appreciated, but any voter who actually pays any
attention to them should be voting the null ballot, as they clearly
haven't informed themselves appropriately.

Finally, there's no reason to crosspost this stuff to multiple lists;
complaints about the form of the ballot belong on -vote.


Don Armstrong

-- 
Il semble que la perfection soit atteinte non quand il n'y a plus rien
a ajouter, mais quand il n'y a plus rien a retrancher.
(Perfection is apparently not achieved when nothing more can be added,
but when nothing else can be removed.)
 -- Antoine de Saint-Exupe'ry, Terres des Hommes

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


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Call for votes for GR: : Handling source-less firmware in the Linux kernel

[Sven Luther]

On Wed, Oct 11, 2006 at 01:16:39AM -0700, Don Armstrong wrote:
 On Wed, 11 Oct 2006, Sven Luther wrote:
  On Sat, Oct 07, 2006 at 06:52:41PM -0500, Debian Project Secretary wrote:
   - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
   c2d43675-9efa-4809-a4aa-af042b62786e
   [   ] Choice 1: Release Etch even with kernel firmware issues
  
  Manoj, you have again overstepped your Secretarial position, by
  issuing a misleading title for the proposal you propose.
 
 When Frederik accepted the proposed amendment, Manoj was no longer the
 proposer. Furthermore, the title of a voting option on the ballot is
 perfectly meaningless. Attempts by the secretary to make them

It may be meaningless, but i strongly believe it is misleading the voters if
the title is the opposite of what the proposal actually says.

And since Manoj hurried the vote out, while he knew there was further
discussion ongoing, because he didn't like other proposals which where being
proposed, i think he is at least coupable of manipulation, since most voters
will chose one or the other option, to get this issue out of the way and not
have to worry.

This is as strong a manipulation of the voting system as was done in the
syntactic change days, and if this one passes, i think we should find a new,
more neutral, secretary, who can be thrusted to not let his own personal
preferences over the votes being held, get in the way of his secretarial
duties.

 informative are appreciated, but any voter who actually pays any
 attention to them should be voting the null ballot, as they clearly
 haven't informed themselves appropriately.

Yeah, this is Manoj's defense, but the reality is elsewhere, because the
secretary is well respected, and helds a position thrusted by most voters.

 Finally, there's no reason to crosspost this stuff to multiple lists;
 complaints about the form of the ballot belong on -vote.

I believe that the debian-kernel should be informed, since most people there
will wake with a serious chock if this option passes, and it is contrary to
our express wishes, as stated in our statement of position on this issue, as
for the rest, i just did a group-reply.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Call for votes for GR: : Handling source-less firmware in the Linux kernel

[Manoj Srivastava]

On Tue, 10 Oct 2006 17:59:38 +0100 (BST), MJ Ray [EMAIL PROTECTED] said: 

 Manoj Srivastava [EMAIL PROTECTED] wrote:
 On Tue, 10 Oct 2006 10:43:03 +0100 (BST), MJ Ray
 [EMAIL PROTECTED] said:
  Frank =?iso-8859-1?Q?K=FCster?= [EMAIL PROTECTED] wrote:
  [...] And how about your offering him to proofread the ballot?
  Or just doing it, since he actually posted it in public for that
  very purpose?
 
  I thought it was posted so that everyone could see the Secretary
  had shown it to the Proposer and Seconders.
 
 Why on earth would I just show people stuff?

 Transparency.  If not for that or comment, why is it posted?

Pointing out errors, of course. Since the ballot is
 distributed on d-d-a, transparency resons seem nonsensical -- we
 publish ballots far and wide.  Commentary is useful, too, but this is
 not a debate starter.


  The most common response to other comments recently is suggesting
  that the commenter is too thick to vote.
 
 Commentary is one thing. Hysterical overreaction to the magnitude
 of the error is another.

 Quite.  Neither These instructions are self-contradictory nor
 name the amendment on the ballot are hysterical overreaction,
 whereas Does anyone themselves have had problems figuring out what
 this was all about and Rubish. You have tow overlapping
 constraints seem closer to hysterical: so keen to flame that
 spelling and grammar went out the window.

Jumping to conclusions as usual. The stutter in messages is
 due to the hotel network randomly dropping packets, to the point
 where typing is often painful.  However, don't let trying to discover
 facts get in your way.

Secondly, hectoring me does not solvce anything; I note that
 no one actually has done _anything_ to reduce the discombobulation;
 no one even mailed d-d-a, which is something I can't do without
 access to my keys.

No, it is much more fun to castigate the secretary about
 confusing voters rather than actually doing _anything_ to send a
 notice to the selfsame voters.

 Unlike LUGs, I've seldom seen thanks for any debian things I do.  In
 one way, that's OK - I do debian tasks for pragmatic reasons and
 I've only twice been offered small extra roles AFAICR - but it does
 suggest to me that something's rotten in the debian world.  I think
 more small teams, more egalitarianism and more openness are the way
 forwards, but that seems to be opposite of the current direction of
 travel - for now.

Actually, it might have something to do with your ability to
 be a team player.

 That works both ways.  People should stop treating fellow volunteers
 as faceless workers and use the power of their role to encourage
 them, rather than seeming to spend equivalent effort on discouraging
 them.  

Why on earth should I encourage behaviour that is merely
 obstructive rather than helping role players in doing their job? I
 have been mostly polite to people who pointed out my error, and
 mailed me privately, but the sky is falling emails and trelling me
 that they preferedd no mistakes being made in the fist place, thank
 you mails get my ire.

manoj
-- 
innovate, v.: To annoy people.
Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Call for votes for GR: : Handling source-less firmware in the Linux kernel

[MJ Ray]

Frank =?iso-8859-1?Q?K=FCster?= [EMAIL PROTECTED] wrote:
 [...] And how about
 your offering him to proofread the ballot?  Or just doing it, since he
 actually posted it in public for that very purpose?

I thought it was posted so that everyone could see the Secretary had
shown it to the Proposer and Seconders.

The most common response to other comments recently is suggesting
that the commenter is too thick to vote.

Shame!
-- 
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Call for votes for GR: : Handling source-less firmware in the Linux kernel

[Manoj Srivastava]

On Tue, 10 Oct 2006 10:43:03 +0100 (BST), MJ Ray [EMAIL PROTECTED] said: 

 Frank =?iso-8859-1?Q?K=FCster?= [EMAIL PROTECTED] wrote:
 [...] And how about your offering him to proofread the ballot?  Or
 just doing it, since he actually posted it in public for that very
 purpose?

 I thought it was posted so that everyone could see the Secretary had
 shown it to the Proposer and Seconders.

Why on earth would I just show people stuff?

 The most common response to other comments recently is suggesting
 that the commenter is too thick to vote.

Commentary is one thing. Hysterical overreaction to the
 magnitude of the error is another.  I think this phenomena stems from
 people no longer treating Debian as a fun project that a group of
 volunteers got together to do -- the paradigm has shifted to people
 wanting service. This might be a result of Debian growing too large
 and anonymous -- now people want services, and complain if the
 service does not meet their standards.

This is true also of other role aspects -- DAM, FTP-master,
 etc.  When you are expecting a service, you are the most important
 component -- your needs must be met. there is no room for erros on
 the part of the so called service provider. You know, the customer is
 always right.

 shame

Indeed.  People whould stop treating fellow volunteers as
 faceless workers, and realize that mistakes happen, and help work
 around them, rather than raising the roof about how the sky is
 falling.

manoj
-- 
Trust me.  I know what I'm doing. Sledge Hammer
Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Call for votes for GR: : Handling source-less firmware in the Linux kernel

[Ian Jackson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Debian Project Secretary writes (Call for votes for GR: : Handling 
source-less firmware in the Linux kernel):
 - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
 c2d43675-9efa-4809-a4aa-af042b62786e
 [ 1 ] Choice 1: Release Etch even with kernel firmware issues
 [ 3 ] Choice 2: Special exception to DFSG2 for firmware as long as required 
 [3:1]
 [ 2 ] Choice 3: Further discussion
 - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iQCVAwUBRSujoMMWjroj9a3bAQL4mQP/Vcx4F7sVJKws+hZovi6N7cWNGOuU5kbt
1UEXWkFjrHaX0ZDpUubQvvIn1eMWqF0Y8aUFLRstQxASRFobUaZ+eqwq+y6YFLlC
ARkvnBziF3p1J5prl4d64NzpXFvXR6zXCPVNXNabwaXhWTjKNMV/cGpHDdaYviML
IEGLlsrsbX4=
=cMyY
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Call for votes for GR: Re-affirm support to the Debian Project Leader

[Eduard Bloch]

#include hallo.h
* Debian Project Secretary [Sat, Oct 07 2006, 06:53:35PM]:
 - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
 a65763d3-b1e2-4530-8ff8-aa5915274eb4
 [ 2  ] Choice 1: Re-affirm DPL, wish success to unofficial Dunc Tank
 [ 1  ] Choice 2: Re-affirm DPL, do not endorse nor support his other projects
 [ 3  ] Choice 3: Further discussion
 - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-

-- 
zobel cat /dev/urandom  /dev/dsp
Ganneff zobel: das nennt sich metal
Ganneff oder techno, je nachdem


signature.asc
Description: Digital signature

Re: Call for votes for GR: : Handling source-less firmware in the Linux kernel

[Toni Mueller]

Hi,

On Sat, 07.10.2006 at 18:52:41 -0500, Debian Project Secretary [EMAIL 
PROTECTED] wrote:
 The details of the general resolution can be found at:
 http://www.debian.org/vote/vote_007

the correct link is probably

http://www.debian.org/vote/2006/vote_007

(note the '2006' part). I'd prefer to get correct links the first time
such an announcement is made. Thank you!

I didn't check any of the other GR announcements.


Best,
--Toni++



pgpv0iFfcwsTH.pgp
Description: PGP signature

Re: Call for votes for GR: Recall the project leader

[Lars Wirzenius]

On la, 2006-10-07 at 18:55 -0500, Debian Project Secretary wrote:
 - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
 49a98df6-2bd4-40c8-a559-7e15212dbd26
 [ 2 ] Choice 1: Recall the project leader
 [ 1 ] Choice 2: Further discussion
 - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-



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

Re: Call for votes for GR: Re-affirm support to the Debian Project Leader

[Manoj Srivastava]

On Mon, 9 Oct 2006 07:57:51 +0200, Matthias Urlichs [EMAIL PROTECTED] said: 

 Hi, Thomas Bushnell BSG:
  Okay... now what the hell should happen if these ballots both
  succeed?
 
 We would know that Debian developers are insane.  The ballots
 cannot both succeed unless sufficient people vote to Re-affirm the
 DPL *and* vote to recall him.

 That assertion holds only if everybody who votes does so on both
 ballots. Our quorum is less than 50 people -- thus, we could hold 20
 valid elections with entirely disjoint sets of participants, neither
 of whom would be insane by that metric.

 Doing those 20 elections would of course be somewhat insane, but the
 conceptual difference between 1 and 2 is larger than between 2 and
 20.  IMHO.

 Yes I know: it's still rather unlikely fo the votes to get that
 result, but that's not my point.

If the level of apathy has reached these hights, we have more
 problems than just this inconsistent resolution.

manoj
 yes, I know apathy is the current fad
-- 
You can't go home again, unless you set $HOME.
Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Call for votes for GR: : Handling source-less firmware in the Linux kernel

[Manoj Srivastava]

Hi,

I note that the same typo was on every draft ballot posted
 here, and no one else caught the typos in the draft ballots either.

manoj
-- 
Scintillation is not always identification for an auric substance.
Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Call for votes for GR: : Handling source-less firmware in the Linux kernel

[Manoj Srivastava]

On Mon, 9 Oct 2006 10:40:16 +0200, Toni Mueller [EMAIL PROTECTED] said: 

 Hi,

 On Sat, 07.10.2006 at 18:52:41 -0500, Debian Project Secretary [EMAIL 
 PROTECTED] wrote:
 The details of the general resolution can be found at:
 http://www.debian.org/vote/vote_007

 the correct link is probably

 http://www.debian.org/vote/2006/vote_007

 (note the '2006' part). I'd prefer to get correct links the first
 time such an announcement is made. Thank you!

And I would like world peace and an end to world hunger.

Typos happen. Deal with 'em. Anyone who can't get to the GR
 text on the vote.debian.org web page, the mailing list archives, or
 elsewhere probably should not be allowed to vote anyway.

manoj
-- 
He was so narrow-minded he could see through a keyhole with both eyes.
Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Call for votes for GR: : Handling source-less firmware in the Linux kernel

[Frank Küster]

Ben Pfaff [EMAIL PROTECTED] wrote:

 Debian Project Secretary [EMAIL PROTECTED] writes:

 In the brackets next to your preferred choice, place a 1. Place a 2 in
 the brackets next to your next choice.  Do not enter a number smaller
 than 1 or larger than 2.  You may skip numbers.  You may rank options
 equally (as long as all choices X you make fall in the range 1= X =
 3).

 These instructions are self-contradictory.

Come on, don't you guys have nothing more interesting to do than bashing
our secretary?  Not?  Okay, then please, as an entertaining exercise,
find out where this text is from, how it comes that it is
self-contradictory, and provide a fix for the script that does that.

Regards, Frank

-- 
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: Call for votes for GR: : Handling source-less firmware in the Linux kernel

[Manoj Srivastava]

On Mon, 09 Oct 2006 08:43:57 -0700, Ben Pfaff [EMAIL PROTECTED] said: 

 Debian Project Secretary [EMAIL PROTECTED] writes:
 In the brackets next to your preferred choice, place a 1. Place a 2
 in the brackets next to your next choice.  Do not enter a number
 smaller than 1 or larger than 2.  You may skip numbers.  You may
 rank options equally (as long as all choices X you make fall in the
 range 1= X = 3).

 These instructions are self-contradictory.  -- Ben Pfaff email:
 [EMAIL PROTECTED] web: http://benpfaff.org

Rubish. You have tow overlapping constraints. One constraint
 happens to be a superset of the other. There is not contradiction --
 get your nit-picking right, fer gaeds sake.

You can fully express all possible coices with just the
 numbers 1 and 2 for this vote, so the CFV isn't even wrong. I just
 overestimated the math and logic skillz of the voters.

manoj
-- 
[Crash programs] fail because they are based on the theory that, with
nine women pregnant, you can get a baby a month.  -- Wernher von Braun
Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Call for votes for GR: Re-affirm support to the Debian Project Leader

[Raul Miller]

On 10/7/06, Debian Project Secretary [EMAIL PROTECTED]  
Voting period starts  00:00:01 UTC on Sunday,

Votes must be received by 23:59:59 UTC on Saturday,


Fortunately, vote.debian.org provides the associated dates.

--
Raul


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Call for votes for GR: : Handling source-less firmware in the Linux kernel

[Jurij Smakov]

On Mon, Oct 09, 2006 at 04:33:42PM -0500, Manoj Srivastava wrote:
 On Mon, 09 Oct 2006 08:43:57 -0700, Ben Pfaff [EMAIL PROTECTED] said: 
 
  Debian Project Secretary [EMAIL PROTECTED] writes:
  In the brackets next to your preferred choice, place a 1. Place a 2
  in the brackets next to your next choice.  Do not enter a number
  smaller than 1 or larger than 2.  You may skip numbers.  You may
  rank options equally (as long as all choices X you make fall in the
  range 1= X = 3).
 
  These instructions are self-contradictory.  -- Ben Pfaff email:
  [EMAIL PROTECTED] web: http://benpfaff.org
 
 Rubish. You have tow overlapping constraints. One constraint
  happens to be a superset of the other. There is not contradiction --
  get your nit-picking right, fer gaeds sake.

Whatever you call it, it's your screw-up. And yes, this is a concern, 
because there are plenty of people participating in this vote, who 
might be confused by this, but reluctant to ask for clarifications due 
to language and/or culture barrier. If it's so unbearably painful 
for you to hear the criticism, perhaps you should do a better job of 
proof-reading the ballot (and your replies :-) next time.

-- 
Jurij Smakov   [EMAIL PROTECTED]
Key: http://www.wooyd.org/pgpkey/  KeyID: C99E03CC


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Call for votes for GR: : Handling source-less firmware in the Linux kernel

[Manoj Srivastava]

On Mon, 9 Oct 2006 19:54:00 -0700, Jurij Smakov [EMAIL PROTECTED] said: 

 On Mon, Oct 09, 2006 at 04:33:42PM -0500, Manoj Srivastava wrote:
 On Mon, 09 Oct 2006 08:43:57 -0700, Ben Pfaff [EMAIL PROTECTED]
 said:
 
  Debian Project Secretary [EMAIL PROTECTED] writes:
  In the brackets next to your preferred choice, place a 1. Place
  a 2 in the brackets next to your next choice.  Do not enter a
  number smaller than 1 or larger than 2.  You may skip numbers.
  You may rank options equally (as long as all choices X you make
  fall in the range 1= X = 3).
 
  These instructions are self-contradictory.  -- Ben Pfaff email:
  [EMAIL PROTECTED] web: http://benpfaff.org
 Rubish. You have tow overlapping constraints. One constraint
 happens to be a superset of the other. There is not contradiction
 -- get your nit-picking right, fer gaeds sake.

 Whatever you call it, it's your screw-up.

It was a mistake, true.  But the  restrictions are not in
 conflict -- they are just not identical. Any reasonable voter would
 know what to do.

 And yes, this is a concern, because there are plenty of people
 participating in this vote, who might be confused by this, but
 reluctant to ask for clarifications due to language and/or culture
 barrier.

If anyone is seriously confused by the discrepancy, they
  should not be voting in the first place.

 If it's so unbearably painful for you to hear the criticism, perhaps
 you should do a better job of proof-reading the ballot (and your
 replies :-) next time.

Fuck that. It is far more instructive finding out those who
 are logically challenged and whose input should be ignored in the
 future. 

manoj
see, even people in official roles in debian can be equally facetious
as people who are smart-ass about pointing out errors
-- 
If the future isn't what it used to be, does that mean that the past
is subject to change in times to come?
Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Call for votes for GR: Re-affirm support to the Debian Project Leader

[Manoj Srivastava]

Hi,
On Mon, 9 Oct 2006 18:21:03 -0400, Raul Miller [EMAIL PROTECTED] said: 

 On 10/7/06, Debian Project Secretary [EMAIL PROTECTED]  
 Voting period starts 00:00:01 UTC on Sunday,
 Votes must be received by 23:59:59 UTC on Saturday,

 Fortunately, vote.debian.org provides the associated dates.

AAaagh!

manoj

-- 
HEAD CRASH!!  FILES LOST!! Details at 11.
Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Call for votes for GR: : Handling source-less firmware in the Linux kernel

[Frank Küster]

Jurij Smakov [EMAIL PROTECTED] wrote:

 On Mon, Oct 09, 2006 at 04:33:42PM -0500, Manoj Srivastava wrote:
 On Mon, 09 Oct 2006 08:43:57 -0700, Ben Pfaff [EMAIL PROTECTED] said: 
 
  Debian Project Secretary [EMAIL PROTECTED] writes:
  In the brackets next to your preferred choice, place a 1. Place a 2
  in the brackets next to your next choice.  Do not enter a number
  smaller than 1 or larger than 2.  You may skip numbers.  You may
  rank options equally (as long as all choices X you make fall in the
  range 1= X = 3).
 
  These instructions are self-contradictory.  -- Ben Pfaff email:
  [EMAIL PROTECTED] web: http://benpfaff.org
 
 Rubish. You have tow overlapping constraints. One constraint
  happens to be a superset of the other. There is not contradiction --
  get your nit-picking right, fer gaeds sake.

 Whatever you call it, it's your screw-up. 

I don't even think there's anything seriously screwed.  And if there
were, the right thing to do would be to ask Manoj Please tell me where
I can download the script you use, so that I can fix it, instead of
blaming him.

 And yes, this is a concern, 
 because there are plenty of people participating in this vote, who 
 might be confused by this, but reluctant to ask for clarifications due 
 to language and/or culture barrier. 

Anyone who ist not able to figure out themselves what this means might
have a problem in their Debian work generally, since you can't expect
that everything is spelled out and proofread when you're dealing with
Debian packages.

Anyone who has a language and/or culture barrier to asking if they don't
understand something important, and/or at the same time is not able to
find the information in the constitution that is the source for this
paragraph, they will have a *severe* problem working in Debian.

 If it's so unbearably painful 
 for you to hear the criticism, perhaps you should do a better job of 
 proof-reading the ballot (and your replies :-) next time.

Given the (often unwarranted) criticism Manoj had to face in the last
couple of days, his reply wasn't really bad-tempered.  And how about
your offering him to proofread the ballot?  Or just doing it, since he
actually posted it in public for that very purpose?

Regards, Frank
-- 
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: Call for votes for GR: : Handling source-less firmware in the Linux kernel

[Don Armstrong]

On Sat, 07 Oct 2006, Debian Project Secretary wrote:
 Please note that the voting period is abridged, you only have
  one week to vote on this.

Just in case there was any question, I excercise the power delegated
to me in [EMAIL PROTECTED] to officially
abridge the voting period to one week, with adjustments to start and
end times at the secretary's convenience.


Don Armstrong

-- 
She was alot like starbucks.
IE, generic and expensive.
 -- hugh macleod http://www.gapingvoid.com/batch3.htm

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


signature.asc
Description: Digital signature

Re: Call for votes for GR: : Handling source-less firmware in the Linux kernel

[Peter Van Eynde]

On Sunday 08 October 2006 01:52, Debian Project Secretary wrote:
 
 - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
 c2d43675-9efa-4809-a4aa-af042b62786e
 [ 2 ] Choice 1: Release Etch even with kernel firmware issues
 [ 1 ] Choice 2: Special exception to DFSG2 for firmware as long as required 
 [3:1]
 [ 3 ] Choice 3: Further discussion
 - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Call for votes for GR: Recall the project leader

[Aurelien Jarno]

 - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
 49a98df6-2bd4-40c8-a559-7e15212dbd26
 [ 1 ] Choice 1: Recall the project leader
 [ 2 ] Choice 2: Further discussion
 - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-



-- 
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net


signature.asc
Description: Digital signature

Question (Re: Call for votes for GR: Re-affirm support to the Debian Project Leader)

[Jérôme Marant]

Le dimanche 08 octobre 2006 01:53, Debian Project Secretary a écrit :

 - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
 a65763d3-b1e2-4530-8ff8-aa5915274eb4
 [   ] Choice 1: Re-affirm DPL, wish success to unofficial Dunc Tank
 [   ] Choice 2: Re-affirm DPL, do not endorse nor support his other projects
 [   ] Choice 3: Further discussion
 - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-

Hi,

I'm unsure about how I should vote this.

Could someone please tell me how not supporting nor endorsing Dunc-Tank would
be incompatible with wishing it success?

I understand that Debian does not have to endorse it, but I don't think it means
wishing it failure, does it?

Thanks.

PS: please CC me

-- 
Jérôme Marant


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Call for votes for GR: Re-affirm support to the Debian Project Leader

[Matthias Urlichs]

On Sat, 07 Oct 2006 23:53:35 +, Debian Project Secretary wrote:

 [   ] Choice 1: Re-affirm DPL, wish success to unofficial Dunc Tank
 [   ] Choice 2: Re-affirm DPL, do not endorse nor support his other projects
and
 [   ] Choice 1: Recall the project leader

Okay... now what the hell should happen if these ballots both succeed?

IMHO those two should have been on one ballot.

-- 
Matthias Urlichs


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Question (Re: Call for votes for GR: Re-affirm support to the Debian Project Leader)

[Russ Allbery]

Jérôme Marant [EMAIL PROTECTED] writes:
 Le dimanche 08 octobre 2006 01:53, Debian Project Secretary a écrit :

 - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
 a65763d3-b1e2-4530-8ff8-aa5915274eb4
 [   ] Choice 1: Re-affirm DPL, wish success to unofficial Dunc Tank
 [   ] Choice 2: Re-affirm DPL, do not endorse nor support his other projects
 [   ] Choice 3: Further discussion
 - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-

 Hi,

 I'm unsure about how I should vote this.

 Could someone please tell me how not supporting nor endorsing Dunc-Tank
 would be incompatible with wishing it success?

 I understand that Debian does not have to endorse it, but I don't think
 it means wishing it failure, does it?

The above are just attempted summaries of the differences between two
position statements.  You really want to read the full statements
themselves and see if you agree more with one or the other (or with
neither).

In practice, I think either choice 1 or choice 2 is going to be
effectively the same in terms of its effect on the project; the real
choice is between one or the other means of saying we support AJ as DPL
or not saying that (choice 3).

I think it would have been somewhat clearer if it were all on the same
ballot as the recall, but I do understand the reasoning.

-- 
Russ Allbery ([EMAIL PROTECTED])   http://www.eyrie.org/~eagle/

Re: Question (Re: Call for votes for GR: Re-affirm support to the Debian Project Leader)

[Jérôme Marant]

Le dimanche 08 octobre 2006 20:23, Russ Allbery a écrit :

 The above are just attempted summaries of the differences between two
 position statements.  You really want to read the full statements
 themselves and see if you agree more with one or the other (or with
 neither).

Well, it does summarize pretty well:

1/ says the Debian Project does not object to the experiment and it is not
the result of a decision of the Debian Project

2/ says it doesn't endorse nor support any projects Mr Towns may lead or
participate in outside Debian

Pretty much the same. The only difference is that 1/ wishes success
to Dunc Tank, which makes Debian look nice with it.

 In practice, I think either choice 1 or choice 2 is going to be
 effectively the same in terms of its effect on the project; the real
 choice is between one or the other means of saying we support AJ as DPL
 or not saying that (choice 3).
 
 I think it would have been somewhat clearer if it were all on the same
 ballot as the recall, but I do understand the reasoning.

Agreed.

Thanks,

-- 
Jérôme Marant


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Call for votes for GR: Re-affirm support to the Debian Project Leader

[Thomas Bushnell BSG]

Matthias Urlichs [EMAIL PROTECTED] writes:

 On Sat, 07 Oct 2006 23:53:35 +, Debian Project Secretary wrote:

 [   ] Choice 1: Re-affirm DPL, wish success to unofficial Dunc Tank
 [   ] Choice 2: Re-affirm DPL, do not endorse nor support his other projects
 and
 [   ] Choice 1: Recall the project leader

 Okay... now what the hell should happen if these ballots both succeed?

We would know that Debian developers are insane.  The ballots cannot
both succeed unless sufficient people vote to Re-affirm the DPL *and*
vote to recall him.

Thomas


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Call for votes for GR: Re-affirm support to the Debian Project Leader

[Russ Allbery]

Thomas Bushnell BSG [EMAIL PROTECTED] writes:
 Matthias Urlichs [EMAIL PROTECTED] writes:

 Okay... now what the hell should happen if these ballots both succeed?

 We would know that Debian developers are insane.  The ballots cannot
 both succeed unless sufficient people vote to Re-affirm the DPL *and*
 vote to recall him.

You only hurt the ones you love.  :)

-- 
Russ Allbery ([EMAIL PROTECTED])   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Call for votes for GR: Re-affirm support to the Debian Project Leader

[Matthias Urlichs]

Hi,

Thomas Bushnell BSG:
  Okay... now what the hell should happen if these ballots both succeed?
 
 We would know that Debian developers are insane.  The ballots cannot
 both succeed unless sufficient people vote to Re-affirm the DPL *and*
 vote to recall him.

That assertion holds only if everybody who votes does so on both
ballots. Our quorum is less than 50 people -- thus, we could hold
20 valid elections with entirely disjoint sets of participants,
neither of whom would be insane by that metric.

Doing those 20 elections would of course be somewhat insane, but the
conceptual difference between 1 and 2 is larger than between 2 and 20.
IMHO.

Yes I know: it's still rather unlikely fo the votes to get that result,
but that's not my point.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [EMAIL PROTECTED]


signature.asc
Description: Digital signature

Re: Call for votes for GR: : Handling source-less firmware in the Linux kernel

[Stephen Gran]

This one time, at band camp, Debian Project Secretary said:
 The details of the general resolution can be found at:
 http://www.debian.org/vote/vote_007

Or not:
[EMAIL PROTECTED]:~$ curl -I http://www.debian.org/vote/vote_007
HTTP/1.0 404 Not Found
Date: Sun, 08 Oct 2006 00:17:23 GMT
Server: Apache/2.0.54 (Debian GNU/Linux)
Content-Length: 211
Content-Type: text/html; charset=iso-8859-1
Age: 105
X-Cache: HIT from hadrian.lobefin.net
X-Cache-Lookup: HIT from hadrian.lobefin.net:3128
Connection: close
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: Call for votes for GR: Re-affirm support to the Debian Project Leader

[Kevin Rosenberg]

Debian Project Secretary wrote:
 - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
 a65763d3-b1e2-4530-8ff8-aa5915274eb4
 [ 2 ] Choice 1: Re-affirm DPL, wish success to unofficial Dunc Tank
 [ 1 ] Choice 2: Re-affirm DPL, do not endorse nor support his other projects
 [ 3 ] Choice 3: Further discussion
 - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-


signature.asc
Description: Digital signature

Re: Call for votes (Was: kernel firmwares: GR proposal)

[Sven Luther]

On Thu, Sep 28, 2006 at 05:02:13PM +0200, Frederik Schueler wrote:
 Hi,
 
 On Wed, Sep 27, 2006 at 06:40:41PM +0200, Kurt Roeckx wrote:
   2. We acknowledge that there is a lot of progress in the kernel firmware
   issue; however, it is not yet finally sorted out;
  
  So, what progress has been made?
 
 For example:
 
 - the firmware_class infrastructure has been added in more than 100 
   drivers (as of 2.6.17)
 
 - the qla2xxx firmware has been dropped from the kernel sources, and is
   now shiped on ftp.qlogic.com
 
 - new drivers for devices requiring a firmware to be uploaded during
   initialization are included without embedded firmware (for example the
   ipw3945 driver, or aic94xx which has just been added in 2.6.19-rc)

Broadcom and qlogic where approached from the legalese angle, to clarify their
implicit-GPL-but-no-source licence over firmware, which made those firmwares
undistributable. Everyone laughed at us over this, even upstream, but we got
a serious and interested response from the vendors, and after longish
discussions they provided new clarified licence. We intent to do more of this
later on, but with the pressure of the release out of the way, and it is stuff
that cannot be rushed upstream.

Also, we prefer to concentrate for now on technical issues, using our DD time
to make sure etch's kernel are as bug free as possible, and solving tedious
licencing issues is secondary at best.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Call for votes (Was: kernel firmwares: GR proposal)

[Kurt Roeckx]

On Thu, Sep 28, 2006 at 05:02:13PM +0200, Frederik Schueler wrote:
 Hi,
 
 On Wed, Sep 27, 2006 at 06:40:41PM +0200, Kurt Roeckx wrote:
   2. We acknowledge that there is a lot of progress in the kernel firmware
   issue; however, it is not yet finally sorted out;
  
  So, what progress has been made?
 
 For example:
 
 - the firmware_class infrastructure has been added in more than 100 
   drivers (as of 2.6.17)

So, does that mean that the firmware for those devices isn't part of the
kernel source, but lives in non-free somewhere?  Or what exactly does
this mean?

 - the qla2xxx firmware has been dropped from the kernel sources, and is
   now shiped on ftp.qlogic.com
 
 - new drivers for devices requiring a firmware to be uploaded during
   initialization are included without embedded firmware (for example the
   ipw3945 driver, or aic94xx which has just been added in 2.6.19-rc)

So those drivers should go to non-free?


Kurt


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Call for votes (Was: kernel firmwares: GR proposal)

[Sven Luther]

On Wed, Sep 27, 2006 at 04:56:40PM +, Sune Vuorela wrote:
 On 2006-09-27, Kurt Roeckx [EMAIL PROTECTED] wrote:
  On Wed, Sep 27, 2006 at 11:36:37AM +0200, Frederik Schueler wrote:
  2. We acknowledge that there is a lot of progress in the kernel firmware
  issue; however, it is not yet finally sorted out;
 
  So, what progress has been made?
 
 All firmwarez have been readded to the debian package.

But with this amendment, they will have to go again anyway, so ...

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Call for votes (Was: kernel firmwares: GR proposal)

[Steve Langasek]

On Thu, Sep 28, 2006 at 11:48:49AM +0200, Sven Luther wrote:
 On Wed, Sep 27, 2006 at 04:56:40PM +, Sune Vuorela wrote:
  On 2006-09-27, Kurt Roeckx [EMAIL PROTECTED] wrote:
   On Wed, Sep 27, 2006 at 11:36:37AM +0200, Frederik Schueler wrote:
   2. We acknowledge that there is a lot of progress in the kernel firmware
   issue; however, it is not yet finally sorted out;

   So, what progress has been made?

  All firmwarez have been readded to the debian package.

 But with this amendment, they will have to go again anyway, so ...

As we've discussed on IRC, 4 of the 6 firmware blobs reintroduced in 2.6.18
apparently have no license statement whatsoever that is intended to permit
us to redistribute them, *even* in non-free.  So they should go away
regardless of the kind of exception the project grants for etch.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Call for votes (Was: kernel firmwares: GR proposal)

[Frederik Schueler]

Hi,

On Wed, Sep 27, 2006 at 06:40:41PM +0200, Kurt Roeckx wrote:
  2. We acknowledge that there is a lot of progress in the kernel firmware
  issue; however, it is not yet finally sorted out;
 
 So, what progress has been made?

For example:

- the firmware_class infrastructure has been added in more than 100 
  drivers (as of 2.6.17)

- the qla2xxx firmware has been dropped from the kernel sources, and is
  now shiped on ftp.qlogic.com

- new drivers for devices requiring a firmware to be uploaded during
  initialization are included without embedded firmware (for example the
  ipw3945 driver, or aic94xx which has just been added in 2.6.19-rc)


Best regards
Frederik Schueler

-- 
ENOSIG


signature.asc
Description: Digital signature

Re: Call for votes

[Sven Luther]

On Tue, Sep 26, 2006 at 10:19:40PM -0500, Manoj Srivastava wrote:
 On Tue, 26 Sep 2006 16:02:11 -0700, Steve Langasek [EMAIL PROTECTED] said: 
 
  On Tue, Sep 26, 2006 at 10:41:24AM +0200, Sven Luther wrote:
 
  As I mentioned previously, I don't think point 3. here is the
  compromise I would like to see.  Without further conditions is so
  broad that it seems to even *require* us to include firmware in main
  that lacks any sort of proper distribution license.  And indeed, the
  upload of a completely unpruned 2.6.18 package to unstable suggests
  that this is not an accident of wording, but the actual view of the
  present kernel team.
 
  If this option appears on a ballot alone, I am likely to vote
  further discussion on it and encourage others to do so as well.  I
  don't want this GR to be a *mandate* that the release team allow
  firmware under clearly non-free licenses into main for etch.
 
 Why not amend the proposal, then?
 
 This is a formal proposal to amend Frederik's proposak, and
  replace the third clause as below (only the third clause is changed,
  and the only change is to ensure we have the right to distribute the
  software in question).  I am asking Frederik to accept this
  amendment, failing which, I am also seeking formal seconds for this.

Two questions here.

First, this means that this proposal needs seconds, right ? Or can Frederik
just incorporate it into his proposal ?

 ,
 |   1. We affirm that our Priorities are our users and the free software
 |  community (Social Contract #4);
 |   2. We acknowledge that there is a lot of progress in the kernel
 |  firmware issue; however, it is not yet finally sorted out; 
 |   3. We give priority to the timely release of Etch over sorting every
 |  bit out; for this reason, we will treat removal of sourceless
 |  firmware as a best-effort process, and deliver firmware in udebs as
 |  long as it is necessary for installation (like all udebs), and
 |  firmware included in the kernel itself as part of Debian Etch,
 |  as long as we are legally allowed to do so, and the formware is
 |  distributed under a DFSG free license. 
 `

I will let Frederik comment, but this ammendment is a total reversal of the
proposition, doesn't allow for a timely release of etch, so contradicts
itself, and is just the status quo anyway. I seriously doubt that this is what
Steve wants, but i don't really know what steve wants.

Steve, what is it you really want to happen, so we can then draft words which
fullfill the spirit of what you want, and which you will be able to second.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Call for votes

[Frank Küster]

Manoj Srivastava [EMAIL PROTECTED] wrote:

 I am asking Frederik to accept this
  amendment, failing which, I am also seeking formal seconds for this.

I would prefer that Frederik accept it, but in case he doesn't, I second
this proposal:

 ,
 |   1. We affirm that our Priorities are our users and the free software
 |  community (Social Contract #4);
 |   2. We acknowledge that there is a lot of progress in the kernel
 |  firmware issue; however, it is not yet finally sorted out; 
 |   3. We give priority to the timely release of Etch over sorting every
 |  bit out; for this reason, we will treat removal of sourceless
 |  firmware as a best-effort process, and deliver firmware in udebs as
 |  long as it is necessary for installation (like all udebs), and
 |  firmware included in the kernel itself as part of Debian Etch,
 |  as long as we are legally allowed to do so, and the formware is
 |  distributed under a DFSG free license. 
 `

without or, better, with the editorial changes ;-) suggested by Aníbal.

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)


pgpLbR628p8ye.pgp
Description: PGP signature

Re: Call for votes

[Sven Luther]

On Wed, Sep 27, 2006 at 08:45:14AM +0200, Frank Küster wrote:
 Manoj Srivastava [EMAIL PROTECTED] wrote:
 
  I am asking Frederik to accept this
   amendment, failing which, I am also seeking formal seconds for this.
 
 I would prefer that Frederik accept it, but in case he doesn't, I second
 this proposal:

There is little doubt that Fredrik will not accept it, since it says all the
contrary to what the intention was, and makes for a useless GR.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Call for votes

[Frederik Schueler]

Hello,

On Tue, Sep 26, 2006 at 10:19:40PM -0500, Manoj Srivastava wrote:
 ,
 |   1. We affirm that our Priorities are our users and the free software
 |  community (Social Contract #4);
 |   2. We acknowledge that there is a lot of progress in the kernel
 |  firmware issue; however, it is not yet finally sorted out; 
 |   3. We give priority to the timely release of Etch over sorting every
 |  bit out; for this reason, we will treat removal of sourceless
 |  firmware as a best-effort process, and deliver firmware in udebs as
 |  long as it is necessary for installation (like all udebs), and
 |  firmware included in the kernel itself as part of Debian Etch,
 |  as long as we are legally allowed to do so, and the formware is
 |  distributed under a DFSG free license. 
 `

I oppose such a change.

this means we actually have to review all licenses before the release,
and completely contradicts the original intention of this GR.

If such a resolution was passed, the kernel team would either be forced 
to remove all badly licensed firmwares, even those required for 
installation, or we had to delay Etch until an appropriate infrastructure 
is implemented in all the installer, the kernel package and the non-free
firmware package.


Best regards
Frederik Schueler

-- 
ENOSIG


signature.asc
Description: Digital signature

Re: Call for votes (Was: kernel firmwares: GR proposal)

[Frederik Schueler]

Hello,

On Tue, Sep 26, 2006 at 04:02:11PM -0700, Steve Langasek wrote:
 As I mentioned previously, I don't think point 3. here is the compromise I
 would like to see.  Without further conditions is so broad that it seems
 to even *require* us to include firmware in main that lacks any sort of
 proper distribution license.

The intention is indeed to release the kernel as-is for Etch, postponing
the work which needs to be done in contacting vendors and upstream to
get relicensings and source disclosures until after the release. 

 And indeed, the upload of a completely
 unpruned 2.6.18 package to unstable suggests that this is not an accident of
 wording, but the actual view of the present kernel team.

It is at least my actual view, the others should speak for themself. 

We will discuss this issue on the kernel-team meeting next Saturday, how we 
should handle the re-added firmwares, and seek a workable compromise.

Dropping for example the apparently useless dgrs driver could be an 
option, or drop the drivers not needed for installation, which means
basically one driver (acenic) from the originally pruned ones would be
the non-free regression in comparison with the sarge kernels. 

But this should be decided by the whole kernel team. 


Best regards
Frederik Schueler

-- 
ENOSIG


signature.asc
Description: Digital signature

Re: Call for votes

[Sven Luther]

On Wed, Sep 27, 2006 at 02:06:50AM -0700, Steve Langasek wrote:
 On Wed, Sep 27, 2006 at 08:21:21AM +0200, Sven Luther wrote:
  Two questions here.
 
  First, this means that this proposal needs seconds, right ? Or can Frederik
  just incorporate it into his proposal ?
 
 Frederik does have the option of incorporating it into his proposal, in
 which case all of the sponsors have the choice of renewing their second for
 the changed resolution, or rejecting the change and becoming the new
 proposer of Frederik's original resolution.
 
   ,
   |   1. We affirm that our Priorities are our users and the free software
   |  community (Social Contract #4);
   |   2. We acknowledge that there is a lot of progress in the kernel
   |  firmware issue; however, it is not yet finally sorted out; 
   |   3. We give priority to the timely release of Etch over sorting every
   |  bit out; for this reason, we will treat removal of sourceless
   |  firmware as a best-effort process, and deliver firmware in udebs as
   |  long as it is necessary for installation (like all udebs), and
   |  firmware included in the kernel itself as part of Debian Etch,
   |  as long as we are legally allowed to do so, and the formware is
   |  distributed under a DFSG free license. 
   `
 
  I will let Frederik comment, but this ammendment is a total reversal of the
  proposition, doesn't allow for a timely release of etch, so contradicts
  itself, and is just the status quo anyway.
 
 What are you claiming is the status quo -- that we're not legally allowed to
 distribute the firmware in question, or that it's not made available under a
 DFSG-compliant license?

both.

The above say we have legally the right to distribute those firmwares, and
that it should be DFSG free to be in main, which is what the current social
contract sayus.

 If they're illegal to distribute, the project can pass GRs until they're
 collectively blue in the face, and it won't matter to me -- I'm not going to
 give my ok as RM to releasing something that I *know* is a violation of
 someone's copyright.

Even if that someone is lost in space like in the acenic case, or if it is a
manifest error on the licencing ? Like it is most probably for all the
imlpicit GPLEd firmwares, and was solved with qlogic and broadcom last fall.

 If you think that the firmware at issue is not distributed under a
 DFSG-compliant *license*, then you and I seem to be looking at different
 firmware.  Of the binary firmware that Larry Doolittle has identified as
 still included in the Debian kernel (as of 2.6.17), only three drivers use
 blobs that don't have a DFSG-compliant license: an appletalk driver, a token
 ring driver, and a USB audio driver.

Yes, and our intention is to not remove them for etch, since world+dog also
distributes it, and to work for etch+1 on solving all these issues.

 So if we trust for the moment that everyone involved is acting in good faith
 and the GPL blobs are intended to be distributable and modifiable even
 though they don't include source, a simple sourceless firmware is ok for
 main exemption gives us 100% coverage of the firmware that matters to the

No, that is not the case, the most probable case is that those firmwares are
under GPL by error, and they will become non-free in the future. In any case,
those are non-distributable.

 installer, and 85% coverage of *all* the redistributable binary firmware in
 the kernel packages today, including those readded in 2.6.18.  That leaves
 only 15% of the firmware that the kernel team would have to decide how
 to support for etch, and that includes those drivers that were *already*
 dropped before sarge's release and just now readded.

Like said, there are 5 or so firmware thus concerned.

 And if 2 1/2 months isn't long enough to solve just the kernel question of
 how to package and distribute these drivers/firmware when we know they
 aren't needed by the installer, then I can expect you to be suitably ashamed
 of having blamed the debian-installer team for all the delays, right?

Err, it is less than 2 and a half month now, and the kernel will need to be
frozen for the d-i test cycle well before that.

 Then again, I guess the difference between sourceless and non-free is
 just words, and I shouldn't expect you to pay any attention to me until I
 start drawing Venn diagrams for you.

a sourceless firmware is considered non-free as per the DFSG, so i really
don't understand the folk who insist on using the sourceless term instead of
the non-free one. Please reread the DFSG.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Call for votes (Was: kernel firmwares: GR proposal)

[Sven Luther]

On Wed, Sep 27, 2006 at 11:36:37AM +0200, Frederik Schueler wrote:
 Hello,
 
 On Tue, Sep 26, 2006 at 04:02:11PM -0700, Steve Langasek wrote:
  As I mentioned previously, I don't think point 3. here is the compromise I
  would like to see.  Without further conditions is so broad that it seems
  to even *require* us to include firmware in main that lacks any sort of
  proper distribution license.
 
 The intention is indeed to release the kernel as-is for Etch, postponing
 the work which needs to be done in contacting vendors and upstream to
 get relicensings and source disclosures until after the release. 
 
  And indeed, the upload of a completely
  unpruned 2.6.18 package to unstable suggests that this is not an accident of
  wording, but the actual view of the present kernel team.
 
 It is at least my actual view, the others should speak for themself. 
 
 We will discuss this issue on the kernel-team meeting next Saturday, how we 
 should handle the re-added firmwares, and seek a workable compromise.
 
 Dropping for example the apparently useless dgrs driver could be an 
 option, or drop the drivers not needed for installation, which means
 basically one driver (acenic) from the originally pruned ones would be
 the non-free regression in comparison with the sarge kernels. 

That said, it seems that the acenic sources are available somewhere, as they
are mentioned on the wiki page. Maybe we should get hand on them.

The only problem is with the licence (can only be used with the acenic
driver), which makes them non-free, but as the copyright holder kind of
dissapeared there is not much we can do about this.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Call for votes

[Sven Luther]

On Wed, Sep 27, 2006 at 12:39:57PM +0200, Frank Küster wrote:
 Sven Luther [EMAIL PROTECTED] wrote:
 
  On Wed, Sep 27, 2006 at 08:45:14AM +0200, Frank Küster wrote:
  Manoj Srivastava [EMAIL PROTECTED] wrote:
  
   I am asking Frederik to accept this
amendment, failing which, I am also seeking formal seconds for this.
  
  I would prefer that Frederik accept it, but in case he doesn't, I second
  this proposal:
 
  There is little doubt that Fredrik will not accept it, since it says all the
  contrary to what the intention was, and makes for a useless GR.
 
 As I understand it, the proposal said distributed under a DFSG free
 license and meant that it has such a license statement, not that we are
 actually able to fulfill all requirements (like providing source).  If
 this is ambiguous, maybe it should be worded better.

Maybe.

 I also assumed that my perception is correct that most of the drivers
 actually have such a license statement.  However, I have read in your
 other post that you believe most of them are erroneously under GPL.

Indeed. Copyright holder just added the binary blob, and released the whole
driver as GPL, thus implicitly putting these drivers under the GPL. They did
so in ignorance, and don't intent to give the source code for those licences.
When approached, they simply relicenced the driver under a non-free licence
(well sourceless BSD is probably non-free under the DFSG, i wonder what
sourceless DFSG is anyway, i feel that the BSD is a source licence, not a
binary one).

 All that is very confusing.  Maybe I should revoke my seconding, and
 instead wait whether the meeting on the weekend will bring us a
 consensus proposal.

I think so, but given the strange and changing statement of Steve, i hope we
will be able to find a common ground then.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Re: Call for votes

[BALLABIO GERARDO]

Frederik Schueler wrote:
 this means we actually have to review all licenses before the release,

Indeed, I have been under the impression that *every* maintainer must
*always* check that *all* the files they are packaging are properly
licensed and distributable by Debian. I must have been wrong?

Gerardo

Re: Re: Call for votes

[BALLABIO GERARDO]

Manoj Srivastava wrote:
 |  as long as we are legally allowed to do so, and the formware is
 |  distributed under a DFSG free license.

This needs to be made clearer.

I assume that your intention is to say GPL'd (or otherwise DFSG-free
licensed) firmware without source is allowed, but everything else is
not. But, as I understand it, the point a lot of people are arguing
about is exactly *whether* GPL'd firmware without source *is* actually
distributable. Your resolution doesn't answer this question. One may
claim that this clause actually *forbids* GPL'd firmware without source
because we are *not* legally allowed to distribute it.

Gerardo

Re: Call for votes

[Pierre Habouzit]

Le mer 27 septembre 2006 14:16, BALLABIO GERARDO a écrit :
 Manoj Srivastava wrote:
  |  as long as we are legally allowed to do so, and the formware
  | is distributed under a DFSG free license.

 This needs to be made clearer.

 I assume that your intention is to say GPL'd (or otherwise DFSG-free
 licensed) firmware without source is allowed, but everything else is
 not. But, as I understand it, the point a lot of people are arguing
 about is exactly *whether* GPL'd firmware without source *is*
 actually distributable. Your resolution doesn't answer this question.
 One may claim that this clause actually *forbids* GPL'd firmware
 without source because we are *not* legally allowed to distribute it.

which mail are you answering to ?

It seems that your MUA does use neither In-Reply-To: nor References: 
headers. That breaks threads and makes a lot of noise. Please change 
your MUA (or MTA? as it seems that's because your mail goes through 
Exchange), or stop posting here. That makes your mails especially 
painful for the readers.
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpdHqg7O8XEc.pgp
Description: PGP signature

Re: Re: Call for votes

[BALLABIO GERARDO]

Pierre Habouzit wrote:
 It seems that your MUA does use neither In-Reply-To: nor References: 
 headers. That breaks threads and makes a lot of noise. Please change 
 your MUA (or MTA? as it seems that's because your mail goes through 
 Exchange), or stop posting here. That makes your mails especially 
 painful for the readers.

Raphael Hertzog wrote:
 Can you please *not* contribute until you're able to reply with a
mailer
 that implements properly threading (ie that creates the In-Reply-To:
 and/or References field)?

 Each time you answer, you create a new thread which makes reading the
list
 more difficult that is really needed.

Umm, this seems the fastest way to get some attention here ;-)

Sorry for the noise. I've posted several replies recently and they all
got threaded correctly, I don't know what happened to the last two. I
hope this one gets it right, otherwise I'll stop posting. For the
record, yes I'm going through exchange, I'm writing from my work place
and can't choose what to use.

Gerardo

Re: Call for votes (Was: kernel firmwares: GR proposal)

[Kurt Roeckx]

On Wed, Sep 27, 2006 at 11:36:37AM +0200, Frederik Schueler wrote:
 Hello,
 
 On Tue, Sep 26, 2006 at 04:02:11PM -0700, Steve Langasek wrote:
  As I mentioned previously, I don't think point 3. here is the compromise I
  would like to see.  Without further conditions is so broad that it seems
  to even *require* us to include firmware in main that lacks any sort of
  proper distribution license.
 
 The intention is indeed to release the kernel as-is for Etch, postponing
 the work which needs to be done in contacting vendors and upstream to
 get relicensings and source disclosures until after the release. 
 
  And indeed, the upload of a completely
  unpruned 2.6.18 package to unstable suggests that this is not an accident of
  wording, but the actual view of the present kernel team.
 
 It is at least my actual view, the others should speak for themself. 

From your proposol:

 2. We acknowledge that there is a lot of progress in the kernel firmware
 issue; however, it is not yet finally sorted out;

So, what progress has been made?


Kurt


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Call for votes (Was: kernel firmwares: GR proposal)

[Sune Vuorela]

On 2006-09-27, Kurt Roeckx [EMAIL PROTECTED] wrote:
 On Wed, Sep 27, 2006 at 11:36:37AM +0200, Frederik Schueler wrote:
 2. We acknowledge that there is a lot of progress in the kernel firmware
 issue; however, it is not yet finally sorted out;

 So, what progress has been made?

All firmwarez have been readded to the debian package.

/Sune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Call for votes (Was: kernel firmwares: GR proposal)

[Sven Luther]

On Tue, Sep 26, 2006 at 10:41:24AM +0200, Sven Luther wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Hello, 
 
 As seconder of the below proposal, which has reached enough seconds since
 august 31, and as there where no ammendments against this proposal, i now
 officially call for a vote, as per section A.2 of our constitution.
 
 ===
 1. We affirm that our Priorities are our users and the free software
 community (Social Contract #4);
 2. We acknowledge that there is a lot of progress in the kernel firmware
 issue; however, it is not yet finally sorted out;
 3. We give priority to the timely release of Etch over sorting every bit
 out; for this reason, we will deliver firmware in udebs as long as it is
 necessary for installation (like all udebs), and firmware included in
 the kernel itself as part of Debian Etch, without further conditions.
 ===
 
 As per section A.2.3, i should also propose a ballot, and i believe that the
 ballot should be of the form :
 
   [ ] Include non-free kernel firmware in etch (this proposal).
   [ ] Further discussion.
 
 Friendly,
 
 Sven Luther

Due to a request for a delay, and in light of the upcoming proposal which will
follow the debian/kernel irc meeting on saturday, i will hold this call for
vote until next monday.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Call for votes (Was: kernel firmwares: GR proposal)

[Steve Langasek]

On Tue, Sep 26, 2006 at 10:41:24AM +0200, Sven Luther wrote:

 As seconder of the below proposal, which has reached enough seconds since
 august 31, and as there where no ammendments against this proposal, i now
 officially call for a vote, as per section A.2 of our constitution.

 ===
 1. We affirm that our Priorities are our users and the free software
 community (Social Contract #4);
 2. We acknowledge that there is a lot of progress in the kernel firmware
 issue; however, it is not yet finally sorted out;
 3. We give priority to the timely release of Etch over sorting every bit
 out; for this reason, we will deliver firmware in udebs as long as it is
 necessary for installation (like all udebs), and firmware included in
 the kernel itself as part of Debian Etch, without further conditions.
 ===

 As per section A.2.3, i should also propose a ballot, and i believe that the
 ballot should be of the form :

   [ ] Include non-free kernel firmware in etch (this proposal).
   [ ] Further discussion.

As I mentioned previously, I don't think point 3. here is the compromise I
would like to see.  Without further conditions is so broad that it seems
to even *require* us to include firmware in main that lacks any sort of
proper distribution license.  And indeed, the upload of a completely
unpruned 2.6.18 package to unstable suggests that this is not an accident of
wording, but the actual view of the present kernel team.

If this option appears on a ballot alone, I am likely to vote further
discussion on it and encourage others to do so as well.  I don't want this
GR to be a *mandate* that the release team allow firmware under clearly
non-free licenses into main for etch.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Call for votes

[Manoj Srivastava]

On Tue, 26 Sep 2006 16:02:11 -0700, Steve Langasek [EMAIL PROTECTED] said: 

 On Tue, Sep 26, 2006 at 10:41:24AM +0200, Sven Luther wrote:

 As I mentioned previously, I don't think point 3. here is the
 compromise I would like to see.  Without further conditions is so
 broad that it seems to even *require* us to include firmware in main
 that lacks any sort of proper distribution license.  And indeed, the
 upload of a completely unpruned 2.6.18 package to unstable suggests
 that this is not an accident of wording, but the actual view of the
 present kernel team.

 If this option appears on a ballot alone, I am likely to vote
 further discussion on it and encourage others to do so as well.  I
 don't want this GR to be a *mandate* that the release team allow
 firmware under clearly non-free licenses into main for etch.

Why not amend the proposal, then?

This is a formal proposal to amend Frederik's proposak, and
 replace the third clause as below (only the third clause is changed,
 and the only change is to ensure we have the right to distribute the
 software in question).  I am asking Frederik to accept this
 amendment, failing which, I am also seeking formal seconds for this.




pgpnhBB11tlJM.pgp
Description: PGP signature
,
|   1. We affirm that our Priorities are our users and the free software
|  community (Social Contract #4);
|   2. We acknowledge that there is a lot of progress in the kernel
|  firmware issue; however, it is not yet finally sorted out; 
|   3. We give priority to the timely release of Etch over sorting every
|  bit out; for this reason, we will treat removal of sourceless
|  firmware as a best-effort process, and deliver firmware in udebs as
|  long as it is necessary for installation (like all udebs), and
|  firmware included in the kernel itself as part of Debian Etch,
|  as long as we are legally allowed to do so, and the formware is
|  distributed under a DFSG free license. 
`

manoj
-- 
He who drinks in the Truth will live happily with a peaceful mind. A
wise man always delights in the Truth taught by the saints. 79
Manoj Srivastava   [EMAIL PROTECTED]  http://www.debian.org/%7Esrivasta/
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


pgpgwMlf8UWKH.pgp
Description: PGP signature

Re: Call for votes

[Aníbal Monsalve Salazar]

On Tue, Sep 26, 2006 at 10:19:40PM -0500, Manoj Srivastava wrote:
,
|   1. We affirm that our Priorities are our users and the free software
|  community (Social Contract #4);
|   2. We acknowledge that there is a lot of progress in the kernel
|  firmware issue; however, it is not yet finally sorted out; 
|   3. We give priority to the timely release of Etch over sorting every
|  bit out; for this reason, we will treat removal of sourceless
|  firmware as a best-effort process, and deliver firmware in udebs as
|  long as it is necessary for installation (like all udebs), and
|  firmware included in the kernel itself as part of Debian Etch,
|  as long as we are legally allowed to do so, and the formware is
|  distributed under a DFSG free license. 
`

Minor typo:
s/formware/firmware/

Seconded with corrected typo or as it is.

Aníbal Monsalve Salazar
-- 
http://v7w.com/anibal


signature.asc
Description: Digital signature

Re: Call for votes

[Aníbal Monsalve Salazar]

On Wed, Sep 27, 2006 at 02:12:29PM +1000, Anibal Monsalve Salazar wrote:
On Tue, Sep 26, 2006 at 10:19:40PM -0500, Manoj Srivastava wrote:
,
|   1. We affirm that our Priorities are our users and the free software
|  community (Social Contract #4);
|   2. We acknowledge that there is a lot of progress in the kernel
|  firmware issue; however, it is not yet finally sorted out; 
|   3. We give priority to the timely release of Etch over sorting every
|  bit out; for this reason, we will treat removal of sourceless
|  firmware as a best-effort process, and deliver firmware in udebs as
|  long as it is necessary for installation (like all udebs), and
|  firmware included in the kernel itself as part of Debian Etch,
|  as long as we are legally allowed to do so, and the formware is
|  distributed under a DFSG free license. 
`

Minor typo:
s/formware/firmware/

Also, instead of a DFSG free license I would prefer a DFSG
compliant license as DFSG already implies free.

Seconded with corrected typo or as it is.

Aníbal Monsalve Salazar
-- 
http://v7w.com/anibal


signature.asc
Description: Digital signature