Re: Bundled votes and the secretary
On Thu, Dec 11 2008, Raphael Hertzog wrote:
> Manoj, I still object to voting all at once and I'm convinced that you
> will manage to hurt the project by doing that.
>
> Honestly, at this point, I would really wish that you retired as
> secretary because there have been too many conflicts between you and
> various DD while your secretarial work shouldn't be the source of any
> conflict. You just have to count the points on each side but you
> don't. You insist on deciding alone if something is a change to the
> DFSG (when the text doesn't modify it explicitely) while I believe that
> only the project at large is able to decide of something like that.
The project at largewill be doing the deciding. If they pass a
resolution that contradicts the foundation document, the will of the
people should not be dismissed.
> That said, here are my comments anyway:
>
> On Wed, 10 Dec 2008, Manoj Srivastava wrote:
>> 41b0a520-c6c1-4e7b-8c49-74ee85faf242
>> [ ] Choice 1: Reaffirm the Social Contract
>
> "Delay Lenny until all DFSG violations known at 1. Nov 2008 are fixed"
>
> At least be clear what the choice means. Otherwise it looks like you are
> hiding the meaning and trying to get you personal preference (yes you
> explained several times that you would probably vote for such an option).
The title for the resolutions are usually selected by the
proposer. I d do not change it unless it is clear to me that the title
is obviously incorrect. Ask the proposer to modify the title, or
demonstrate the title is wrong (no clear enough is not "wrong").
>> [ ] Choice 2: Allow Lenny to release with proprietary firmware [3:1]
>
> We're not changing the DFSG. So there's no need for 3:1.
The proposal is to resolve on a course of action that over
rides a foundation document.
>> [ ] Choice 3: Allow Lenny to release with DFSG violations [3:1]
>
> I followed the discussions but I don't even know why we have this
> alternative which looks like the same than 2.
Look again. This is more general than 2.
>> [ ] Choice 4: Empower the release team to decide about allowing DFSG violations [3:1]
>
> The full text doesn't use the word DFSG violation.
> Maybe:
> "Let the release team decide if each known freeness problems should be blockers"
We define the DFSG to be the definition of what we consider
free. So freeness problems == DFSG violations.
>> [ ] Choice 5: Assume blobs comply with GPL unless proven otherwise
>
> The proposition doesn't speak of the GPL in any special way. Neither does
> it explain what is required to prove that source code exist for the blob.
> So this subject is not appropriate either.
>
> In fact, I would think it doesn't solve at all the problem of GPL
> firmwares.
Well, if you can show that the GPL firmware is not in the
preferred form of modification, you might have a point.
I wanted to propose that a) Everything in the kernel should be
a) legal for us to distribute
b) released under a free license.
What is excluded is "verfy beyond reasonable doubt that the
firmware is the preferred form of documentation". I wanted to say we'll
take any upstream claim that the firmware does not violate gpl or
whatever dfsg free license it is nunder; unless we have some kind of
proof that the author is being deceptive.
I'll take suggestions on how to word this on the ballot as long
as the meaning is not distorted.
>> [ ] Choice 6: Exclude source requirements for firmware (defined) [3:1]
>
> Peter explicitely told that he doesn't want to modify the DFSG.
If peter is resolving that the project do something that
contradicts the dfsg, I am not sure any unrelated staements he makes
changes the fact that the resolution is to propose a course of action
different from the current foundation document.
manoj
--
A 'full' life in my experience is usually full only of other people's
demands.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: