[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> "D. Starner" <[EMAIL PROTECTED]> writes:
>
>> I don't agree with the GR as it stands. The release manager should
>> decide whether or not to release AMD64 with Sarge. I prefer that
>> we could get AMD64 added to Sid by peaceful discussion and not a
>> GR.
>
> It seems like its appropriate for this to be taken off of -vote.
>
> There seem to be four distinct issues here:
>
> 1) Should amd64 support biarch as an interim before multiarch support
> is in place?
That is a clear no from the debian-amd64 port team. It is also a
pointless question since it can't be in debian at all as long as sarge
is pending (unless base is unfrozen).
> 2) What's the best way to support the change in library directory
> that is involved here?
That is also beside the point of pure64. Any change in library
directories applies to i386, ppc, s390, mips, mipsel and sparc just as
well as amd64 and is not part of the scope of pure64.
> 3) Should the existing pure64 be added to sid?
I think that is the only thing on-topic for vote.
Through inaction (at least not publishing the issues) ftp-master has
decided to not add amd64 to sid. That (in)decision was called to be
overruled by the GR while all the other points of the GR are undecided
so there is nothing to overturn.
Lets see if I can summarize the comments relevant to sid inlusion into
a new draft:
======================================================================
The GR should be restated along the following:
This GR calls for a vote to overturn the decision (made through
inaction) to block amd64 from sid by the ftp-master team.
One of the following obsoletes/delays this GR:
1. amd64 is added to sid (the obvious).
2. The ftp-master team (or someone speaking for them) clearly states
the issues preventing amd64 from being added which can then be fixed
or the appropriate instances can be called to intermediate when no
aggreement between ftp-master and the debian-amd64 team is possible.
3. The ftp-master team gets changed (someone resignes or is removed or
someone is added) to facilitate better communications, which would put
the GR on hold for X days (a month?).
If the GR passes the ftp-master team has Y days to implement one of
the 3 points above. If it fails to do so on its own the DPL is asked
to enforce the decision [disappointing the team if needed].
======================================================================
> 4) Should the existing pure64 be added to sarge?
That is the decision of the release manager and he has neither made a
decision regarding amd64 and sarge nor has he been asked to. I doubt
someone can make an argument why this would be constitutional in a GR.
Also it is quite premature (which goes along what you said) to decide
the sarge issue now before amd64 is in sid. Before this can be judged
the majority of packages have to be uploaded for sid and undergone the
testing script (be added to sarge). Some previously state limits where
90% completness and 95% completness. I estimate 1-4 weeks delay to
reach that level and no decision should be made before that.
As to if pure64 could be added to sarge I would caution against
it. Pure64 has not yet the stability I associate with a Debian stable
release (mainly because the X web-browsers are buggy as hell). If that
can be resoved (and tested enough) before sarge is released remains to
be seen.
> (1)-(3) are off-topic for debian-vote.
>
> The answer to number (4) seems clearly "no". Being a part of sid and
> testing is a requirement for being a part of stable, and regardless of
> whether something has been excluded from sid for good reasons or bad
> reasons, it shouldn't be put in stable by some kind of end-run around
> sid and testing.
Agreed by all I think/hope.
> Thomas
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
