> 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.
I'm not offering to implement anything, correct. The code in question's been
implemented. I leave wheel reinvention to others.
> 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?
This really doesn't follow. Not all modifications are global in their impact,
and therefore many patches could coexist simultaneously without interference.
Additionally, if the kernel version control tools extended beyond majordomo,
sendmail and an editor, it would even be conceivable for people to check out
those branches they decided were suitable for their application.
> 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.
Or you regenerate it for the next 2.even, as this may be less effort.
>> 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).
What's acceptable is purely subjective. Another good reason for a
post-distribution distribution. Many of us do it anyway, for significant and
useful functionality which hasn't found its way through the `input filtering'.
> 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?
That's not what's being suggested. The question posed was more like: why are
authors expected to operate with no feedback in generating new patches.
> 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.
Forget it. There's a point beyond which it's not worth arguing, but easier to
get off and do 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.
If you took the time to read the posts in this thread, you'd see that the
patch has apparently been `offered up to Linus' on several occasions, without
what was apparently effective feedback.
At the moment it seems to me that people just abandon the process in despair.
If nothing else, my part in this conversation is to suggest that a
non-despairing alternative might be needed, possible, and even feasible.
> 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.
Of course the process is opaque, in parts. Its opacity has nothing to do with its complexity, but with some subjective and non-transparent aspects of the process.
I'll give you an example: GGI. Nobody seems to know quite what happened to it. Not even people arguing on your side can articulate the reasons clearly. That's reasonable evidence of non-transparency.
The author of the piece of code I am interested in has no idea why the code didn't get incorporated. That's not a transparent process. If, in fact, it's because the patches were against 2.even, then a simple email to that effect may have saved him time, and may have given us useful functionality.
I asked a simple question in my initial post: `Is there a good reason, or indeed any reason, why epckpt isn't in the kernel right now?'
I still haven't got a clear answer to it. I don't know, you don't know, Alan Cox doesn't say (who knows if he knows, or ever knew) ... nobody knows. It's not a transparent process.
At least we can be clear about *that*.
Colin.
-
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/