lkml.org 
[lkml]   [1997]   [Jul]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.0.31 : please!
On Wed, 16 Jul 1997, Russell Coker - mailing lists account wrote:

> That is a fair comment. However I believe that we could do with some
> serious effort to ensure that things don't get broken in the course of
> adding new features. I don't think that a 2.1.x release should be held up
> because of this, however if a serious testing effort was applied to the
> pre-patches it would provide a list of things that need work. Then
> hopefully most of these issues would be fixed before the full releae of the
> 2.1.x version.

[snip]

> I believe that I have proved that it is impossible to test all
> combinations of kernel options. But I believe that if we test a reasonable
> number of kernels then we can discover (and therefore fix) bugs that might
> otherwise hang around for ages. One reason for doing this in the
> development kernels is that it's easier to keep track of what you're doing
> if you do it all at once. Some people such as Alan Cox and Dave Miller
> work on many different parts of the kernel. If they were politely informed
> that a new feature they had added had broken something else shortly after
> the release of the code then I'm sure that they would be able to either fix
> the problem or give some background information that allows a less skilled
> programmer to fix it with a minimum amount of effort. However if the bug
> goes undiscovered for 6 months because no-one tries compiling a certain
> combination of modules (or whatever the trigger is) then they are likely to
> require much more work to fix it.

By defining even more levels of "official" release policy, you are running
the danger of blocking the creativity of the biggest contributers to
Linux. In my mind, the model works like this:

The pre patches are an excellent way for the core/key developers to
rapidly exchange their work.

Once Linus (or who-ever) decides that the pre-patches represent some
kind of milestone, or useful amount of work, these are released
as a patch to the 2.1.x tree.

At this point the non-core developers are able to verify that the new work
has not broken something in their contribution(s) or configuration. Note
that at no point is there any guarantee that the code actually compiles -
the development kernel tree represents work in progress.

The distinction between code and non-core developers could be defined as
whether or not you are active enough to try out the pre-patches.

If you follow the mailing list you will get an idea of which kernels
compile, and which ones even seem to be stable.

If you try to impose barriers to what has proven to be a fantastically
development methodology, you are in danger of killing (or maiming) it.

- Dave

\
 
 \ /
  Last update: 2005-03-22 13:39    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site