Re: Status of 'sarge' for the amd64 architecture
- To: firstname.lastname@example.org
- Subject: Re: Status of 'sarge' for the amd64 architecture
- From: Adrian Bunk <email@example.com>
- Date: Tue, 3 May 2005 04:26:42 +0200
- Message-id: <[🔎] 20050503022642.GV3592@stusta.de>
- Mail-followup-to: Adrian Bunk <firstname.lastname@example.org>, email@example.com
- In-reply-to: <firstname.lastname@example.org>
- References: <20050423142428.GY4355@stusta.de> <20050423202040.GA25852@mauritius.dodds.net> <email@example.com> <20050423222444.GF10453@mails.so.argh.org> <20050425142428.GB1470@moregruel.net> <20050425152253.GN19819@mails.so.argh.org> <20050429133503.GA3562@admingilde.org> <20050429135037.GN10453@mails.so.argh.org> <20050429223633.GA15937@stusta.de> <firstname.lastname@example.org>
On Sat, Apr 30, 2005 at 11:50:30AM +0200, Goswin von Brederlow wrote:
> Adrian Bunk <email@example.com> 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.
And noone has said _why_ this isn't simply done...
> > 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"
There were also not so nice things like ftpmasters ignoring emails and
amd64 porters calling them names for doing this.
This was wrong in both directions, and was one more negative result of
communication problems inside Debian.
> 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)
Besides the fact that I think the RC bug count metric isn't a good
metric for measuring the quality (it's a good example for the known fact
that in such cases only the metric is improved, but other things that
aren't measured by this metric tend to be ignored), FTBFS bugs on
architectures a package was never built on are not considered RC.
Are there any FTBFS issues on amd64 in important packages that aren't
> 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
What kind of amd64 specific security problems do you expect (except for
> (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.
What is the real problem?
Getting money for hardware?
Finding administratores for the machines?
> 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.
Why are more hints needed?
And if the problem is Britney being resource hungry, adding more RAM to
the computer it's running on might be an option?
> 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.
And you have to do this work for your separate amd64 release.
> 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.
Which creates extra work...
> 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.
And security fixes will be provided at which location?
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed