On Thu, May 25, 2000, Ricky Beam <jfbeam@bluetopia.net> wrote:
> 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.
Actually, I'm one of those people with systems. I worked on the ia64
port. Why don't we get it easy?
> They do not belong in 2.4
Whoa there. Linux is open development, right? I suggest you talk to
Linus before making statements like that.
> they are not stable
Umm, huh? Have you ever run it?
> and only add unnecessary "bloat" to an already huge source tree.
It's going to go in anyway, why not now?
> 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.
Which brings me to my next point...
> >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.)
Ask Linus what he thinks a code freeze means. New drivers are alright.
That would cover ia64 as well.
Now, if you ask me if he broke the code freeze, I'll say yes. I never
disagreed there.
> >> 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.
So you have no point.
> >> /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.
You're preaching to choir. Did you read the part where I said "I have to
agree here"?
The point of my email was to clear up the inaccuracies of some of the
examples. Please don't read into it any further than that.
JE
-
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