On Sunday 26 February 2006 01:13, Paul M Foster wrote:
> steve szmidt wrote:
> >
> > The 2.6 kernel got Linux up to be able to compete with the big boys.
> > Linux had finally grown up.
>
> While all of this may be true, it wasn't the point I was making. I don't
> closely follow the kernel lists, but my understanding is that the 2.4
> kernel (and prior) was implemented under a much more plodding,
> methodical paradigm. There was a very specific methodology to the way
> kernel development was shepherded and administered. With the 2.6 kernel,
> Linus changed this so that kernel development could be considered more
> "haphazard" now. That's not really the right word, as it implies more
> randomness than actually exists. But kernel development did change away
> from the more "orthogonal" way in which it was previously administered.
Yes it did change. Very drastically.
The changes with 2.6 are so encompassing that it's hard to casually tell how
fundamentally different it is.
Many of the methods used to develop the Linux kernel are very similar to the
way it was with the 2.4. But these are key changes that has improved overall
stability and quality.
Under the 2.4 there was no real version control except for what each developer
used. Linus did not have a formal version control and source code management,
which led to the implementation of Bitkeeper. (This happend while the 2.5
kernel was being developed.)
Before this change there were often gaping holes between releases where people
did not know what was merged and not. This often resulted in things being
unnecessarily broken.
So the implementation of a central repository has resulted in everyone knowing
exactly what the code status is.
During 2.5 a lot of parallel development occurred with many new teams worked
on support for different areas. This was not the case during previous
kernels.
During the 2.4 kernel there were only around 100 automated tests run on the
kernel, but with 2.5 we got the Linux Test Project which is aimed towards
more organized testing methods. By the time 2.6 was released we had over 2000
tests.
Adding code coverage analysis you can now tell what area of the kernel that
does not have a test, which can then be developed.
Then thanks to Bitkeeper nightly regression testing made it possible for
developers to see what effect their changes had without having to wait for
another release to be made.
Bug tracking has improved as much and it's pretty straight forward to post,
assign and track bugs.
Maybe you got the idea from the fact that now you have a lot more people
working on and submitting changes than was ever made under 2.4. That could
give a false impression that it's not as stable.
The 2.6 kernel offered such an improvement that it attracted a lot more
developers. Fortunately their work can all be done in parallel, with full
version and bug control and testing, resulting in a much improved kernel.
--Steve Szmidt
"For evil to triumph all that is needed is for good men to do nothing. Edmund Burke ----------------------------------------------------------------------- This list is provided as an unmoderated internet service by Networked Knowledge Systems (NKS). Views and opinions expressed in messages posted are those of the author and do not necessarily reflect the official policy or position of NKS or any of its employees.
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 18:53:17 EDT