> > 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.
Fine, we'll take your example. Apologies if this looks like I'm dis'ing
or misrepresenting the GGI people.
> Nobody seems to know quite what happened to it.
Unless something has changed since I last looked at GGI a couple of months
back, they are not claiming that their code is ready for kernel inclusion.
> Not even people arguing on your side can articulate the reasons
> clearly.
Here's a selection:
* they never produced a useful, stable kernel addition
* (to the best of my knowledge) they never submitted complete patches to
Linus
* they took so long in doing this, that a bunch of other guys beat them
to it
* their sources are packaged in such a way that I need to patch a
non-current kernel, _and_ fight their quirky build system
> That's reasonable evidence of non-transparency.
Maybe on Monday you had a good reason for claiming non-transparency, but
the very first response to your post was from Alan Cox, who explained
exactly what to do to get the patch integrated.
> 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?'
OK, I'll bite. "Probably."
It "probably" comitted one or more of the following sins:
a) was formatted in an ugly manner
b) was encoded inconveniently
c) was submitted against a stable branch, or during a feature or code
freeze
d) was submitted as a patch against an obsolete kernel and didn't merge
trivially with the current one
e) affects core code (and thus potentially both performance and
reliability) and
+ made it look ugly
+ was not able to be configured out
+ was a portability disaster
f) looked like crappy code
g) looked hacky
h) was not considered a useful, desirable or worthwhile feature
i) was not submitted at all
(I just need one more for a full 10 Commandments)
>From my brief inspection of the 2.2.1 release, I suspect it to be guilty
of b,c,e and maybe even d. It probably didn't do a and i. The rest (f,
g and h) I don't know/haven't read enough to comment on, but nobody who
has been following Linux kernel development would claim that it looked in
a worthwhile state for Linus' approval if it violated nearly half of
these.
> 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.
The development of epckpt is rather opaque to us. Most of us haven't used
it, many of us haven't even heard of it. Why should Alan throw a few
hundred k of new code into a stable branch when the maintainer won't even
provide a patch let alone one against a stable kernel?
If "edpin" won't merge Linus' patches, why should Linus merge his?
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/