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:
pgpEgDgzj9NjP.pgp
Description: PGP signature