Messages in this thread | | | Subject | Re: Accountability | Date | Wed, 15 Sep 1999 12:26:30 +1000 | From | Colin McCormack <> |
| |
> On Wed, Sep 15, 1999 at 09:44:52AM +1000, Colin McCormack wrote: > >> 1) The mailing list linux-kernel *is* the change repository. >> >> This is precisely how comp.sources.minix worked, all those years ago: if you >> followed the newsgroup you knew everything there was to know about Minix, if >> you didn't you knew nothing. > > I'd disagree. We have a load of stuff in linux/Documentation/*. What's there > is pretty good, the problem is the stuff that's missing. I'm sure patches from > you to add stuff to that directory would be welcomed.
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/
| |