[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: First call for votes for the Lenny release GR



On Wed, Dec 17 2008, Russ Allbery wrote:

> Manoj Srivastava <srivasta@debian.org> writes:
>
>>         I am not sure how even choice 1 is over riding that decision. Do
>>  you believe that the release team, despite their protestations, is
>>  bundling DFSG violatons into main? If the release team is releasing
>>  only free stuff, then option 1 is being followed.
>>
>>         I do not see where you get this over ride a delegate bit from,
>>  unless you are accusing the release team of violating the 100 % free
>>  debian system bit.
>>
>>         Can you clarify?
>
> If you go back to my original message on this, you'll see that I said that
> *either* option 1 is a delegate override *or* it's meaningless.  It sounds
> like you're arguing (probably just for the sake of discussion) that it's
> meaningless and we should continue on to release lenny even if it passes.
> Is that correct?

        Actually, no. I was saying that option 1 says:

,----
| 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). 
`----

        Now, the only way this overrides a delegate is if the delegates
 and decide that we are not shipping a free operating system. I did not
 understand that that was the case.

>
> *This* is exactly why I think that the ballot is poorly worded and could
> have used additional assistance, not in the form of rewriting it, but in
> the form of someone saying "uh, this makes no sense -- if you want to
> override a decision, be explicit."  I agree that any of us could have
> offered that assistance, and therefore this is something of a collective
> failure.

        Actuall, given the pwer that the secretary has voer the process,
 the secretary shoul *NOT* be saying things like  "uh, this makes no
 sense -- if you want to  override a decision, be explicit."

        The secretary should *NOT* be deciding if the contents of the
 proposal are sane.

> There are multiple different ways by which to arrive at the conclusion
> that releasing lenny as-is doesn't violate the SC.  One of them is that
> points 1 and 4 of the SC are in conflict and we steer a course between the
> two of them.

        Did you read SC #5? SC #5, in my eyes, is what tells us how we
 reconcile SC #1 abd SC #4. 

> Another is that the DFSG doesn't apply to firmware now.

        I do not see this in my reading of the SC.

> Another is that the SC is a goal that we don't need to meet in full
> immediately.

        While I do not agree for releases, I think that is true for Sid,
 and I can see how reasonable people might disagree.

> Another is that given that the software is already in the
> archive, whatever problems there are aren't the release team's problem.
> There are probably others.  I've seen all of the above put forward by
> different people as part of this discussion.  I intend to extent to all of
> my fellow developers the assumption that they hold their opinions
> sincerely and not deceptively.


> I can't tell you which interpretation is correct, if any of them --
> that's exactly the point under dispute.  I can tell you what I
> personally believe, but that doesn't really mean anything.  Other
> people can arrive at similar conclusions for entirely different
> reasons.  I don't agree with all of those opinions, but that doesn't
> matter -- that just means that we don't have consensus, and we knew
> that already.  The question now is how do we decide what to do given
> the lack of consensus.

> I think it was manifestly clear from the way in which Robert Millan made
> his proposal and the discussion leading up to it that he intended it to be
> a delegate decision override, and I think that even in the absence of
> better wording to make that explicit, the project should treat it
> accordingly anyway, since that was obviously the intent.

        Well, I don't see how we can interpret another person's
 proposal -- but these clarifying questions should have been long
 resolved now, since asking these questions is why we have a discussion
 period. 

> No, I think this is too simplistic.  A vote is not solely your work as
> secretary.  It also has a direct effect on other people's work.  It's
> effectively part of multiple decision-making processes at the same time.

        Any developer in a core role has the same impact. The FTP
 masters, and the release team, have similar impats on the
 project as a whole.

        I till think that if a 3:1 majority requirement needs the SC to
 be interpreted, I am unclear what your suggestion is. My take on it has
 been that I do as the other delegates do: I interpret the SC for
 myself, as best I can, and act in goodfaith. I see this situation as no
 different from that of the  FTP master/RM situation.

        manoj
-- 
"Boy, life takes a long time to live." Steven Wright
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: