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

Re: Proposal G



On Wed, 2 Jun 2004 10:27:58 +0200, Andreas Barth <aba@not.so.argh.org> said: 

> * Manoj Srivastava (srivasta@debian.org) [040602 09:25]:
>> On Tue, 1 Jun 2004 10:19:15 +0200, Andreas Barth
>> <aba@not.so.argh.org> said:
>> -------- Reaffirmation of the social contract - priorities
>> > are our users and the free software community
>>
>> > For our users, we promise to do regular releases; as a guideline,
>> > a major release of the distribution should happen about once a
>> > year.

>> On what basis do you think we can make this promise?

> The promise to do regular releases: On the same as we promise other
> things: That we do our best to keep it. Or what else do you think?

	The best we can do is promise to try. Actually promising to
 make regular releases requires at the very least a hint of a plan,
 something that would help us make our release intervals shorter, buy
 in from the release team and the developers, and a trial run
 (perhaps in private, like aj had done for setting up testing).


	Making empty promises like this does not seem like something
 we should be doing. In any case. this looks like an orthogonal
 issue; we can release sarge now, and promise to release regularily,
 we can repeas the editorial chjamges and promise to release
 regularily, we can affirm the social contract as of today and
 promise to make regular releases, we can make a new foundation
 document and promise to make regular releases. Or not.

	Since this is orthogonal, please propose it in its own GR.

>> > For the free software community, we promise to use the Debian
>> > Free Software Guidelines as guidelines for the software that is
>> > allowed to go in the Distribution ("main" on the ftp-mirrors).

>> That excludes the current Sarge release. And thus we would need to
>> eviscerate sarge.

> For the special case of the release of sarge, please see below.

	OK.

> General speaking, do you think that this is stricter than the social
> contract?

	Actually, this seems kinda redundant. The social contract
 already says what we use as guidelines for determining what is free;
 and those guidelines tell us sarge, as it stands today, contains
 non-free elements.

> And: Please read the word guidelines as in the following
> paragraph:

>> > We know that, as with every guidelines, there are border cases
>> > were these guidelines don't really match. We promise to use our
>> > common sense in this case to get to an appropriate result. We
>> > will use our guidelines in a way that serves our users and the
>> > free software community, and we don't intend to blow our
>> > guidelines up to full legal texts, because we aim to create the
>> > best operating system, consisting of free works, and not a place
>> > for lawyers-to-be.
>>
>> I have no idea what that means.

> Do you remember the discussion whether the GPL can be included
> because the GPL can't be modified? Of course, we can make a new
> regulation about license texts. However, I prefer to keep the social
> contract and the DFSG simple, and just use our common sense that we
> don't really care about the license of the GPL.

	Well, please rphrase that paragraph to be less vague, and
 actually say what it means; as it stands, especially if this document
 is to overrule a foundation document, the language is by far too
 vague and far too open to misinterpretation.

>> > Furthermore, by this decision, we overrule the decision by the
>> > release manager in
>> > http://lists.debian.org/debian-devel/2004/04/msg06588.html and
>> > re-inforce the release policy that was valid prior to this
>> > date[1]. Of course, the Release Manager team is authorized to
>> > adjust the release policy.
>>
>> > [1] still available as today on
>> > http://people.debian.org/~ajt/sarge_rc_policy.txt ------------------
>>
>> That policy violates the SC. You essentially told a delegate to go
>> violate the social contract, and I don't think we can do that.

> No, it doesn't.

	Does too.

> There are different ways of reading the SC.

	Let us see.
======================================================================
`Social Contract' with the Free Software Community

 1. Debian will remain 100% free

    We provide the guidelines that we use to determine if a work is "free" in
    the document entitled "The Debian Free Software Guidelines". We promise
    that the Debian system and all its components will be free according to
    these guidelines.
======================================================================
Old Release policy

        Documentation in main and contrib must be freely distributable,
        and wherever possible should be under a DFSG-free license. This
        will likely become a requirement post-sarge.

        An exception exists for "firmware" - that is code that
        will be uploaded to a hardware device as part of making it
        functional. This may be distributed in main even without source
        or modifications being allowed; but you must be careful not to
        violate the GPL by incorporating it into a GPLed program. This
        generally means using the hotplug request_firmware() interface
        to load the firmware from userspace. The firmware does not need
        to be moved into a separate package, however.
======================================================================

	I can't see how you can "interpret" that to say that the
 policy is not a violation of the social contract.

> In my opinion, the SC requires us to release sarge soon ("our
> priorities are our users and the free software community"), and the
> only way to do this is to use this cited release policy.

	Right, as soon as possible, as long as it is also free. If
 you want to rule on what bits of the social contract take precedence
 over the other bits of the social contract, you need to be precise;
 since this GR should help to get on with the release, and not
 descend into endless debates about the scope and the meaning of the
 proclamation. 

>> If you mean this position statement to explicitly overrule a
>> foundation document, you must say so; and then it would need a 3:1
>> super majority.

> I don't think that it overrules a foundation document, but rather
> reads it in a specific way that disagrees with the way your read it.
> However, as the 3:1-majority is needed anyways(*), I don't mind to
> add something like: In the opinion of the Secretary, this proposal
> overrules the social contract, and needs therefor a 3:1-majority. In
> the opinion of the proponent, it doesn't overrules the social
> contract, but just put more siginficance on the interests of our
> users (as in SC #4).

	Please submit the modified proposals. I would also strongly
 suggest that you tighten up the proposal, and explain some of the
 ambiguous or vague elements. Most of the redundant stuff really
 belongs in a rationale; this proposal seems to interdigitate the
 working proposal with its own rationale.

>> I would also advice you to clean up this proposal; there is not
>> time period for how long the social contract is to be violated by
>> the project,

> This proposal doesn't violate the social contract.

	I beg to differ. This proposal puts in place a policy which
 is in violation of the social contract as it stands today.

>> and we should remove promises we have no idea whether we can keep,
>> no plans that have even been considered as to how we could possibly
>> change that.

> You think that we can't keep the promise to do regular releases?

	Our track records makes me think it is quite likely that we
 shall have trouble doing so. If there were a detailed proposal of
 changes, I may think there is some substance behind the promise, but
 as it stands, no. However, this is a different GR, so we should talk
 about it in a new thread.

>> As it stands, I do not think that this proposal meets the
>> requirements for helping determine the changes in release schedule
>> of sarge in voew of GR 2004_003; therefore I think it may need to
>> go on a separate ballot (since it is there fore a separate
>> issue). I need to think about it more before making an official
>> ruling on this, and I am open to being persuaded either way.

> Of course it helps. The release manager has put an issue forward to
> the technical comittee and/or the developers, and this GR puts an
> specific way to deal with them: We reaffirm the previous release
> policy, and ask the release manager to release sarge based on this.

	You are leaving dangling the problem that the previous
 release policy violates the SC. You can't affirm a release policy in
 violation of the rules, unless you state that you are overruling the
 SC, and then I would prefer that you define the scope (how long is
 the violating release policy good for? for sarge? point releases?
 security updates? forever?)

	manoj

-- 
Beware of geeks bearing graft.
Manoj Srivastava   <srivasta@debian.org>  <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Attachment: pgpSHRC5yFNWl.pgp
Description: PGP signature


Reply to: