Re: Proposal G
On Thu, 3 Jun 2004 10:50:27 +0200, Andreas Barth <aba@not.so.argh.org> said:
> "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.
Fair enough.
>> 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.
I don't see that. This GR is to address releasing sarge; if
all we are promising is making regular releases, that is indeed
orthogonal: we can promise regular releases, and not release sarge
now (hey, releases can be made twice a decade, regularily, from what
I understand) -- or we can make the promise and release sarge now.
I can see proponents of all 4 combinations (promise, release;
promise, delay; no promise, release; no promise, delay).
Orthogonal options must be moved to seperate votes, or else
the combinations multiply.
You can, of course, put the promise in the rationale for this
GR, and propose the "we promise" GR immediately.
>> 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.
a) common sense is not entirely as common as people suppose;
b) common sense is subjective, and one man's common sense is
another man's insanity,
c) We have demonstrated that interpretations of commonly
accepted doctrines differed in the project. I am not
advocating that we write up GR's like laws, but we should
try to tighten up the wording as best we can.
>> >> > 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).
While the violation of clause 1 is direct, and unequivocal,
the release immediately or else you violate the users best interest
is a debatable issue (in other words, not so clear). I would say
that users are harmed by Debian fostering non-free bits in main --
which means that clause 4 also tells us to delay Sarge until it is
clean.
Faced with a clear cut violation of one part of the SC, and
uncertainty whether it violates, or adheres, to the other part
pretty much leads to the conclusion that the policy in question
can't be followed as such, unless it is agreed that users are harmed
more by a delay than by given non-free stuff.
>> 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.
One may conclude that users are best served by an immediate
release, rather than by a clean release at a later time; but that is
not yet established. You can not, in my opinion, use clause 4 to
push for an immediate release; that is just one opinion amongst
many.
Now, you may resolve the issue by building consensus, and
passing a GR that the developers so agree; but you can't assume it
and make the RM follow your interpretation.
> 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.
So make your resolution -- and see what the project decides
on this case. However, telling the RM team in advance of such a GR is
premature. (Option E tries to formalize guidelines under which we
may make a determination about which clause is more important than
the other -- seems to me you are skipping that important step).
>> 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.
That is fair. Shall I label your proposal GR 2004_005?
> 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.
I do not see this as a fair summary of the situation. It
certainly violates clause 1; and it may or may not violate or adhere
to clause 4. We need, as a project, to decide which view needs to be
adopted; and you can do so in GR 2004_005.
> 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.
Please do so, if you can, without the regular release
promise.
> To the second question: It's the release policy for sarge. Of
> course, sarge includes all security updates and point releases. For
Please make that explicit.
> 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.
I think that that is another indication that the two parts
submitted so far are really decoupled.
manoj
--
They have been at a great feast of languages, and stolen the
scraps. William Shakespeare, "Love's Labour's Lost"
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
Reply to: