RE: The direction linux is taking

RE: The direction linux is taking

[Dana Lacoste]

> 1. Are we satisfied with the source code control system ?

Yes.  Alan (2.2) and Marcelo (2.4) and Linus (2.5) are doing
a good job with source control.

The fact the 'source control' is a person and not a piece
of software is irrelevant.

> 2. Is there enough planning for documentation ? As another
> poster mentioned, there are new API and we dont know about
> them.

Although this seems annoying, it's just one facet of the
primary difference between Linux and a commercially based
kernel : if you want to know how something works and how
it's being developed, then you MUST participate, in this
and other mailing lists.

I, for example, don't particularly care about the structures
that define the block interfaces in the kernel : I don't use
them.  I do, however, care about networking things, so I follow
linux-kernel and linux-net (and several other lists) to make
sure I'm up to date.  I am applying an inherent trust in the
people developing the block code, trusting that they will do
a good job and have a stable platform for my networking needs :)

> 3. There is no central bug tracking database. At least people
> should know the status of the bugs they have found with some
> releases.

There is no central product, so there can be no central bug track.
(see below)

> 4. Aggressive nature of this mailing list itself may be a
> turn off to many who would like to contribute.

You're missing something again.

I think this is a FAQ, so maybe we can develop a form response
here.  Feel free to edit the following :

What is Linux?  (The LKML definition)
Linux is a free, open source kernel that is used by many people
as the center for their operating system.  The operating system
as a whole is NOT Linux.  Linux is just the kernel.

"RedHat Linux" is an example of an entire operating system that
uses the Linux kernel and adds lots of other software around it
to make an entire operating system.

Similarly, Lineo makes an embedded product that starts with the
same kernel code.  It doesn't target ANY of the same users that
RedHat Linux targets, but that doesn't make it any less significant.

Why is this distinction important?  Because in LKML we are not
trying to define the way that the kernel is used, we are not
trying to take over the desktop world, we are not trying to
take over the supercomputing world, and we are not trying to
become the next microsoft.  We are trying to make the best
kernel available, and that means that we support dozens of
different hardware platforms and thousands of different
operating environments.

LKML is a place where lots of developers who work on the Linux
kernel talk about different things (usually) pertaining to the
kernel source code and ways of improving it, by bug fixing, by
feature additions, or by code/API re-writing.

If you've worked in a pure development environment then you have
probably observed that people with ideas can become quite vocal
when defending their ideas, and because LKML is email based we
probably seem to be more, ah, vocal than most.  If you can't
handle this kind of environment, then stick to Kernel Traffic.
(http://kt.zork.net/)

Does that answer your question?

Dana Lacoste
Linux Developer
Ottawa, Canada

Re: The direction linux is taking

[Alan Cox]

> > 1. Are we satisfied with the source code control system ?
> 
> Yes.  Alan (2.2) and Marcelo (2.4) and Linus (2.5) are doing
> a good job with source control.

Not really. We do a passable job. Stuff gets dropped, lost, 
deferred and forgotten, applied when it conflicts with other work
- much of this stuff that software wouldnt actually improve on over a 
person

> Although this seems annoying, it's just one facet of the
> primary difference between Linux and a commercially based
> kernel : if you want to know how something works and how
> it's being developed, then you MUST participate, in this
> and other mailing lists.

That wont help you - most discussion occurs in private because l/k 
is too noisy and many key people dont read it.

> > 3. There is no central bug tracking database. At least people
> > should know the status of the bugs they have found with some
> > releases.
> 
> There is no central product, so there can be no central bug track.
> (see below)

Rubbish. Ask the engineering world about fault tracking. You won't get
"different products no central flaw tracking" you'll get extensive cross
correlation, statistical tools and the like in any syste, where reliability
matters

Many kernel bug reports end up invisible to some of the developers.

Alan

Re: The direction linux is taking

[Dead2]

> > > 1. Are we satisfied with the source code control system ?
> >
> > Yes.  Alan (2.2) and Marcelo (2.4) and Linus (2.5) are doing
> > a good job with source control.
>
> Not really. We do a passable job. Stuff gets dropped, lost,
> deferred and forgotten, applied when it conflicts with other work
> - much of this stuff that software wouldnt actually improve on over a
> person

What about having the Linux source code in a CVS tree where active/trusted
driver-/module-maintainers are granted write access, and everyone else read
access.
After the patches are applied, people will test them out, and bugfixes will
be applied when bugs are detected.
Then, when the kernel-maintainer feels this or that sourcecode is ready for a
.pre kernel, he puts it in the main kernel tree.
(This would indeed pose a security risk, but who in their right mind would run
 a CVS snapshot on anything important, that's right _noone_ in their _right
mind_)

Of course this would require much maintenance, and possibly more than
one kernel-maintainer. This because of how much easier it would become
for driver-/module-maintainers to apply patches they believe would make
things better. Cleanups would also be necessary from time to time..
(cleanups = making the CVS identical to the main kernel tree again)

Just my 2 cents..

-=Dead2=-

Re: The direction linux is taking

[Ken Brownfield]

The CVS tree availability you mention parallels the FreeBSD tree, I
believe.  However, assuming enough brain cycles, one knowledgable
maintainer seems to be a better method of maintaining a kernel.

Having one person maintain the entire CVS tree for an OS would be
laughable, but in the case of a kernel you have much tighter control
over what goes into a smaller, more delicate tree, with maintainers who
have access to hardware for device driver implementation, etc.
Especially when this person is a Linus/Alan/Marcelo, etc.

I've been following lkml for some time now, and I've been using patches
that get posted to the list.  But I do so at my own risk, since I do not
have comprehensive knowledge of kernel internels.  But even I can tell
that many of the patches posted are either bogus, are potentially
incorrect in subtle and/or complex ways, or are simply working around
user-space issues or other bugs.

There have been discussions on this list (and several off) about how
patches are dropped, ignored, etc.  Part of this is due to what Linus
himself described as a conservative stabilization of 2.4 given VM and
other issues.  I believe the other part is that one person (Marcelo in
this case) will have a hard time taking something as verbose as lkml
(plus the plethora of direct email that he must receive) and weed out
the noise from the signal.  And then possibly having to spend time
finding a maintainer or someone knowledgable about a certain specific
area of the kernel to see if the signal is legitimate.

I think Alan compiled a ton of very useful stuff in the 2.4-ac series,
but (maybe he'll agree with my bs here :) I think 2.2-mainline and
2.4-mainline require different trade-offs.

What might take out a few birds with one stone is to have someone on
lkml become an "LKML MAINTAINER": collect patches and bug reports in a
central place.  This would include:

	1) The patch and/or bug report
	2) The entire LKML thread, with "important" messages marked
	3) Personal input, prioritization, severity info, etc.

This could be a bugtraq type site, or webrt, or something along those
lines.  Something like kernel traffic, but useful. ;-) ;-)

What this gives is a very succinct source of data for the key kernel
developers and maintainers who don't necessarily have time to weed
through lkml -- they can check the web site occasionally, or even fairly
frequently, and spend a very minimal amount of time glancing through for
anything that sounds relevant.

I think this would also be a good place to track which patches make it
into stable vs. development kernels (2.4.x vs 2.5.x right now).  But
this would NOT necessarily have crossover with the maintainers -- this
compilation would be unofficial and for informational purposes only.

This lkml maintainer would NOT be the sole source of lkml output --
clearly the public and direct sharing of patches should continue, but I
think compiling the best bits of lkml is 99% of the battle.

Just my two cents.  If enough of the relevant folks think this is
worthwhile, I might try to set this up (in my free time between 24 and
27 hours a day...) since I'm already doing a small subpart of this for
my own purposes.

Thx,
-- 
Ken.
brownfld@irridia.com


On Tue, Dec 18, 2001 at 04:09:00PM +0100, Dead2 wrote:
| > > > 1. Are we satisfied with the source code control system ?
| > >
| > > Yes.  Alan (2.2) and Marcelo (2.4) and Linus (2.5) are doing
| > > a good job with source control.
| >
| > Not really. We do a passable job. Stuff gets dropped, lost,
| > deferred and forgotten, applied when it conflicts with other work
| > - much of this stuff that software wouldnt actually improve on over a
| > person
| 
| What about having the Linux source code in a CVS tree where active/trusted
| driver-/module-maintainers are granted write access, and everyone else read
| access.
| After the patches are applied, people will test them out, and bugfixes will
| be applied when bugs are detected.
| Then, when the kernel-maintainer feels this or that sourcecode is ready for a
| .pre kernel, he puts it in the main kernel tree.
| (This would indeed pose a security risk, but who in their right mind would run
|  a CVS snapshot on anything important, that's right _noone_ in their _right
| mind_)
| 
| Of course this would require much maintenance, and possibly more than
| one kernel-maintainer. This because of how much easier it would become
| for driver-/module-maintainers to apply patches they believe would make
| things better. Cleanups would also be necessary from time to time..
| (cleanups = making the CVS identical to the main kernel tree again)
| 
| Just my 2 cents..
| 
| -=Dead2=-
| 
| 
| 
| 
| -
| To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
| the body of a message to majordomo@vger.kernel.org
| More majordomo info at  http://vger.kernel.org/majordomo-info.html
| Please read the FAQ at  http://www.tux.org/lkml/

Re: The direction linux is taking (CVS)

[Dead2]

----- Original Message -----
From: "Ken Brownfield" <brownfld@irridia.com>

> The CVS tree availability you mention parallels the FreeBSD tree, I
> believe.  However, assuming enough brain cycles, one knowledgable
> maintainer seems to be a better method of maintaining a kernel.

Then positive and negative sides should be gathered from their experiences
aswell, it can be good for the outcome to follow something that has
been tested thoroughly by others.

*snip*

> I've been following lkml for some time now, and I've been using patches
> that get posted to the list.  But I do so at my own risk, since I do not
> have comprehensive knowledge of kernel internels.  But even I can tell
> that many of the patches posted are either bogus, are potentially
> incorrect in subtle and/or complex ways, or are simply working around
> user-space issues or other bugs.

Therfore only trusted maintainers should have access. Normal deadly
people like me would have to contact the maintainer(s) for that sub-tree.

> What might take out a few birds with one stone is to have someone on
> lkml become an "LKML MAINTAINER": collect patches and bug reports in a
> central place.  This would include:
>
> 1) The patch and/or bug report
> 2) The entire LKML thread, with "important" messages marked
> 3) Personal input, prioritization, severity info, etc.

Or even make a kernel-patches@vger.kernel.org address that would be
parsed manually of automaticly..

*snip-snip*
> --
> Ken.
> brownfld@irridia.com

-=Dead2=-

> On Tue, Dec 18, 2001 at 04:09:00PM +0100, Dead2 wrote:
> | > > > 1. Are we satisfied with the source code control system ?
> | > >
> | > > Yes.  Alan (2.2) and Marcelo (2.4) and Linus (2.5) are doing
> | > > a good job with source control.
> | >
> | > Not really. We do a passable job. Stuff gets dropped, lost,
> | > deferred and forgotten, applied when it conflicts with other work
> | > - much of this stuff that software wouldnt actually improve on over a
> | > person
> |
> | What about having the Linux source code in a CVS tree where active/trusted
> | driver-/module-maintainers are granted write access, and everyone else read
> | access.
> | After the patches are applied, people will test them out, and bugfixes will
> | be applied when bugs are detected.
> | Then, when the kernel-maintainer feels this or that sourcecode is ready for
a
> | .pre kernel, he puts it in the main kernel tree.
> | (This would indeed pose a security risk, but who in their right mind would
run
> |  a CVS snapshot on anything important, that's right _noone_ in their _right
> | mind_)
> |
> | Of course this would require much maintenance, and possibly more than
> | one kernel-maintainer. This because of how much easier it would become
> | for driver-/module-maintainers to apply patches they believe would make
> | things better. Cleanups would also be necessary from time to time..
> | (cleanups = making the CVS identical to the main kernel tree again)
> |
> | Just my 2 cents..
> |
> | -=Dead2=-
> |
> |
> |
> |
> | -
> | To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> | the body of a message to majordomo@vger.kernel.org
> | More majordomo info at  http://vger.kernel.org/majordomo-info.html
> | Please read the FAQ at  http://www.tux.org/lkml/
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: The direction linux is taking

[Dead2]

 > What might take out a few birds with one stone is to have someone on
> > lkml become an "LKML MAINTAINER": collect patches and bug reports in a
> > central place.  This would include:
> >
> > 1) The patch and/or bug report
> > 2) The entire LKML thread, with "important" messages marked
> > 3) Personal input, prioritization, severity info, etc.
>
> Good idea but _who_ will do that?

Just a thought that popped into my head..
What about using some kind of BugTrack system for this?
Where people can report a bug, and file patches for them.
There would indeed be some situations where 2-3-4 maybe
more patches are filed to fix one bug. Then the maintainer
can easily look through the patches and descide what to use..

-=Dead2=-

Re: The direction linux is taking

[Ken Brownfield]

That's one of the specific options I proposed.  I think it would be best
if it were focussed on lkml reports rather than noise from everywhere,
and also if it kept the maintainers' interface as simple and explicit as
possible.  And yes, who is the question that I'm pondering as well.

-- 
Ken.
brownfld@irridia.com

On Wed, Dec 19, 2001 at 10:56:53AM +0100, Dead2 wrote:
|  > What might take out a few birds with one stone is to have someone on
| > > lkml become an "LKML MAINTAINER": collect patches and bug reports in a
| > > central place.  This would include:
| > >
| > > 1) The patch and/or bug report
| > > 2) The entire LKML thread, with "important" messages marked
| > > 3) Personal input, prioritization, severity info, etc.
| >
| > Good idea but _who_ will do that?
| 
| Just a thought that popped into my head..
| What about using some kind of BugTrack system for this?
| Where people can report a bug, and file patches for them.
| There would indeed be some situations where 2-3-4 maybe
| more patches are filed to fix one bug. Then the maintainer
| can easily look through the patches and descide what to use..
| 
| -=Dead2=-
| 
| 
| -
| To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
| the body of a message to majordomo@vger.kernel.org
| More majordomo info at  http://vger.kernel.org/majordomo-info.html
| Please read the FAQ at  http://www.tux.org/lkml/

Re: The direction linux is taking

[Ken Brownfield]

On Wed, Dec 19, 2001 at 09:27:41AM -0200, vda wrote:
| On Tuesday 18 December 2001 16:37, Ken Brownfield wrote:
| > The CVS tree availability you mention parallels the FreeBSD tree, I
| > believe.  However, assuming enough brain cycles, one knowledgable
| > maintainer seems to be a better method of maintaining a kernel.
| 
| As tree gets larger over time, Linus *and* Alan hacking on the single tree in 
| CVS ought to be more productive than regular time consuming syncs between 
| Linus and -ac trees (but requires higher level of mutual trust).

Yes, I agree, this is somewhat along the lines what I mentioned -- a
main maintainer (Linus in this case) has their own CVS tree that they
can have specific people work on.  This example would be for the entire
kernel, and as you say trust would be required.  The number of people in
this specific case would be countable on one hand (or perhaps two
fingers), whereas instances of tree sharing within sub-parts of the
kernel could be wider and looser.

My only negative reaction would be a single kernel tree shared among
many/all developers, like more than two.

-- 
Ken.
brownfld@irridia.com