Adrian Bunk <[EMAIL PROTECTED]> writes:
> Sorry, but I still don't understand it:
>
> You could continue to offer the complete archive as it is today, and it
> shouldn't be a big amount of work to offer one or more partial archives
> (e.g. only stable or only i386) from different locations - and a mirror
> with bandwith problems could simply switch to using a partial archive.
>
> This wouldn't be as complicated as the SCC proposal, would have exactly
> zero impact on release management and should be implemantable within a
> few days.
Yes it absolutely would be trivial. All it needs is a script to make a
linkfarm and sync that daily. I can even give you a script for it.
> Considering that this might make it possible to ship amd64 with sarge
> which would have a positive effect on the reputation of Debian, could
> you please explain which technical problems I do oversee when thinking
> that the technical problems of such a solution were small?
>
> If such a solution would e.g. take two weeks and would have been
> implemented at the day of the SCC announcement, it was running for one
> month today...
>
> Could someone please enlighten me?
Back when we asked for amd64 inclusion more than a year ago some
people just ignored it, hiding the (non) problem in the process for
many month. Then the same people don't want to do anything to fix the
problem easy and quickly but rather design a grand scheme to solve a
million problems at once with the Vancouver proposal. And through all
those delays we are now at the "Now it is too late to add amd64"
stage.
So, after letting off some steam, please consider some other things
adding amd64 would affect:
1. release team
Another arch to sync. And, as with every arch, there would be some
packages that fail just there. There are still a lot of amd64 specific
FTBFS bugs (lots of them with patches) that would all become RC. The
RC count would double overnight at least for a few weeks. (yeah, it
would be back down if this had happened weeks ago)
2. security ream
Who knows about amd64? Who is able to debug code to see if security
problems also exist there? Who will maintain the amd64 security buildd
(since us Non-DDs are not allowed)? Who will get the wanna-build
admins to add the amd64 buildd? Seeing as after over 6 month there are
still 2 of the old archs without a security buildd for testing this
seems to be a realy big problem.
3. britney
One more arch, 15K more packages to consider. Britney needs more ram,
more time, gets slower overall and probably fails more often. More
hints needed costing more manual time.
4. D-I docs and CDs
There are no docs covering amd64 yet as nobody has done any work in
that regard. Since amd64 is basicaly just a i386 on steroids adapting
those docs should be easy. But it has to be done. There are also some
(hopefully minor) quircks left in debian-cd to investigate. Might be
caused by the missing docs.
I do however feel that the need of Debians users to have amd64 over
the next 2 years till etch is out far outweights the inconvenience of
adding it. That's why the amd64 team, recently with much entusiasm
from other parts of the debian foodchain, is doing the inofficial
release in parallel with sarge.
Sources are the same, cdimages will be on cdimage.d.o, security
updates will follow debian closely. All that differs for users is that
ftp.debian.org is amd64.debian.net for the main archive and /debian
becomes /debian-amd64 for mirros. Maybe at some point someone up there
will decide to embrace amd64, move the files over to ftp-master and
call it official post datum.
>> Cheers,
>> Andi
>
>
> cu
> Adrian
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
