> >>2) Only patches to unstable kernels will ever be considered for inclusion in
> >> a kernel.
> >>
> >> Not unreasonable, when you think about it, but not obvious either, unless
> >> you read this mailing list.
> >
> > Well, yes, pretty obvious to most people I think. I've actually dug up the
> > linux-kernel FAQ, and it does define what a 'production kernel' is. Of course,
> > if your patch fixes a bug in the stable kernel, then I'm sure it would be
> > considered.
>
> I wonder if my epckpt author knew it? Somehow I doubt it.
>
> 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.
For this to happen, you have to assume that nobody else is working on the
stable kernel. Exactly one patch, then, can be developed against the
stable kernel. Why the hell should it be yours?
And then, once your checkpointing patch has been folded into 2.even, you
have to get it put into 2.odd as well, or it disappears under the next
stable kernel.
> Whether the requirement of patching the development kernel's a good or
> bad thing, I have no opinion. I merely make the point that it's not
> clear to someone who's only *secondarily* interested in patching the
> kernel, and primarily interested in providing functionality which
> properly or necessarily belongs in the kernel.
Firstly, get it into an acceptable form. If the author isn't prepared to
do it, offer him money, do it yourself, or convince somebody else to do
it (offer me money, for example).
You can't get away from this. Why should Linus/Alan/other kernel patch
hoovers have to merge an old patch without the help of its author?
Secondly, since it does touch on core code and functionality, collect
evidence that it works. Get the maintainers of the subsystems which it
affects to OK it.
Third, at an appropriate time (ie. not during feature/code freeze) offer
it up to Linus. Again, for a non-trivial patch which affects core
functionality, show evidence (or at least claim) that it will be
maintained and fixed in a responsible and timely manner.
There's nothing particularly complicated about this. IMO, only someone
who has never worked on a non-trivial piece of software could think that
this process is opaque.
Matthew.
-
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/