I'm thinking of a `what you really need to know to get a patch considered' web
page.
>>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.
1) because they're doing something else that depends on the patch, and they
don't need extra worries from the (presumed) instability of the development
kernels.
2) because they'd like to be working with somewhat more stable versions of
internal data structures (to the extent they need to dick with them.)
3) because their consumers are likely to be running a stable kernel, that's
their target.
It's not at all immediately obvious to someone who wants to do something that,
perforce, relies upon kernel mods, that the development kernel is the place to
start looking.
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.
This conversation's cleared it up for me.
>> 3) The patch submission process is ad-hoc and informal.
>>
>> Or, perhaps, it seems that way to someone who's not actually primarily
focused
>> on the kernel. Over time rules of thumb have arisen such as whom not to
>> flame, what format to submit patches in, which ideas are `hot' and which
will
>> languish.
>
> Ish. The prefered format for patches is mentioned in the (ancient) copy of
> the lkml FAQ I'm looking at. The "MAINTAINERS" file in the root of the source
> tarball describes pretty accurately a good process for creating, testing and
> submitting patches.
I'll have a look.
>> First: only kernel-centric patches will flourish, because only people who
>> follow the group will be able to negotiate the caucus, and only people who
are
>> primarily focused on the kernel will bother.
>
>I'm not sure what you mean by "kernel-centric". This is the kernel mailing
>list, of course patches are going to focused on the kernel, we don't do
>anything else here..
I think I mean patches motivated by a desire to extend the kernel, or improve
the kernel for its own sake, rather than patches intended to add functionality
to userland for which kernel space mods is considered necessary.
I'm not speaking authoritatively in this, but it seems to me that e.g. GGI
were aiming to solve a user problem, and were rejected because they offended
some ethos in kernel-land. The frustration and bitterness arose, I would say,
because of a difference in the primacy of values. GGI: We want this
functionality, it must be in kernel space to work. Kernal: it makes the
kernel ugly and bloated, or vaporous, or not crispy enough, or whatever you
guys use as the unit of niceness.
As someone who doesn't admire monolithic kernel `crispiness', I'm pretty well
on the GGI guys' side, because the utility offered exceeds the (nominal)
disutility of code which doesn't conform to a standard I don't value.
My point is: there's useful userland functionality going begging because the
kernel group values it lower than some fad gadget tweak. If the userland
functionality makes a difference, that's a centrifugal force.
>> Second: any kernel functionality which forms a sufficiently large and
modular
>> chunk will have to spin off and use its own resources, as has happened with
MM
>> and with ISDN.
>
> To a certain extent, yes, in as far as those areas create their own mailing
> lists and web pages. Is that a problem?
It's only a problem when they try to synch the mods back in, apparently, or
when then claim they're doing their own QA and ask that it be valued.
>> The traffic flow in the main list will swamp anything that's
>> not primarily focused on the kernel.
>
> Anything that's not focused on the kernel is off-topic. Hence the name of
> the list..
I'll rephrase: anything not primarily motivated by a desire to hack the
kernel.
>>Third: the kernel list won't ever see a real pressing need for a CVS because
>>they're comfortable with the list's use as a patch repository.
>
> A lot of people use some sort of source control privately though. And Larry
> McVoy has been working very hard to produce a distributed source control
> system that meets Linus' requirements. Anybody's free to use CVS to keep
> the kernel source code, and I believe DaveM and the Sparc people do so.
Sure. It comes down to perceived cost/benefit, I guess. All strength to
Larry McVoy in his quest. It'd be very useful.
> Linus'
> won't because he doesn't want to. I don't see anyone has the right to tell him
> how he should manage his tree.
Wouldn't matter if they had the right. They don't have the ability. Which's
why I found the treatment of the ISDN people heavy handed, uncooperative,
peremptory, arrogant, unconstructive. (pick your adjective.)
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/