Re: Plain 2.4.5 VM... (and 2.4.5-ac3)

[Mike Galbraith]

On Wed, 30 May 2001, Vincent Stemen wrote:

> On Wednesday 30 May 2001 01:02, Mike Galbraith wrote:
> > On Tue, 29 May 2001, Vincent Stemen wrote:
> > > On Tuesday 29 May 2001 15:16, Alan Cox wrote:
> > > > > a reasonably stable release until 2.2.12.  I do not understand why
> > > > > code with such serious reproducible problems is being introduced
> > > > > into the even numbered kernels.  What happened to the plan to use
> > > > > only the
> > > >
> > > > Who said it was introduced ?? It was more 'lurking' than introduced.
> > > > And unfortunately nobody really pinned it down in 2.4test.
> > >
> > > I fail to see the distinction.  First of all, why was it ever released
> > > as 2.4-test?  That question should probably be directed at Linus.  If
> > > it is not fully tested, then it should be released it as an odd
> > > number.  If it already existed in the odd numbered development kernel
> > > and was known, then it should have never been released as a production
> > > kernel until it was resolved.  Otherwise, it completely defeats the
> > > purpose of having the even/odd numbering system.
> > >
> > > I do not expect bugs to never slip through to production kernels, but
> > > known bugs that are not trivial should not, and serious bugs like
> > > these VM problems especially should not.
> >
> > And you can help prevent them from slipping through by signing up as a
> > shake and bake tester.  Indeed, you can make your expectations reality
> > absolutely free of charge, <microfont> and or compensation </microfont>
> > what a bargain!
> >
> > X ___________________ ;-)
> >
> > 	-Mike
>
> The problem is, that's not true.  These problems are not slipping
> through because of lack of testers.  As Alan said, the VM problem has

Sorry, that's a copout.  You (we) had many chances to notice.  Don't
push the problems back onto developers.. it's our problem.

> been lurking, which means that it was known already.  We currently

Yes, it has been lurking (imho. do some work, and you'll not be able
to avoid developing an imHo.  the more work you do, the larger font
you'll want to use for the H)

> have no development/production kernel distinction and I have not been
> able to find even one stable 2.4.x version to run on our main
> machines.  Reverting back to 2.2.x is a real pain because of all the

So work on it.

> surrounding changes which will affect our initscripts and other system
> configuration issues, such as Unix98 pty's, proc filesystem
> differences, device numbering, etc.
>
> I have the greatest respect and appreciation for Linus, Alan, and all
> of the other kernel developers.  My comments are not meant to
> criticize, but rather to point out some the problems I see that are
> making it so difficult to stabilize the kernel and encourage them to
> steer back on track.

Me too.. but my comment stands.  You can make a diference.

> Here are some of the problems I see:
>
> There was far to long of a stretch with to much code dumped into both
> the 2.2 and 2.4 kernels before release.  There needs to be a smaller
> number changes between major releases so that they can be more
> thoroughly tested and debugged.  In the race to get it out there they
> are making the same mistakes as Microsoft, releasing production
> kernels with known serious bugs because it is taking to long and they
> want to move on forward.  I enjoy criticizing Microsoft so much for
> the same thing that I do not want to have to stop in order to not
> sound hypocritical :-).  The Linux community has built a lot of it's
> reputation on not making these mistakes.  Please lets try not to
> destroy that.
>
> They are disregarding the even/odd versioning system.
> For example:
> There was a new 8139too driver added to the the 2.4.5 (I think) kernel
> which Alan Cox took back out and reverted to the old one in his
> 2.4.5-ac? versions because it is apparently causing lockups.
> Shouldn't this new driver have been released in a 2.5.x development
> kernel and proven there before replacing the one in the production
> kernel?  I haven't even seen a 2.5.x kernel released yet.
>
> Based on Linus's original very good plan for even/odd numbers, there
> should not have been 2.4.0-test? kernels either.  This was another
> example of the rush to increment to 2.4 long before it was ready.
> There was a long stretch of test kernels and and now we are all the
> way to 2.4.5 and it is still not stable.  We are repeating the 2.2.x
> process all over again.  It should have been 2.3.x until the
> production release was ready.  If they needed to distinguish a code
> freeze for final testing, it could be done with a 4th version
> component (2.3.xx.xx), where the 4 component is incremented for final
> bug fixes.

Sorry, I disagree with every last bit.  Either you accept a situation
or you try to do something about it.

	-Mike