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

Re: Proposal G

* 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?

> > 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.
General speaking, do you think that this is stricter than the social
contract? And: Please read the word guidelines as in the following

> > 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.

> > 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. There are different ways of reading the SC. 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.

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

(*) There are three cases:
1. Any of the other proposals (except F) matches it's own majority:
   Then this proposal can only have success if it has also a
   3:1-majority. No problem with requiring 3:1.
2. This proposal has not even a simple majority. No problem with
   requiring 3:1.
3. Anything else.
Therefor, I don't care for requiring 3:1.

> 	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.

> 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?

> 	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.

   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C

Reply to: