Re: Summary: Proposal - Rescind GR 2004-003
Hi,
One thing we all can agree is that there have been long and many
arguments over what SC really means and there are few camps out there
with totally different views.
On Tue, May 04, 2004 at 08:05:38PM +0200, Guido Trotter wrote:
> On Tue, May 04, 2004 at 12:16:25AM +0200, Osamu Aoki wrote:
>
> > Here is the list of rationale raised for this proposal:
^^^^^^
Please note this "raised".
> > * People can make mistake and should be allowed to correct it.
> > * This deserves to be an option on the ballet.
> > * Full impact assessment by Anthony Towns [3] revealed the hidden issues.
> > * We need to get the sarge out the door ASAP. [4]
> > * All other proposed GRs to get the sarge out are better than the
> > situation created by GR (2004-003). But they still seem to put heavy
> > limitations on the past-sarge releases. This proposal solves them
> > for good.
>
> Are you sure about this? The problem is posed by RC issues which were
> tagged sarge-ignore.
I thought:
* "sarge-ignore" means that, although there is a good discussion going
on for RCness of the bugs, RM will ignore debatable ones for sarge by
the decision of RM.
* RM changed his position on "sarge-ignore" because the new clarified
SC text left him with no room to interpret SC to allow these
components as "sarge-ignore".
> This means that they would be ignored *only* for sarge, and not
> allowed to remain after.
Really? Following the result of Google search of '"sarge-ignore" debian'
leads me to: http://people.debian.org/~ajt/sarge_rc_policy.txt
| Further to this, certain issues may be exempted from being considered
| release critical for sarge by the release manager. This is expressed
| by tagging the report "sarge-ignore"; this should not be done without
| explicit authorisation from the release manager.
This definition of "sarge-ignore" made no commitment that the next
release will not ignore these RC bugs.
Let's continue.
| Here's the list:
|
| 1. DFSG-freeness
|
| Code in main and contrib must meet the DFSG, both in .debs and
| in the source (including the .orig.tar.gz)
|
| 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.
"likely become a requirement" is clearly not equal to "not allowed to
remain after". This means to me that discussion is ongoing and RM
acknowledged that the camp pushing for DSFG compliance for documentation
is wining. (I like to see DSFG issues resolved for GFDL by the new
nicer GFDL. But this is a separate issue.)
You can read on about firmware issues and its GPL compatibility issues
there. But I see nothing stating that sarge++ will not have firmware in
Debian main.
Did I miss something here?
> > * Change of SC by GR (2004-003) was not clarification but a radical
> > change which subverts the original intent of the old SC.
>
> So the original intent of the SC was to have non-free non-software in main?
> I remember Bruce Perens saying the opposite (but I'm too lazy to search
> where, so I may be in mistake). Have you got any reference which confirms
> this interpretation?
I listed this due to following message by Craig:
http://lists.debian.org/debian-vote/2004/04/msg00314.html
which said:
... the GR was proposed with a misleading title (it was NOT a simple
"editorial" change, it was a radical change to the meaning of the
Social Contract which will ultimately result in the death by
irrelevance of debian) and effectively got through by stealth.
To me, it was clear that there are people who understood SC this way.
The result of this GR will only tell which side had more supporters.
If you find solid consensus on this issue, please post to here or
debian-private (if it was originally in debian-private, CC: me).
Osamu
Reply to: