[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: -= PROPOSAL =- Release sarge with amd64



David Weinehall <tao@debian.org> writes:

> On Fri, Jul 16, 2004 at 08:30:04AM +0200, Ingo Juergensmann wrote:
>> On Fri, Jul 16, 2004 at 02:16:00AM +0200, Goswin von Brederlow wrote:
>> 
>> > PS: I greatly value the work you have done but I don't like this "I'm
>> > above the law' kind attitude.
>> 
>> Since "Animal Farm" we know: 
>> 
>> "All animals are equal but some animals are more equal than others."
>
> I kind of suspect some people have been reading 1984 too many times,
> considering the amount of conspiracy theories that are weathered ever
> so often on various Debian-lists...  There is no conspiracy against
> AMD64, it's just a question of bad timing.  Trying to combine
>
> a.) low diskspace on mirrors (known problem, getting worse all the time)
> b.) release of Sarge
>
> and
>
> c.) another architecture
>
> just isn't realistic.  a.) is being actively worked on, b.) too.
> c.) requires a.) to be solved first, and *will*, no matter how much you
> close you eyes and say "Noooooo, AMD64 is totally free from bugs",
> further delay b.).
>
> In this thread I'm mostly witnessing half-truths (or hopefully just
> ignoramus) and and bitter whining rather than constructive ideas, to an
> extent I've rarely encountered before[1].  If you care about AMD64 (and
> I'm not talking specifically to you Ingo, I just decided to jump in on
> your quote), forget about the GR-proposal, help fix the RC bugs in base
> and standard.  Just because those bugs aren't AMD64-specific, doesn't
> mean they don't block AMD64.  In fact, as soon as Sarge is ready for
> release, everyone except for the stable release manager will have a lot
> more time to deal with AMD64.

Thats absolutely counterproductive to the people wanting amd64 support
in sarge. They would want to delay sarge as much as possible so amd64
support can be added too.

> Bitching won't help AMD64 to get into Sid faster.  Helping out with
> things that block the release of Sarge will.  AND tends to create a lot

How about 200 patches to RC bugs? I think the count for amd64 patches
for general RC bugs is around that number.

> more goodwill than whining your ass off does.  Make sure that everything
> works perfectly, so that a nice slip-in of AMD64 into Sarge r1 will be

That only works if amd64 is in sid so it can be tested under realistic
conditions and with the right debs. Security wise it is impossible to
use the debs from alioth to upload to ftp-master or worse to release
sarge r1.

Also any bugs showing up in amd64 need to be fixed before sarge is
released since point releases are for security fixes.

> a no-brainer.  And trying to get AMD64 into Sarge is just plain silly.
> It's not even in Sid yet.  Not even silly 10kB packages goes directly
> into testing without passing Sid.  Does anyone really consider it sane
> to let an entire new architecture in without at least being part
> of Sid for, say, half a year or so?  Especially in a situation where we
> *hopefully* can release Sarge within that timeframe[0]?

No. And that part was just wrong in the GR.

Amd64 has been ready for sid inclusion since mid Feb. and if it had
been added back them the 6 month timeframe you suggest would not be a
problem.

Every day delay on the sid issue means one day less testing for amd64
before a sarge release. Thats how the sarge amd64 supporters see
it. Which makes this very urgent and probably contributed largely to
the GR in the first place.

> Don't feel like fixing RC-bugs?  Write missing manual-pages; there are
> still a lot of packages missing manual-pages.  Or even better, make
> sure existing manual-pages are up to date.  While it's in no way
> RC for Sarge, having a well-documentated Sarge surely makes a better
> impression.

Oh, so making sarge without amd64 make a better impression will do
wonders for amd64. Sure. Thats complety irelevant to the case.

> If nothing else, stop prolonging this thread further[2].  Repeating
> your message won't help.  It will however increase the probability of
> getting killfiled.  And then you can be _sure_ that your message won't
> ever get heard.
>
> Oh, and please stop perpetuating the widespread, incorrect belief that
> James Troup is the only FTP-master.  He isn't, he's part of a team.

James was the person being named as having issuses and that he would
post them soon. If any other ftp-master knows what the issues are they
haven't come forward yet. Please do.

That could be because it is not their job (like the RM having more
jobs than his little helpers) or they don't have a clue what issues
James has but don't want to interfere with him or one of a million
other reasons.

> BTW: Feel open to flame.  I don't killfile anyone (well, except for
> spammers).  I might not answer, but at least I read the mail I get.
>
>
> Regards: David Weinehall
>
> [0] Yes, I'm an optimist.
> [1] And I've been active in politics for more than 10 years.
> [2] Yes, I'm fully aware of that this post does that too...

MfG
        Goswin

PS: Don't get me wrong. I don't think sarge amd64 will be, its not
tested enough and bugfree enough for that. It might even require
gcc-3.4 to solve that. But I'm a sid user and don't much care about
stable.



Reply to: