Re: Status of 'sarge' for the amd64 architecture
Adrian Bunk <bunk@stusta.de> writes:
> On Sat, Apr 30, 2005 at 11:50:30AM +0200, Goswin von Brederlow wrote:
>> 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
> easily solvable?
Some very few package broke with newer uploads. So those would be
counted as "did build before" by us. Esspecially if the old version is
still in sarge. For the rest you are right, they would still only be
important and not RC.
Then there are the packages with bugs in sarge but not in sid. Again
you can keep them all non RC (except util-linux and syslinux which are
needed for a release) and .
But all of those can easily be fixed by a weekend of aggressive NMUing.
>> 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
> kernel issues)?
I guess kernel problems. But always expect the unexpected. At a
minimum they need a system meeting their security secrecy
requirements.
>> (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 hardware?
> Getting money for hardware?
> Finding administratores for the machines?
Beats me.
>> 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?
Might be, might not be. I think the britney algorithm needs
rewriting. There is something seriously wrong with the current
one. Getting killed by out-of-memory after using over 1.2Gb ram
doesn't sound correct.
>> 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...
At least it will be a test for what the SCC/Vancouver proposal will
mean. LOTS OF PAIN.
>> 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?
amd64.debian.net:/debian/dists/stable-security/ probably.
MfG
Goswin
Reply to: