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

Re: Stop the madness (Re: -= PROPOSAL =- Release sarge with amd64)



Joshua Kwan <joshk@triplehelix.org> writes:

> <DISORGANIZED RANT>
>
> On Sat, 17 Jul 2004 11:08:33 +0200, Florian Weimer wrote:
>> Yes, but probably there would be another one.  Maybe "Debian destroys
>> its future because it doesn't ship the architecture that will dominate
>> the computing world starting next year", or something like that.
>
> Commercially speaking this is a very important argument in favor of amd64
> in sarge. I work at a rackmount server company where about ~70% of our
> shipments are AMD Opterons running Red Hat Enterprise Linux AS.
>
> Wouldn't it nice to see some of those machines running a well-made
> official Debian port?
>
> Of course, when we look at the issues pertaining to amd64 - possible
> gcc-3.4 transition, missing multiarch, not all packages work with it, etc.

- gcc-3.4 is uploaded to unstable. The transition can happen while all
packages are being recompiled for sid anyway. If that drops the amount
of ported packages below the release candidate threshold then tough
luck, amd64 would stop being a candidate. If we get everything
compiled fine then fine.

- Multiarch is in no way essential for amd64. In fact most people
think its quite useless for that arch. The 32/64 bit issue is just a
transient problem and sufficiently (given the only complained so far
was OO and that is getting fixed now) solved by ia32-libs. There is no
reason to prefer 32bit versions if there is also a 64bit version for
amd64, which there will be.

- For any arch not all packages work with it. What counts is that enough
packages do and that those that do build a useable group. Only concern
I have there is with web browsers but gcc-3.4 seems to cure that. But
if it turns out that amd64 has to many bugs then the RM can decide not
to release sarge with amd64. But debian should at least try and check
first.

> - it is clearly unreasonable to release it with sarge assuming it comes
> out within the next two or three months. Why not dump amd64 into sid

In two or three month amd64 will have had ~6 month of testing by its
users. Someone said previously that that time span should be invested
into testing before making a decision.

> first, keep fixing packages so they build on amd64, and then release a

Last count I made we were down to ~100 packages being build with a
patch that is pending in the BTS. So lets say we drop all those. Then
we still are around 97% complete.

And a large section of those pending bugs is adding 'amd64' in
debian/control.

What I try to say is that for pure64 the porting is over. Now it's just
day to day work like any other port and amd64 is in a better shape
(completion wise, not tested wise) than all others.

> sarge snapshot of it as the official sarge release for this arch? (NB
> after some additional reading Frederik Schueler proposed this already,
> but it's so simple and functional that it deserves repeating.)

I asked Martin Schulze on irc about adding amd64 later in a point
release and he already vetoed it. Its either sarge or sarge+1 unless
you get the decision overturned.

I, and I think all others, agree that amd64 has to be added to sid
first, then go thrugh the normal sarge/testing procedure and meet the
criteria to be a release candidate. Otherwise the choice to add amd64
to sarge is overruled by technical concerns, simple as that.

If amd64 is found not ready when sarge will be released then so be
it. But please lets try first before just dismissing the idea. I doubt
the GR was ment to overrule real technical concerns but only to
overrule social problems.

> I can't really tell where everybody is coming from. I have not read the
> thread back to back. I do care about Debian but the fact is that I have a
> life too. But I don't think anyone at all - as Matt Zimmermann pointed out
> - objects to amd64 entering sid. In fact, I'm sure many embrace it! So a
> lot of this argument is already moot.

Yes, and still nothing happens.

Well, Martin has posted an update on the subject of sid inclusion so
lets give that some time to workout. The GR was to (indirectly but not
stated as such) to overturn the ftp-masters decision by inaction.

Now an effort is being made to get some action so the GR should be
delayed (or obsoleted since the only thing faintly valid in it is the
implicit sid inclusion) to let that work out.

> We have all begun to take sides. Debian is falling apart and we scream
> "fork Debian, get out of our hair" to opposing parties, people -- VERY
> good people -- are getting disillusioned and are thinking of resigning
> from the project because all the GRs we've had do nothing but generate
> strife and vendettas. There is really not a whole lot in disagreement here
> except that it would be REALLY, REALLY nice for a ftp-master to say "Look,
> amd64 is real cool, we'd like to see it in sid, maybe not in sarge; but if
> you want to do that here's what you have to do." Then we would be working
> toward a common goal. But for now, this discussion is just a cesspool of
> hate.

Hear hear.

> The reality is, what would happen if we gathered everyone participating in
> this discussion and stuck them in a conference room somewhere, next to
> each other?
>
> I'm sure they wouldn't be ripping out each other's necks like what's going
> on now.
>
> Perhaps it would be amicable if some porters and some ftp-masters met some
> time for lunch or something!? At this rate, whatever it takes to stop
> people arguing, and to get them on with releasing Sarge is good.

As said above, lets give it some time. An effort is underway, if it
succeeds all is well.

> I must emphasize that I would personally really like to see amd64 in sid.
> I'm unsure as to whether it's healthy enough for sarge.

I doubt it is yet up to the high standard of other stable ports but
Debian should at least try. The repository on alioth has only minor
problems (on a port scale, not per package) getting reported but
rebuilding for sid could change that. Debian won't know unlessthey try.

> -- 
> Joshua Kwan

MfG
        Goswin



Reply to: