Re: Proposal G
* Manoj Srivastava (srivasta@debian.org) [040602 19:55]:
> 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).
"promise to do regular releases" does not speak about "making our
release intervals shorter". Of course, the goal is to do a release
about once a year, but that's not part of the promise.
> 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.
This promise is a core part of this proposal. If you reject this part
to be on the ballot, then it's better to drop the whole proposal from
the ballot.
> >> > 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.
>
> > 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;
The whole proposal, except the last paragraph and the sentence "as a
guideline, major releases of the distribution should be about once a
year.", repeats - in my opinion - only what the social contract
already tells us to do.
> >> > 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.
I disagree with you. I really think that we should be able to say: We
use our common sense.
> >> > 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.
> ======================================================================
The Social Contract does not only consists of #1. It does also provide
a #4:
======================================================================
4. Our priorities are our users and free software
We will be guided by the needs of our users and the free software
community. We will place their interests first in our priorities. We
will support the needs of our users for operation in many different
kinds of computing environments. We will not object to non-free works
that are intended to be used on Debian systems, or attempt to charge a
fee to people who create or use such works. We will allow others to
create distributions containing both the Debian system and other
works, without any fee from us. In furtherance of these goals, we will
provide an integrated system of high-quality materials with no legal
restrictions that would prevent such uses of the system.
======================================================================
So, in my understanding, this paragraph forces us to do regular
releases, with not too large intervals. And, for the moment, the only
way to do this is to stick to the sarge release policy (at least
nobody has claimed an alternative to this).
> I can't see how you can "interpret" that to say that the
> policy is not a violation of the social contract.
Well, the social contract requires us at the same time to release now,
to release a working system, and to release only free code. In my
opinion, the cited sarge release policy is the best way to achive as
much as possible of all these goals.
> > 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.
In real life, if different rules collide, one usually trys to take the
approache that each rule is valid in it's core, and trys to balance
out the rules outside the core of the rules. I think this is the
proper approach; I don't want to give any of the rules of the Social
Contract the absolute priority over another rules, but decide by a
case-by-case-basis what's the best approache to take from the point of
view of the whole social contract.
> >> 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 don't see how I can modify the proposal in a way that both meets
your expectations, and works as intended by me.
> >> 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.
There are different interpretations of the social contract. I can see
that it is in violation of the interpretation of the social contract
of some of the developers, but not in violation of the interpretation
of other developers.
> >> 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?)
As I said, I don't think that I need to overrule the SC, but I said
that I'm willing to add a clause that this proposal overrules the SC
in the point of view of some of the developers, and therefor need a
3:1-majority.
To the second question: It's the release policy for sarge. Of course,
sarge includes all security updates and point releases. For the next
release (Codename to be choosen) the release managers as delegates of
the DPL, will do their release policy in their own responsibility,
under the different rules of the constitution and the social contract.
My proposal does not talk about sarge+1, except that we promise to do
regular releases.
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Reply to: