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.
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.
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 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.
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.
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.
Colin.
> On Wed, Sep 15, 1999 at 03:11:56AM +1000, Colin McCormack wrote:
>
> > > A suitable fashion means someone submits it to Linus and promises to maintain
> > > it and fix it.
> >
> > Is this documented somewhere?
>
> Not "formally". But every now and then Linus or someone else posts something
> to linux-kernel that elaborates on what they like to see done. I dimly recall
> that there may also be something in the FAQ about it - have you read it?
>
> > From one marketing front man to another:
>
> Assuming you addressed this to Alan, I certainly don't regard him as a
> 'marketing front man' particularly. I don't know whether he does, but I doubt
> it somehow.
>
> > I respect your desire to keep the
> > brand name pure, but what's in a number?
>
> Well, for starters, the patchlevel (middle number) tells you whether it's
> a stable version or not. You generally won't get new core features (i.e.
> something that affects other code) into a stable release.
>
> > Something for real marketing front men to put on a press release?
>
> I guess the main version number (left-most) is kind of like that.
>
> > What'd be really nice would be a system where people could directly submit
> > branch material
>
> If you mean, "submit material for a non-standard branch", then just create
> a mailing list for the non standard branch, get people interested in said
> branch to join it, and bob's your unicorn.
>
> >, others could selectively check out branches,
>
> Nothing to stop people publishing non-standard branches. Alan does it, and I
> think Andrea has periodically as well. And of course there are the ELKS people,
> and so on.
>
> > and still others could (if they wished) re-join the branches.
>
> Anyone who's got the source to both branches can do this.
>
> > Linus could bless branches, so could you, but people should be able to roll
> > their own to a much greater extent, if Linux is to maintain any kind of
> > growing edge.
>
> The kernel's GPL'd. Anyone can roll their own branch, and distribute it. This
> is in fact what the distribution vendors do. Admittedly they don't tend to
> deviate much, but that's not really relevant.
>
> > Another lesson from history is the gcc/egcs development. I'd say Linux's in
> > the balance now, but if I were intimately involved with the kernel, I'd be
> > open-sourcing it as quickly as possible.
>
> It /is/ "open-sourced" (ugh); that is, it's GPL'd and as such complies with
> the OSI's open source definition and the DFSG, which are pretty much the
> de-facto standards for the definition of "open source".
>
> Can we drop this now? Or at least go to email?
>
> --
> There are many intelligent species in the universe. They all own
> cats.
>
>
-
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/