On Thu, 25 May 2000, Johannes Erdfelt wrote:
>On Thu, May 25, 2000, Ricky Beam <jfbeam@bluetopia.net> wrote:
>> inclusion of the ia64 arch code despite not one
>> physically available system for using it;
>
>This is incorrect. There are many ia64 development systems. Not to
>mention that production machines will almost definately be available
>long before 2.6 is released (based on past development timelines).
At the time of inclusion, there were _very_ few _prototypes_ in hardware.
Just look at some of the traget systems for ia64... notice the cpu simulators.
They are still prototypes. The only people with ia64 hardware are the
people sending Linus the patches in the first place. They do not
belong in 2.4; they are not stable and only add unnecessary "bloat" to
an already huge source tree. No one has said ia64 could not be rolled into
2.4 from the 2.5 development tree -- in fact 2.2 has gained several things
in this manner.
>Also, look at the number of changes that were made outside of arch/ia64.
>I think I can count them all on one hand and they were all bug fixes. Do
>you realistically think this affects stability of say, an x86 system?
This is irrelevant. There was a code freeze and then a substantial amount
of new (completely new) code was added to the tree. I don't care if a 9M
patch contains 3k of bug fixes in there somewhere. And what might seem
like "nothing" can (and does) certainly break other less obvious things.
For example, the keyboard routines haven't been changed lately, yet somewhere
around -pre6, the keyboards on all my machines began to malfunction (it's
transmitting information to the keyboard correctly -- as if the clock was
not running during transmit.)
>> inclusion of devfs with a default
>> of mounting over /dev at kernel startup;
>
>This is incorrect as well. It is not the default.
At the time it was included, it was the default. Only recently was that
behavior changed -- there are people bitching on both sides as usual.
>> /var/shm... If one continually
>> dicks with the tree, then nothing will ever reach a point where it can be
>> labeled as "tested and stable" or ever approach "bug free".]
>
>I have to agree here. However, some of your examples were poor.
Not at all... it doesn't matter _what_ one sticks into the tree; it is the
fact that it was pushed into the tree at all. The purpose of a code freeze
is to stablize what's there in preparation for release. Most software
development has multiple branches of development occuring at all times.
When the code is frozen for release, then you STOP ADDING THINGS and start
aggresively testing and FIXING things. (If it's not going into the shipped
product then it doesn't belong in the tree.) Where I work, if a developer
checks in a new feature after code freeze without authorization, he gets
yelled at and we remove (read: destory) what was checked in.
IMO, the instant 2.3 was "frozen", 2.5 should have been opened for business.
Fix what needs to be fixed in 2.3 and add whatever wasn't submitted prior
the freeze to 2.5.
2.4.0 (gold) will still have problems (I'm betting quite a few.) Many people
will be moving to 2.4.0 from 2.2 -- this will be the first "new" kernel
they try out on their hardware. 2.3 has certainly seen a broad array of
hardware, but it's only a very small fraction of the machines running linux.
(I, for example, still have a machine running 1.2.13!)
BTW, some people might be surprised when their specific keyboard doesn't
work well with the driver in 2.3 (I don't think the changes crossed over to
2.2.)
And let's not forget... alot of 3rd party vendors aren't going to touch 2.3
until it reaches the golden "2.4.0" - period. It's a bad idea to invest time
in shooting at a rapidly moving target.
--Ricky
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:15 EST