Re: Accountability
Arthur (pkobly@calgary.crosswinds.net)
Wed, 15 Sep 1999 13:04:27 -0600 (MDT)
> On Wed, 15 Sep 1999, Colin McCormack wrote:
> > On Wed, 15 Sep 1999, Matthew Kirkwood wrote:
> > > On Wed, 15 Sep 1999, Colin McCormack wrote:
> > >> What we end up with is this: anyone who needs (as distinct from
> `wants',
> > >> in a linux-kernel mailing list way) to add functionality to the
> kernel
> > >> would like to add it to the stable kernel.
> > > [ snip list of reasons that people like to work against the stable
> kernel ]
>
> > > So, in essence what you're saying is that you'd like (by proxy - I
> note
> > > that you're not offering to implement anything) to work against a
> kernel
> > > which isn't changing much.
>
> > Yes, in effect I think I'm saying unit testing is easier against a
> stable
> > backdrop.
>
> There is no reason why one cannot do initial development against a stable
> kernel. However, once the patch works to the developer's satisfaction, it
> is incumbent upon him to port it to the development series if patches
> to it are being accepted or to wait for the next one.
>
> For example, if a patch for a new or enhanced feature were developed
> against 2.2.0 through 2.2.7, it would be necessary to wait for the
> release of 2.2.8/2.3.1 so that the patch could be submitted against 2.3.1.
> If the patch were developed against 2.2.8 through 2.2.11, it should have
> been ported to 2.3.x for submission. With 2.2.12, it is now too late, as
> Linus has declared a (long expected and arguably overdue) feature freeze
> with 2.3.18, so any new features must wait for 2.5.1. So the right thing
> to do with a feature patch such as the one you are advocating is to port
> it to 2.3.18 and maintain it until 2.5.1 is released. Then submit it. In
> the meantime, see if the maintainer of the relevent section of the kernel
> will provide you feedback on it. Just don't expect it to be accepted until
> 2.5.1.
It is important to understand _WHY_ a stable kernel is _always_ under feature
freeze. From his previous posts, I don't believe Colin understands this. The
reason that a development kernel is often unstable is that there are no
features going into it. Stable kernels are stable because there are no new
features going in.
New features add risk. Bug fixes decrease risk. It is untenable to say that
we should be increasing risk on a stable kernel. Thus it is untenable to say
that we should be adding features to stable kernels.
PK
-
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/