Re: Social Contract GR's Affect on sarge
- To: email@example.com
- Subject: Re: Social Contract GR's Affect on sarge
- From: Raul Miller <firstname.lastname@example.org>
- Date: Mon, 26 Apr 2004 12:59:17 -0400
- Message-id: <20040426125917.V13880@links.magenta.com>
- In-reply-to: <20040426165227.GA18940@azure.humbug.org.au>; from email@example.com on Tue, Apr 27, 2004 at 02:52:27AM +1000
- References: <firstname.lastname@example.org> <20040426045609.GA2579@azure.humbug.org.au> <20040426095953.O13880@links.magenta.com> <20040426101609.P13880@links.magenta.com> <email@example.com> <20040426161500.GC17247@azure.humbug.org.au> <20040426123602.R13880@links.magenta.com> <20040426165227.GA18940@azure.humbug.org.au>
[Note: I've removed aj from the explicit followups to honor the
Mail-Followup-To: headers on his message.]
On Tue, Apr 27, 2004 at 02:52:27AM +1000, Anthony Towns wrote:
> The key questions to my mind are:
> * are there any other possible release policies on this issue
> (than "delay sarge 'til non-DFSG-free firmware, docs, etc
> are removed from main") that satisfy the new social contract,
> by any reasonable interpretation of that document?
> * is it permissable to have a release policy that deliberately
> breaks the social contract?
> I believe the answer to both questions is "no". I think the first question
> is fairly clearly an issue of technical policy -- what goes in sarge? --
> if that's worth anything.
Some of the technical issues underlying this issue are spelled out in
Of course: if a full solution to this problem lies outside the scope of
the committee, maybe we'd be better off issuing advice on how to proceed
than mandating a solution.
Also, if a full solution to this problem is out of scope then we shouldn't
be surprised if other work towards that solution proceeds apace.
Even working quickly, we shouldn't be surprised if we wind up simply
emphasizing that some other thread of activity is the right move.