FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 11-15-2008, 02:45 PM
Debian Project Secretary
 
Default call for seconds: on firmware

Hi,

This is how things stand:
The Situation: We are close to releasing Lenny
The Problem: The kernels we are shipping have blobs that might not meet
the DFSG, and some might be in violation of the kernel's
GPL license. This would put them in conflict with the SC.

The proposed solutions below all try to address the basic issue
of releasing while meeting the promises made in the SC. A new proposal
has been seconded, which extends the minimum discussion period by a
week (I think the relevant second came in at 14 Nov 2008 22:53:07).

If the proposers do not submit the wml that should go up as the
vote page, I'll make up the wording for the vote web page.

Here is the handy seconds registry. I hope I have recorded all
seconds, and recorded their sponsorship correctly, please let me know
if I have missed anything. (I have also simplified the summation
formula below)
|----------------------------------------------------+---+---+---+---+----+----|
| | 1 | 2 | 3 | 4 | 5 | 6 |
|----------------------------------------------------+---+---+---+---+----+----|
| Robert Millan <rmh@aybabtu.com> | 1 | 1 | 1 | | 1 | |
| Bas Wijnen <wijnen@debian.org> | 1 | | | | | |
| Manoj Srivastava <srivasta@debian.org> | 1 | 1 | | | 1 | |
| Holger Levsen <holger@layer-acht.org> | 1 | 1 | 1 | 1 | | 1 |
| Peter Samuelson <peter@p12n.org> | 1 | 1 | 1 | | | |
| Hubert Chathi <uhoreg@debian.org | 1 | 1 | 1 | | | |
| Andreas Barth <aba@not.so.argh.org> | | | | 1 | | |
| Alexander Reichle-Schmehl <alexander@schmehl.info> | | | | 1 | | 1 |
| Reinhard Tartler <siretart@debian.org> | | | | 1 | | |
| Bernd Zeimetz <bernd@bzed.de> | | | | 1 | 1 | 1 |
| Neil McGovern <neilm@debian.org> | | | | 1 | 1 | |
| Frans Pop <elendil@planet.nl> | | 1 | 1 | | | 1 |
| vanicat@debian.org (Rémi Vanicat) | 1 | 1 | 1 | 1 | | |
| "John H. Robinson, IV" <jaqque@debian.org> | | | | | 1 | |
| Lars Wirzenius <liw@liw.fi> | | | | | 1 | |
| Damyan Ivanov <dmn@debian.org> | | | | | 1 | |
| Colin Tuckley <colin@tuckley.org> | | | | | 1 | 1 |
| Pierre Habouzit <madcoder@debian.org> | | | | | 1 | |
| Gunnar Wolf <gwolf@gwolf.org> | | | | | 1 | |
| Peter Palfrader <weasel@debian.org> | | | | | | 1 |
| Russ Allbery <rra@debian.org> | | | | | | 1 |
| Martin Michlmayr <tbm@cyrius.com> | | | | | | 1 |
| Steve McIntyre <steve@einval.com> | | | | | | 1 |
| Mark Hymers <mhy@debian.org> | | | | | | 1 |
| Moritz Muehlenhoff <jmm@debian.org> | | | | | | 1 |
| Ben Pfaff <blp@cs.stanford.edu> | | | | | | 1 |
| Cyril Brulebois <kibi@debian.org> | | | | | | 1 |
|----------------------------------------------------+---+---+---+---+----+----|
| | 7 | 7 | 6 | 7 | 10 | 13 |
|----------------------------------------------------+---+---+---+---+----+----|
#+TBLFM: @29$2=vsum(@2..-I)::@29$3=vsum(@2..-I)::@29$4=vsum(@2..-I)::@29$5=vsum(@2..-I)::@29$6=vsum(@2..-I)::@29$7=vsum(@2..-I)


Since some people have had trouble reading the proposals, I am
including a short impact of the proposal list below the proposal.

,----[ Proposal 1: reaffirm the Social Contract ]
| 1. We affirm that our Priorities are our users and the free software
| community (Social Contract #4);
|
| 2. We acknowledge that we promised to deliver a 100% free operating system
| (Social Contract #1);
|
| 3. Given that we have known for two previous releases that we have
| non-free bits in various parts of Debian, and a lot of progress has
| been made, and we are almost to the point where we can provide a
| free version of the Debian operating system, we will delay the
| release of Lenny until such point that the work to free the operating
| system is complete (to the best of our knowledge as of 1 November 2008).
`----
i Do we require source for firmware in main: Yes
ii Do we allow the Release Team to ignore SC violation bugs: No
iii What do we do for Lenny: Wait
iv Do we modify foundation documents: No
v Do we override foundation documents No

,----[ Proposal 2: allow Lenny to release with proprietary firmware ]
| 1. We affirm that our Priorities are our users and the free software
| community (Social Contract #4);
|
| 2. We acknowledge that there is a lot of progress in the kernel firmware
| issue; most of the issues that were outstanding at the time of the
| last stable release have been sorted out. However, new issues in the
| kernel sources have cropped up fairly recently, and these new issues
| have not yet been addressed;
|
| 3. We assure the community that there will be no regressions in the
| progress made for freedom in the kernel distributed by Debian
| relative to the Etch release in Lenny (to the best of our knowledge
| as of 1 November 2008);

| 4. We give priority to the timely release of Lenny over sorting every
| bit out; for this reason, we will treat removal of sourceless
| firmware as a best-effort process, and deliver firmware as part of
| Debian Lenny as long as we are legally allowed to do so.
|
| (Since this option overrides the SC, I believe it would require 3:1
| majority)
`----
This is a temporary override, so the SC need not be changed.
i Do we require source for firmware in main: No
ii Do we allow the Release Team to ignore SC violation bugs: No
iii What do we do for Lenny: Release
iV Do we modify foundation documents: No
v Do we override foundation documents Yes

,----[ Proposal 3: (allow Lenny to release with DFSG violations ]
| 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 on DFSG compliance
| issues; however, they are not yet finally sorted out;
|
| 3. We assure the community that there will be no regressions in the
| progress made for freedom in the packages distributed by Debian
| relative to the Etch release in Lenny (to the best of our knowledge
| as of 1 November 2008);
|
| 4. We give priority to the timely release of Lenny over sorting every
| bit out; for this reason, we will treat fixing of DFSG violations as
| a best-effort process.
|
| (Since this option overrides the SC, I believe it would require 3:1
| majority)
`----
This is a temporary override, so the SC need not be changed.
i Do we require source for firmware in main: No
ii Do we allow the Release Team to ignore SC violation bugs: No
iii What do we do for Lenny: Release
iV Do we modify foundation documents: No
v Do we override foundation documents Yes


,----[ Proposal 4: Allow release managers leeway to include non-dfsg bits as needed ]
| Debian's priorities are our users and free software. We don't trade
| them against each other. However during getting an release out of the
| door, decisions need to be done how to get a rock stable release of the
| high quality Debian is known for, release more or less on time, and to
| minimize the usage of problematic software. We acknowledge that there
| is more than just one minefield our core developers and the release
| team are working at.
|
| We as Developers at large continue to trust our release team to follow
| all these goals, and therefor encourage them to continue making
| case-by-case-decisions as they consider fit, and if necessary
| authorize these decisions.
|
| (Since this option overrides the SC, I believe it would require 3:1
| majority)
`----

This will need wording to change the SC, and the constitution,
since this is not a temporary override, but adds to the powers of the
delegates of the project leader.
i Do we require source for firmware in main: No
ii Do we allow the Release Team to ignore SC violation bugs: Yes
iii What do we do for Lenny: Release
iV Do we modify foundation documents: Yes
v Do we override foundation documents No

,----[ Proposal 5: allow Lenny to release with firmware blobs ]
| 1. We affirm that our Priorities are our users and the free software
| community (Social Contract #4);
|
| 2. We acknowledge that there is a lot of progress in the kernel firmware
| issue; most of the issues that were outstanding at the time of the
| last stable release have been sorted out. However, new issues in the
| kernel sources have cropped up fairly recently, and these new issues
| have not yet been addressed;
|
| 3. We assure the community that there will be no regressions in the
| progress made for freedom in the kernel distributed by Debian
| relative to the Etch release in Lenny (to the best of our knowledge
| as of 1 November 2008);

| 4. We give priority to the timely release of Lenny over sorting every
| bit out; for this reason, we will treat removal of sourceless
| firmware as a best-effort process, and deliver firmware as part of
| Debian Lenny as long as we are legally allowed to do so, and the
| firmware is distributed upstream under a license that complies
| with the DFSG.
`----
i Do we require source for firmware in main: Yes*
ii Do we allow the Release Team to ignore SC violation bugs: No
iii What do we do for Lenny: Release
iV Do we modify foundation documents: No
v Do we override foundation documents No

* This proposal gives the binary blobs distributed in the kernel
the benefit of doubt, and assumes they do not violate the GPL and are
the preferred form of modification, however unlikely that is.

,----[ Proposal 6: Exclude source requirements from firmware (defined) ]
| Firmware is data such as microcode or lookup tables that is loaded into
| hardware components in order to make the component function properly.
| It is not code that is run on the host CPU.
|
| Unfortunately such firmware often is distributed as so-called blobs,
| with no source or further documentation that lets us learn how it works
| or interacts with the hardware in question. By excluding such firmware
| from Debian we exclude users that require such devices from installing
| our operating system, or make it unnecessarily hard for them.
|
| Therefore the Debian project resolves that
| a) firmware in Debian does not have to come with source. While we do
| prefer firmware that comes with source and documentation we will not
| require it,
| b) we however do require all other freedoms that the DFSG mandate from
| components of our operating system, and
| c) such firmware can and should be part of our official installation media.
|
| (Since this option overrides the SC, I believe it would require 3:1
| majority)
`----
This will need wording to change the SC, since this is not a
temporary override, but adds a definition of firmware, and an exclusion
from the 100% free promises of the SC.
i Do we require source for firmware in main: No
ii Do we allow the Release Team to ignore SC violation bugs: No
iii What do we do for Lenny: Release
iV Do we modify foundation documents: Yes
v Do we override foundation documents No

manoj

--
Excusing bad programming is a shooting offence, no matter _what_ the
circumstances. -- Linus Torvalds, to the linux-kernel list
Debian Project Secretary <secretary@debian.org>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
 
Old 11-15-2008, 03:16 PM
Adeodato Simó
 
Default call for seconds: on firmware

Peter Palfrader's proposal [1] explicitly said, and I quote:

| I'm hereby proposing the following general resolution.

I don't think it's acceptable to bundle it up with the ongoing GR, since
it was not proposed as an amendment to it.

[1]: http://lists.debian.org/debian-vote/2008/11/msg00164.html

--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org

The problem I have with making an intelligent statement is that some
people then think that it's not an isolated occurrance.
-- Simon Travaglia


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 11-15-2008, 06:33 PM
Adeodato Simó
 
Default call for seconds: on firmware

> ,----[ Proposal 4: Allow release managers leeway to include non-dfsg bits as needed ]
> | Debian's priorities are our users and free software. We don't trade
> | them against each other. However during getting an release out of the
> | door, decisions need to be done how to get a rock stable release of the
> | high quality Debian is known for, release more or less on time, and to
> | minimize the usage of problematic software. We acknowledge that there
> | is more than just one minefield our core developers and the release
> | team are working at.

> | We as Developers at large continue to trust our release team to follow
> | all these goals, and therefor encourage them to continue making
> | case-by-case-decisions as they consider fit, and if necessary
> | authorize these decisions.

> | (Since this option overrides the SC, I believe it would require 3:1
> | majority)

Also, this one should not be voted together with the rest, since it's
an orthogonal issue. This not /exclusively/ a solution for the problem
for Lenny.

We can ask the proposer of this option what he thinks, if you don't
agree it should be split out.

--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org

Listening to: Dar Williams - You Rise And Meet The Day


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 11-15-2008, 06:54 PM
Manoj Srivastava
 
Default call for seconds: on firmware

On Sat, Nov 15 2008, Adeodato Simó wrote:

>> ,----[ Proposal 4: Allow release managers leeway to include non-dfsg bits as needed ]
>> | Debian's priorities are our users and free software. We don't trade
>> | them against each other. However during getting an release out of the
>> | door, decisions need to be done how to get a rock stable release of the
>> | high quality Debian is known for, release more or less on time, and to
>> | minimize the usage of problematic software. We acknowledge that there
>> | is more than just one minefield our core developers and the release
>> | team are working at.
>
>> | We as Developers at large continue to trust our release team to follow
>> | all these goals, and therefor encourage them to continue making
>> | case-by-case-decisions as they consider fit, and if necessary
>> | authorize these decisions.
>
>> | (Since this option overrides the SC, I believe it would require 3:1
>> | majority)
>
> Also, this one should not be voted together with the rest, since it's
> an orthogonal issue. This not /exclusively/ a solution for the problem
> for Lenny.
>
> We can ask the proposer of this option what he thinks, if you don't
> agree it should be split out.

While some of the proposals have longer lasting effects than
just the current release, they are still related: for example, the
proposal singled out above, if passed, would make proposal 5 moot, and
invalidate proposal 1.

Given that these proposals are strongly related, they should be
on the ballot together. Post Lenny, if we do want to change our
foundation documents, we can try and do so; but splitting out options
on how to handle the release of lenny in view of firmware blobs, and
the apparent conflict with the SC, would result in a botched
decision. Serial votes with subsets of options really lend themselves
to tactical voting our voting method is not designed to deal with.

manoj
--
Screw up your courage! You've screwed up everything else.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 11-15-2008, 06:57 PM
Manoj Srivastava
 
Default call for seconds: on firmware

On Sat, Nov 15 2008, Adeodato Simó wrote:

> Peter Palfrader's proposal [1] explicitly said, and I quote:
>
> | I'm hereby proposing the following general resolution.
>
> I don't think it's acceptable to bundle it up with the ongoing GR, since
> it was not proposed as an amendment to it.

I have explained why I think all these proposals are related
(they all affect releasing lenny while kernels contain firmware blobs,
and some of the solutions have effects that are more far reaching than
others). Since they are related, they belong on the same ballot --
even if they were not all formally declared to be "amendments" of the
original proposal.

Our voting methods do not deal well with related options being
on separate ballots.

manoj
--
"Imitation is the sincerest form of television." The New Mighty Mouse
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 11-15-2008, 09:50 PM
Stephen Gran
 
Default call for seconds: on firmware

This one time, at band camp, Manoj Srivastava said:
> On Sat, Nov 15 2008, Adeodato Simó wrote:
> >
> >> | We as Developers at large continue to trust our release team to follow
> >> | all these goals, and therefor encourage them to continue making
> >> | case-by-case-decisions as they consider fit, and if necessary
> >> | authorize these decisions.
> >
> > Also, this one should not be voted together with the rest, since it's
> > an orthogonal issue. This not /exclusively/ a solution for the problem
> > for Lenny.
> >
> > We can ask the proposer of this option what he thinks, if you don't
> > agree it should be split out.
>
> While some of the proposals have longer lasting effects than
> just the current release, they are still related: for example, the
> proposal singled out above, if passed, would make proposal 5 moot, and
> invalidate proposal 1.

It's not possible to express the full set of relations in a single
winner vote, as far as I can tell. It might be someone's vote to say
'none of this non-free crap in the archive ever' and simultaneously
say 'but the release team does have the authority to downgrade these bug
reports if they need to'. Unless I've missed something and we're
planning on having a multi winner vote,
--
-----------------------------------------------------------------
| ,'`. Stephen Gran |
| : :' : sgran@debian.org |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------
 
Old 11-15-2008, 10:25 PM
Florian Weimer
 
Default call for seconds: on firmware

* Stephen Gran:

> It's not possible to express the full set of relations in a single
> winner vote, as far as I can tell. It might be someone's vote to say
> 'none of this non-free crap in the archive ever' and simultaneously
> say 'but the release team does have the authority to downgrade these bug
> reports if they need to'. Unless I've missed something and we're
> planning on having a multi winner vote,

We can always put the elements of the power set of all proposals on
the ballot.

I suppose the ballot should be structured in a way that guarantees
halfway meaningful outcomes, while not actively discriminating against
certain proposals. To be honest, I'm glad I need not decide such
things.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 11-15-2008, 10:38 PM
Manoj Srivastava
 
Default call for seconds: on firmware

On Sat, Nov 15 2008, Stephen Gran wrote:

> This one time, at band camp, Manoj Srivastava said:
>> On Sat, Nov 15 2008, Adeodato Simó wrote:
>> >
>> >> | We as Developers at large continue to trust our release team to follow
>> >> | all these goals, and therefor encourage them to continue making
>> >> | case-by-case-decisions as they consider fit, and if necessary
>> >> | authorize these decisions.
>> >
>> > Also, this one should not be voted together with the rest, since it's
>> > an orthogonal issue. This not /exclusively/ a solution for the problem
>> > for Lenny.
>> >
>> > We can ask the proposer of this option what he thinks, if you don't
>> > agree it should be split out.
>>
>> While some of the proposals have longer lasting effects than
>> just the current release, they are still related: for example, the
>> proposal singled out above, if passed, would make proposal 5 moot, and
>> invalidate proposal 1.
>
> It's not possible to express the full set of relations in a single
> winner vote, as far as I can tell. It might be someone's vote to say
> 'none of this non-free crap in the archive ever' and simultaneously
> say 'but the release team does have the authority to downgrade these bug
> reports if they need to'. Unless I've missed something and we're
> planning on having a multi winner vote,

That does not seem to make sense. Either you have
'none of this non-free crap in the archive ever'
or you have
'the release team downgrades these bugs and includes non-free crap'

Not both.

Which is why they are on the same ballot.

Frankly, at this point, we are trying to get the issue of Lenny
release with or without firmware resolved. All the options do that, in
one way or the other. Some options are temporary displensations, other
are far wider ranging than that. Arguably, we might want the wider
ranging changes _anyway_, but that might not happen if we can get lenny
released by an other option.

In that case, we can re-raise the issue post lenny,
independently, and not get the vote get all tangled up with trying to
release lenny.

If we are trying to change foundation documents not in the
context of releasing lenny, I think we need a good debate on the merits
of each proposal, not an accelerated one trying to resolve the lenny
issue. But all the related proposals will solve the lenny release, so I
think it is justified to put them on the ballot about "what to do with
lenny".

manoj
--
Success in management--at any level--depends on the ability to pick the
right people for the right jobs.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 11-16-2008, 12:39 AM
Manoj Srivastava
 
Default call for seconds: on firmware

On Sat, Nov 15 2008, Russ Allbery wrote:

> Charles Plessy <plessy@debian.org> writes:
>
>> we all agree that the result of "Further discussion" is the following,
>> don't we?
>>
>> i Do we require source for firmware in main: As usual
>> ii Do we allow the Release Team to ignore SC violation bugs: As usual
>> iii What do we do for Lenny: Release
>> iV Do we modify foundation documents: No
>> v Do we override foundation documents No
>
> Hm, no, the impression that I got from this discussion that at least
> several people here think the result of "Further discussion" is:
>
> i Do we require source for firmware in main: Yes
> ii Do we allow the Release Team to ignore SC violation bugs: No
> iii What do we do for Lenny: Wait
> iV Do we modify foundation documents: No
> v Do we override foundation documents No
>
> and that seems to be consistent with what Manoj is ruling about overrides
> of the SC.

This is my reading, yes. As far as I see, the SC is pretty
clear, and leaves us no other option.

manoj
--
UNIX was half a billion (500000000) seconds old on Tue Nov 5 00:53:20
1985 GMT (measuring since the time(2) epoch). -- Andy Tannenbaum
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 11-16-2008, 12:39 AM
Manoj Srivastava
 
Default call for seconds: on firmware

On Sat, Nov 15 2008, Florian Weimer wrote:

> * Stephen Gran:
>
>> It's not possible to express the full set of relations in a single
>> winner vote, as far as I can tell. It might be someone's vote to say
>> 'none of this non-free crap in the archive ever' and simultaneously
>> say 'but the release team does have the authority to downgrade these bug
>> reports if they need to'. Unless I've missed something and we're
>> planning on having a multi winner vote,
>
> We can always put the elements of the power set of all proposals on
> the ballot.

Yes, people may propose and second combinations of current
proposals, as long as they are not mutually exclusive.

> I suppose the ballot should be structured in a way that guarantees
> halfway meaningful outcomes, while not actively discriminating against
> certain proposals. To be honest, I'm glad I need not decide such
> things.

Being very hesitant about my wisdom, my first cutr at a ballot
would be all the 6 proposals, plus a default, which is more or less
proposal 1.

manoj
--
Flattery will get you everywhere.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 06:41 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org