Subject: Moving development off this mailing list

From: Charles Esson <[email-masked]>
Date: Fri, 06 Feb 1998 10:18:50 -0500

I have long felt that the linux-arm development effort has adopted the
linux code but not the development method that made linux the success it
is. The paper pointed to be the following URL discusses what the linux
development method. I think it is probable the most significent writing
on  the topic of project managment since the Mythical man month.

http://earthspace.net/~esr/writings/cathedral-paper.html

If you don't agree with me then please read the following extact from an
email that was posted to this sight around Christmass. Russell's posting
that led to this responce ( which I long ago zapped). Russell's earlier
emails stating he didn't want to post the source for arm linux as he
would get email from inexperienced users and so on.

As this posting is very blunt, I expect very blunt responces, but before
you flame me please read the above paper.

\
-----------------------------------------------------------------------------------
\
> No Phil.  Your patch does the following:
>
> *     Changes the help descriptions for the ethernet cards.

That's true.  I hadn't particularly intended for that to leak into the
patch.

> * Moves the kernel link address back to 0x1800000, which is where it
was
> originally.

Yes, on your advice.

> * Changes a few #definitions to to with processor and machine type
with
> no overall
>       effect, especially the processor definitions.
>       Do you really understand the meaning of the __arm2__ __arm3__
> etc *compiler*
>       definitions?

Yes.  gcc 2.8 doesn't define __arm2__ or __arm3__ if you give it the
-mapcs= and -mcpu= options, so with the old #ifdefs you ended up getting

support for no CPUs at all.  You do still get __arm3__ defined with -m3,

but you also get complaints about this being an obsolete option.

> * Removes *all* support for the binutils currently supplied with the
ARM
> Linux
>       distribution.

Since the support was 50% gone already, this strikes me as little
hardship.  The binutils with this problem fixed has been available for
months.

> *     Removes the floppy code's ARM architecture dependence.

Why, exactly, do you feel this is bad?  I'm slightly confused as to
which
patch you're talking about here.  The one I had last week removed the
architecture dependence, and your reaction to that was "good".
Unfortunately I goofed slightly and the result wouldn't compile
properly (and I left out some debug stuff).  This newer patch remedies
that; I don't understand your objection.

> * Slightly optimises the __xchg() function in terms of memory data
> space.

... and, more importantly, allows you to compile armksyms.c on a5k
machines.

> * Unnecessarily changes the decompressor code.
>       If your compiler can't hack that, then throw it away - it's not
ANSI
>       conformant, and must be broken.

It's gcc, and I don't know of any alternative.

> *     Various spelling corrections.
I can't see that they do any harm either, though I agree that the world
won't end without them.

> In effect, what Phil is trying to do is to remove as many changes as
> possible to the driver code that has moved from the drivers
directories
> to the arch/arm/drivers heirarchy.

That's true, and last time I posted a patch to do this you were all in
favour.

> What is the point in reversing some of the changes made to *improve*
the
> performance of the 2.0 kernels when we're moving towards the 2.1
> kernels?

Because the fewer gratuitous changes we have, the less work there is to
do
with the merge.  If you want to fix 8390.c to go faster, then since it's

not an ARM specific change there's no need to make another copy of the
file.

> There have been *no* bug fixes in this patch whatsoever, in fact,
there

If that's your opinion, fine.  Merry Christmas, by the way.

unsubscribe: body of `unsubscribe linux-arm' to [email-masked]