Linux-kernel mailing list archive 1999-37,: Re: Accountability

# Re: Accountability

Sean Hunter (sean@uncarved.co.uk)
Wed, 15 Sep 1999 09:29:33 +0100

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: bill@taniwha.org: "Re: Serial mouse `driver'"
- Previous message: Orin Eman: "Re: High Performance I/O stuff (more)"
- In reply to: Colin McCormack: "Re: Accountability"

On Wed, Sep 15, 1999 at 09:44:52AM +1000, Colin McCormack wrote:
> In reading Steve Dodd's post, among others, a few key realizations occurred,
> for me.
>
> 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.

Quelle suprise. If I want to know about 'Hamlet' then I have to read
'Hamlet'. If I want to know about the ongoing linux kernel
development, then I have to read the linux-kernel development list.
There are books, articles, commentaries in abundance about both
things, but there's no substitute for the real thing.
> 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.

Also not true. Features go into unstable kernels, patches for
bugfixes can go against either kernel series. Its in the FAQ.
> 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.

You really should try reading the FAQ before you post this kind of
stuff. The fact is, that it is documented and you just haven't
bothered to take the trouble to read it. "How to submit a patch" at
http://www.tux.org/lkml/#s4-1 might be a good place to start in this
instance. You could supplement that with a look through the mail list
archives.

>
> You can predict a lot from this and a few subsidiary observations.
>
> 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.

Explain, breifly, what a non-kernel-centric patch to the linux kernel
might be.

Its also probably a good thing that only kernel-focussed people
contribute to the kernel. Kernel programming is a pretty tricky
business. If I'm flying, I'd rather have the plane serviced by
someone airplane-centric. If you want a reliable kernel, patches have
to be submitted by people who know what they're doing. Following the
kernel list is a good way to start to know and understand the kernel.
You also see what the really knowlegable guys have to say about
various things. This is useful to determine what kinds of things will
get accepted and so on.

> 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. The traffic flow in the main list will swamp anything that's
> not primarily focused on the kernel.

Hmm. A lot of these so-called spin-offs have spun off for a long
time. Furthermore, people regularly discuss memory management etc on
the main list. Lastly, these spinoffs have to feed something back to
Linus and/or Alan if they want it in the official 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.

CVS was tried, and proved unusable for Linus. IIRC he felt the deltas
became too large for him to personally check all the code, and it was
difficult to maintain quality. There was a pretty big falling out
over this issue. Part of the problem is that many teamworking tools
are built for use in small teams, and really don't scale to
contributions from thousands of developers very well. Larry Mc Voy is
working on a major new revision system called BitKeeper, which he has
tailored to Linus et al's preferences on the way. It is waiting in
the wings to be used.

The question about scalability of development tools is also why
patches have to be submitted in the right format and to the right
people. Recieving 1000's of emails every day makes Linus and Alan
pretty quick with the ol "delete" key. If they go away, their inboxes
get swamped. For these reasons they work on the assumption that
people will resend patches until they get included or discussed. The
FAQ (and many other things) more eloquently than I. Its URL is on the
bottom of every submission to the list.

Sean

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

- Next message: bill@taniwha.org: "Re: Serial mouse `driver'"
- Previous message: Orin Eman: "Re: High Performance I/O stuff (more)"
- In reply to: Colin McCormack: "Re: Accountability"