lkml.org 
[lkml]   [1999]   [Sep]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Accountability
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.

> 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.

> 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.

> 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..

> 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?

> 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..

> 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. 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.

--
Horses are forbidden to eat fire hydrants in Marshalltown, Iowa.

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.059 / U:0.584 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site