Tech Insider					     Technology and Trends


			      USENET Archives

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!
ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
X-Originating-IP: [128.107.253.38]
From: "Eyal Sohya" <linuz_kerne...@hotmail.com>
To: linux-ker...@vger.kernel.org
Subject: The direction linux is taking
Original-Date: 	Tue, 18 Dec 2001 05:20:44 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Original-Message-ID: <F25YXU6KJQcxQv8rcyN00007eb5@hotmail.com>
X-OriginalArrivalTime: 18 Dec 2001 05:20:44.0333 (UTC) 
FILETIME=[BE202DD0:01C18783]
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Tue, 18 Dec 2001 05:22:22 GMT
Message-ID: <fa.j6k6viv.b06d2r@ifi.uio.no>
Lines: 25

I've watched this List and have some questions to ask
which i would appreciate are answered. Some might not
have definite answers and we might be divided on them.

1. Are we satisfied with the source code control system ?
2. Is there enough planning for documentation ? As another
poster mentioned, there are new API and we dont know about
them.
3. There is no central bug tracking database. At least people
should know the status of the bugs they have found with some
releases.
4. Aggressive nature of this mailing list itself may be a
turn off to many who would like to contribute.



_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news.tele.dk!
small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!ifi.uio.no!
internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Message-ID: 
<B51F07F0080AD511AC4A0002A52CAB445B2A05@ottonexc1.ottawa.loran.com>
From: Dana Lacoste <dana.laco...@peregrine.com>
To: "'Eyal Sohya'" <linuz_kerne...@hotmail.com>
Cc: linux-ker...@vger.kernel.org
Subject: RE: The direction linux is taking
Original-Date: 	Tue, 18 Dec 2001 06:32:55 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Tue, 18 Dec 2001 14:35:01 GMT
Message-ID: <fa.pjic09v.8msg96@ifi.uio.no>
Lines: 85

> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!
ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Subject: Re: The direction linux is taking
To: dana.laco...@peregrine.com (Dana Lacoste)
Original-Date: 	Tue, 18 Dec 2001 15:04:13 +0000 (GMT)
Cc: linuz_kerne...@hotmail.com ('Eyal Sohya'), linux-ker...@vger.kernel.org
In-Reply-To: 
<B51F07F0080AD511AC4A0002A52CAB445B2A05@ottonexc1.ottawa.loran.com> 
from "Dana Lacoste" at Dec 18, 2001 06:32:55 AM
X-Mailer: ELM [version 2.5 PL6]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Original-Message-Id: <E16GLmv-0007d4-00@the-village.bc.nu>
From: Alan Cox <a...@lxorguk.ukuu.org.uk>
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Tue, 18 Dec 2001 14:56:39 GMT
Message-ID: <fa.gk1l8nv.1g1gupf@ifi.uio.no>
References: <fa.pjic09v.8msg96@ifi.uio.no>
Lines: 39

> > 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!
ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Message-ID: 
<B51F07F0080AD511AC4A0002A52CAB445B2A07@ottonexc1.ottawa.loran.com>
From: Dana Lacoste <dana.laco...@peregrine.com>
To: "'Alan Cox'" <a...@lxorguk.ukuu.org.uk>
Cc: linux-ker...@vger.kernel.org
Subject: RE: The direction linux is taking
Original-Date: 	Tue, 18 Dec 2001 07:18:51 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Tue, 18 Dec 2001 15:21:43 GMT
Message-ID: <fa.pjig09v.8mog96@ifi.uio.no>
Lines: 77

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

So the same result then :
We are 'satisfied with the current source code control system'
because there isn't a way currently available that would allow
for any significant benefit.

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

...but if you are working with the code and you see something change
the mailing list is the place to ask, correct?

What I'm saying isn't so much that the mailing lists are complete,
but that you have to keep current with the community if you want to
keep current with its work.

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

Many kernel developers don't read LKML.
Isn't that their flaw?

Many bug reports don't end up in the right place.
(i.e. a Sparc patch on the LKML but not the Sparc-Linux mailing lists)

How is a central bug repository going to help?

For example. Red Hat's knowledge base is a piece of crap.  It's
impossible to find anything because of the millions of variations
on different products.

You can't maintain a central bug repository for separate product
streams (Red Hat's kernel vs. "Stock" vs. Suse vs. VA, etc)
because there's too many variables.  If you want a centralized
bug tracking system then you MUST use the same product or it
will end up tracking end-user bugs instead of developer bugs
because the developers won't use it.

I sincerely challenge you to propose a method for centralizing
bug tracking in the Linux kernel that _can_ be used by the
community as a whole.  That means something that Linus would use
_and_ somebody who doesn't subscribe to LKML can use to find out
why he can't compile loop.o on his redhat 7.0 system with the
kernel he got from kernel.org a few weeks ago.

Dana Lacoste
Linux Developer
Ottawa, Canada
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!
ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Subject: Re: The direction linux is taking
To: dana.laco...@peregrine.com (Dana Lacoste)
Original-Date: 	Tue, 18 Dec 2001 19:50:27 +0000 (GMT)
Cc: a...@lxorguk.ukuu.org.uk ('Alan Cox'), linux-ker...@vger.kernel.org
In-Reply-To: 
<B51F07F0080AD511AC4A0002A52CAB445B2A07@ottonexc1.ottawa.loran.com> 
from "Dana Lacoste" at Dec 18, 2001 07:18:51 AM
X-Mailer: ELM [version 2.5 PL6]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Original-Message-Id: <E16GQFw-0008Uh-00@the-village.bc.nu>
From: Alan Cox <a...@lxorguk.ukuu.org.uk>
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Tue, 18 Dec 2001 19:46:38 GMT
Message-ID: <fa.gf2f8vv.166uuh0@ifi.uio.no>
References: <fa.pjig09v.8mog96@ifi.uio.no>
Lines: 29

> > is too noisy and many key people dont read it.
> 
> ...but if you are working with the code and you see something change
> the mailing list is the place to ask, correct?

Or its submitter - thyats why names in changelogs are so important

> > Many kernel bug reports end up invisible to some of the developers.
> 
> Many kernel developers don't read LKML.
> Isn't that their flaw?

Not really. If they read lk they would have no time to fix bugs.

> I sincerely challenge you to propose a method for centralizing
> bug tracking in the Linux kernel that _can_ be used by the
> community as a whole.  That means something that Linus would use
> _and_ somebody who doesn't subscribe to LKML can use to find out
> why he can't compile loop.o on his redhat 7.0 system with the
> kernel he got from kernel.org a few weeks ago.

You don't centralise it. You ensure the data is in common(ish) formats
and let the search tools improve. Would you build google by making all
the web run at one site ?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!
ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
X-Originating-IP: [128.107.253.38]
From: "Eyal Sohya" <linuz_kerne...@hotmail.com>
To: dana.laco...@peregrine.com
Cc: linux-ker...@vger.kernel.org
Subject: Re: The direction linux is taking
Original-Date: 	Sun, 23 Dec 2001 14:13:20 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Original-Message-ID: <F113yeKzGZuNY1SWoBD0000e383@hotmail.com>
X-OriginalArrivalTime: 23 Dec 2001 14:13:20.0356 (UTC) 
FILETIME=[F9771240:01C18BBB]
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Sun, 23 Dec 2001 14:17:30 GMT
Message-ID: <fa.j6bbc1v.1k1qf21@ifi.uio.no>
Lines: 63




>From: Alan Cox <a...@lxorguk.ukuu.org.uk>
>To: dana.laco...@peregrine.com (Dana Lacoste)
>CC: linuz_kerne...@hotmail.com ('Eyal Sohya'), linux-ker...@vger.kernel.org
>Subject: Re: The direction linux is taking
>Date: Tue, 18 Dec 2001 15:04:13 +0000 (GMT)
>
> > > 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.

really ?
Do you know what good source control is ? i doubt it.

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


that is exactly my point.
>
>Alan




_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!
ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Message-ID: 
<B51F07F0080AD511AC4A0002A52CAB445B2A36@ottonexc1.ottawa.loran.com>
From: Dana Lacoste <dana.laco...@peregrine.com>
To: "'Eyal Sohya'" <linuz_kerne...@hotmail.com>
Cc: linux-ker...@vger.kernel.org
Subject: RE: The direction linux is taking
Original-Date: 	Thu, 27 Dec 2001 07:46:32 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Thu, 27 Dec 2001 15:47:55 GMT
Message-ID: <fa.pl2e09v.96qg96@ifi.uio.no>
Lines: 67

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

> really ?
> Do you know what good source control is ? i doubt it.

why do you drop to personal insults?  are your arguments that weak?

i'm a perforce admin.  if you don't know what perforce is, you go
look it up.  i used to be a CVS admin.  i REALLY hope you know what
THAT is.  and i've used clearcase and even SCCS/RCS in the past.

my point wasn't that marcelo and linus and allan are source control
systems.  my point was that if you're looking for a properly source-
controlled project, THEN DON'T USE LINUX AND QUIT YOUR FUCKING WHINING.

(ok, that might be a bit harsh, but there have been quite a few
people here who think that the linux kernel should be maintained
in the same way as a closed source commercially run project. But
if it was, it wouldn't be _Linux_ any more.)

Linux is maintained by Linus (2.5), Allan (2.2), and Marcelo (2.4)
(and someone's doing 2.0 still, but i forget who :)
That's The Way It Is (tm) and trying to change that isn't going to
happen any time soon (nor, given the disparity between the
Linux Kernel and the Linux Distributions, should it be)

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

ahhh, so trying to tackle these problems would be a good idea.
For example, Marcelo's adoption of the "final -pre is (essentially)
unchanged when it becomes the formal release"

Q - Would CVS or Perforce or BitKeeper help fix these problems?
A - No, the problem is one of organization, not accountability

Maybe we should toss the original question and try to find ways
to solve the organizational problems instead?

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

> that is exactly my point.

so maybe we should make it clear (in the maintainers file, for example)
WHERE patches and bugs should be reported?

It sounds more like a reporting problem than a tracking problem : the
maintainers know which bugs have been fixed (or patches to fix the bugs
have been applied at least) so the only thing missing is that the
maintainers
have to know about the bugs.  I don't think that a bugzilla-type central
bug reporting tool will help that, because the maintainers who don't read
LKML won't pay attention to bugzilla either.

--
Dana Lacoste
Ottawa, Canada
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!
ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Date: 	Thu, 27 Dec 2001 14:01:23 -0200 (BRST)
From: Rik van Riel <r...@conectiva.com.br>
X-X-Sender:  <r...@duckman.distro.conectiva>
To: Dana Lacoste <dana.laco...@peregrine.com>
Cc: "'Eyal Sohya'" <linuz_kerne...@hotmail.com>,
        <linux-ker...@vger.kernel.org>
Subject: RE: The direction linux is taking
In-Reply-To: <B51F07F0080AD511AC4A0002A52CAB445B2A36@ottonexc1.ottawa.loran.com>
Original-Message-ID: 
<Pine.LNX.4.33L.0112271353370.12225-100000@duckman.distro.conectiva>
X-spambait: aardv...@kernelnewbies.org
X-spammeplease: 	aardv...@nl.linux.org
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Thu, 27 Dec 2001 16:03:48 GMT
Message-ID: <fa.om4sihv.41guj0@ifi.uio.no>
References: <fa.pl2e09v.96qg96@ifi.uio.no>
Lines: 57

On Thu, 27 Dec 2001, Dana Lacoste wrote:

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

> Q - Would CVS or Perforce or BitKeeper help fix these problems?
> A - No, the problem is one of organization, not accountability
>
> Maybe we should toss the original question and try to find ways
> to solve the organizational problems instead?

Sounds like an idea, except that up to now I haven't seen
any suitable solution for this.

The biggest problem right now seems to be that of patches
being dropped, which is a direct result of the kernel
maintainers not having infinite time.

A system to solve this problem would have to make it easier
for the kernel maintainers to remember patches, while at the
same time saving them time. I guess it would have something
like the following ingredients:
1. remember the patches and their descriptions
2. have the possibility for other people (subsystem maintainers?)
   to de-queue or update pending patches
3. check at each pre-release if the patches still apply, notify
   the submitter if the patch no longer applies
4. make an easy "one-click" solution for the maintainers to apply
   the patch and add a line to the changelog ;)
   (all patches apply without rejects, patches which don't apply
   have already been bounced back to the maintainer by #3)
5. after a new pre-patch, send the kernel maintainer a quick
   overview of pending patches
6. patches can get different priorities assigned, so the kernel
   maintainers can spend their time with the highest-priority
   patches first
7. .. ?

All in all, if such a system is ever going to exist, it
needs to _reduce_ the amount of work the kernel maintainers
need to do, otherwise it'll never get used.

regards,

Rik
-- 
DMCA, SSSCA, W3C?  Who cares?  http://thefreeworld.net/

http://www.surriel.com/		http://distro.conectiva.com/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news2.google.com!news1.google.com!
newsfeed.stanford.edu!news.tele.dk!small.news.tele.dk!129.240.148.23!
uio.no!nntp.uio.no!ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Subject: Re: The direction linux is taking
To: r...@conectiva.com.br (Rik van Riel)
Original-Date: 	Thu, 27 Dec 2001 16:33:50 +0000 (GMT)
Cc: dana.laco...@peregrine.com (Dana Lacoste),
        linuz_kerne...@hotmail.com ('Eyal Sohya'),
        linux-ker...@vger.kernel.org
In-Reply-To: 
<Pine.LNX.4.33L.0112271353370.12225-100000@duckman.distro.conectiva> 
from "Rik van Riel" at Dec 27, 2001 02:01:23 PM
X-Mailer: ELM [version 2.5 PL6]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Original-Message-Id: <E16JdTa-0005zm-00@the-village.bc.nu>
From: Alan Cox <a...@lxorguk.ukuu.org.uk>
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Thu, 27 Dec 2001 16:25:12 GMT
Message-ID: <fa.hb3l3fv.1b7gr10@ifi.uio.no>
References: <fa.om4sihv.41guj0@ifi.uio.no>
Lines: 12

> All in all, if such a system is ever going to exist, it
> needs to _reduce_ the amount of work the kernel maintainers
> need to do, otherwise it'll never get used.

Tridge wrote the system you describe, several years ago. Its called
jitterbug but it doesnt help because Linus wont use it

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!
ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Date: 	Thu, 27 Dec 2001 14:30:53 -0200 (BRST)
From: Rik van Riel <r...@conectiva.com.br>
X-X-Sender:  <r...@duckman.distro.conectiva>
To: Alan Cox <a...@lxorguk.ukuu.org.uk>
Cc: Dana Lacoste <dana.laco...@peregrine.com>,
        "'Eyal Sohya'" <linuz_kerne...@hotmail.com>,
        <linux-ker...@vger.kernel.org>
Subject: Re: The direction linux is taking
In-Reply-To: <E16JdTa-0005zm-00@the-village.bc.nu>
Original-Message-ID: 
<Pine.LNX.4.33L.0112271429580.12225-100000@duckman.distro.conectiva>
X-spambait: aardv...@kernelnewbies.org
X-spammeplease: 	aardv...@nl.linux.org
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Thu, 27 Dec 2001 16:32:38 GMT
Message-ID: <fa.op50j1v.11ssj7@ifi.uio.no>
References: <fa.hb3l3fv.1b7gr10@ifi.uio.no>
Lines: 29

On Thu, 27 Dec 2001, Alan Cox wrote:

> > All in all, if such a system is ever going to exist, it
> > needs to _reduce_ the amount of work the kernel maintainers
> > need to do, otherwise it'll never get used.
>
> Tridge wrote the system you describe, several years ago. Its called
> jitterbug but it doesnt help because Linus wont use it

I don't care about Linus, he drops so many bugfixes
his kernel have done nothing but suck rocks since the
2.1 era.

This system could be useful for people who _are_ maintainers,
however.

regards,

Rik
-- 
DMCA, SSSCA, W3C?  Who cares?  http://thefreeworld.net/

http://www.surriel.com/		http://distro.conectiva.com/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news.tele.dk!
small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!ifi.uio.no!
internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Subject: Re: The direction linux is taking
To: r...@conectiva.com.br (Rik van Riel)
Original-Date: 	Thu, 27 Dec 2001 16:53:32 +0000 (GMT)
Cc: a...@lxorguk.ukuu.org.uk (Alan Cox),
        dana.laco...@peregrine.com (Dana Lacoste),
        linuz_kerne...@hotmail.com ('Eyal Sohya'),
        linux-ker...@vger.kernel.org
In-Reply-To: 
<Pine.LNX.4.33L.0112271429580.12225-100000@duckman.distro.conectiva> 
from "Rik van Riel" at Dec 27, 2001 02:30:53 PM
X-Mailer: ELM [version 2.5 PL6]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Original-Message-Id: <E16Jdme-00065I-00@the-village.bc.nu>
From: Alan Cox <a...@lxorguk.ukuu.org.uk>
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Thu, 27 Dec 2001 16:44:47 GMT
Message-ID: <fa.g8iv4fv.cmaq13@ifi.uio.no>
References: <fa.op50j1v.11ssj7@ifi.uio.no>
Lines: 13

> I don't care about Linus, he drops so many bugfixes
> his kernel have done nothing but suck rocks since the
> 2.1 era.
> 
> This system could be useful for people who _are_ maintainers,
> however.

In which case you'll find jitterbug on www.samba.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news.algonet.se!algonet!
newsfeed1.uni2.dk!news.net.uni-c.dk!uninett.no!uio.no!nntp.uio.no!
ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Date: 	Thu, 27 Dec 2001 16:57:52 +0000
From: Russell King <r...@arm.linux.org.uk>
To: Alan Cox <a...@lxorguk.ukuu.org.uk>
Cc: Rik van Riel <r...@conectiva.com.br>,
        Dana Lacoste <dana.laco...@peregrine.com>,
        "'Eyal Sohya'" <linuz_kerne...@hotmail.com>,
        linux-ker...@vger.kernel.org
Subject: Re: The direction linux is taking
Original-Message-ID: <20011227165752.A19618@flint.arm.linux.org.uk>
Original-References: 
<Pine.LNX.4.33L.0112271353370.12225-100...@duckman.distro.conectiva> 
<E16JdTa-0005zm...@the-village.bc.nu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <E16JdTa-0005zm-00@the-village.bc.nu>; 
from alan@lxorguk.ukuu.org.uk on Thu, Dec 27, 2001 at 04:33:50PM +0000
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Thu, 27 Dec 2001 16:59:41 GMT
Message-ID: <fa.j15gdsv.p4a98j@ifi.uio.no>
References: <fa.hb3l3fv.1b7gr10@ifi.uio.no>
Lines: 31

On Thu, Dec 27, 2001 at 04:33:50PM +0000, Alan Cox wrote:
> Tridge wrote the system you describe, several years ago. Its called
> jitterbug but it doesnt help because Linus wont use it

Speaking as someone who _does_ use a system for tracking patches, I
believe that patch management systems are a right pain in the arse.

If the quality of patches aren't good, then it throws you into a problem.
You have to provide people with a reason why you discarded their patch,
which provides people with the perfect opportunity to immediately start
bugging you about exactly how to make it better.  If you get lots of
such patches, eventually you've got a mailbox of people wanting to know
how to make their patches better.

I envy Alan, Linus, and Marcelo for having the ability to silently drop
patches and wait for resends.  I personally don't believe a patch tracking
system makes life any easier.  Yes, it means you can't loose patches, but
it means you can't accidentally loose them on purpose.  This, imho, makes
life very much harder.

I hope this makes some sort of sense 8)

-- 
Russell King (r...@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!
ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Date: 	Thu, 27 Dec 2001 15:11:01 -0200 (BRST)
From: Rik van Riel <r...@conectiva.com.br>
X-X-Sender:  <r...@duckman.distro.conectiva>
To: Russell King <r...@arm.linux.org.uk>
Cc: Alan Cox <a...@lxorguk.ukuu.org.uk>,
        Dana Lacoste <dana.laco...@peregrine.com>,
        "'Eyal Sohya'" <linuz_kerne...@hotmail.com>,
        <linux-ker...@vger.kernel.org>
Subject: Re: The direction linux is taking
In-Reply-To: <20011227165752.A19618@flint.arm.linux.org.uk>
Original-Message-ID: 
<Pine.LNX.4.33L.0112271509570.12225-100000@duckman.distro.conectiva>
X-spambait: aardv...@kernelnewbies.org
X-spammeplease: 	aardv...@nl.linux.org
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Thu, 27 Dec 2001 17:12:47 GMT
Message-ID: <fa.op50j1v.11sv35@ifi.uio.no>
References: <fa.j15gdsv.p4a98j@ifi.uio.no>
Lines: 22

On Thu, 27 Dec 2001, Russell King wrote:

> I envy Alan, Linus, and Marcelo for having the ability to silently
> drop patches and wait for resends.

I'm not going to resend more than twice. If after that
a critical bugfix isn't applied, I'll put it in our
kernel RPM and the rest of the world has tough luck.

regards,

Rik
-- 
DMCA, SSSCA, W3C?  Who cares?  http://thefreeworld.net/

http://www.surriel.com/		http://distro.conectiva.com/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!
ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Date: 	Thu, 27 Dec 2001 10:38:28 -0700
Original-Message-Id: <200112271738.fBRHcSd30844@vindaloo.ras.ucalgary.ca>
From: Richard Gooch <rgo...@ras.ucalgary.ca>
To: Russell King <r...@arm.linux.org.uk>
Cc: Alan Cox <a...@lxorguk.ukuu.org.uk>, Rik van Riel <r...@conectiva.com.br>,
        Dana Lacoste <dana.laco...@peregrine.com>,
        "'Eyal Sohya'" <linuz_kerne...@hotmail.com>,
        linux-ker...@vger.kernel.org
Subject: Re: The direction linux is taking
In-Reply-To: <20011227165752.A19618@flint.arm.linux.org.uk>
Original-References: 
<Pine.LNX.4.33L.0112271353370.12225-100...@duckman.distro.conectiva>
	<E16JdTa-0005zm...@the-village.bc.nu>
	<20011227165752.A19...@flint.arm.linux.org.uk>
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Thu, 27 Dec 2001 17:41:20 GMT
Message-ID: <fa.ltc9tiv.19hgn9o@ifi.uio.no>
References: <fa.j15gdsv.p4a98j@ifi.uio.no>
Lines: 31

Russell King writes:
> On Thu, Dec 27, 2001 at 04:33:50PM +0000, Alan Cox wrote:
> > Tridge wrote the system you describe, several years ago. Its called
> > jitterbug but it doesnt help because Linus wont use it
> 
> Speaking as someone who _does_ use a system for tracking patches, I
> believe that patch management systems are a right pain in the arse.
> 
> If the quality of patches aren't good, then it throws you into a
> problem.  You have to provide people with a reason why you discarded
> their patch, which provides people with the perfect opportunity to
> immediately start bugging you about exactly how to make it better.
> If you get lots of such patches, eventually you've got a mailbox of
> people wanting to know how to make their patches better.

So you just do what Linus does: delete those questions without
replying. No matter what system you use, if you want to avoid an
overflowing mailbox, you either have to silently drop patches, and/or
silently drop questions/requests/begging letters. There isn't really
much difference between the two.

				Regards,

					Richard....
Permanent: rgo...@atnf.csiro.au
Current:   rgo...@ras.ucalgary.ca
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news.tele.dk!
small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!ifi.uio.no!
internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Subject: Re: The direction linux is taking
To: r...@arm.linux.org.uk (Russell King)
Original-Date: 	Thu, 27 Dec 2001 17:52:57 +0000 (GMT)
Cc: a...@lxorguk.ukuu.org.uk (Alan Cox), r...@conectiva.com.br (Rik van Riel),
        dana.laco...@peregrine.com (Dana Lacoste),
        linuz_kerne...@hotmail.com ('Eyal Sohya'),
        linux-ker...@vger.kernel.org
In-Reply-To: <20011227165752.A19618@flint.arm.linux.org.uk> 
from "Russell King" at Dec 27, 2001 04:57:52 PM
X-Mailer: ELM [version 2.5 PL6]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Original-Message-Id: <E16Jei9-0006Gl-00@the-village.bc.nu>
From: Alan Cox <a...@lxorguk.ukuu.org.uk>
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Thu, 27 Dec 2001 17:46:02 GMT
Message-ID: <fa.gi4spfv.1l48d13@ifi.uio.no>
References: <fa.j15gdsv.p4a98j@ifi.uio.no>
Lines: 14

> I envy Alan, Linus, and Marcelo for having the ability to silently drop
> patches and wait for resends.  I personally don't believe a patch tracking

I go to great lengths to try and avoid that. People often get very
short replies but I try to make sure if the patch isnt queued to apply
they get a reply. Sometimes I have to sit on them for a week until I
understand why I don't like them.

The things I happily drop are people arguing about why I dropped their patch
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news.tele.dk!
small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!ifi.uio.no!
internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Subject: Re: The direction linux is taking
To: tcapr...@logatique.fr (Thomas Capricelli)
Original-Date: 	Thu, 27 Dec 2001 17:54:13 +0000 (GMT)
Cc: a...@lxorguk.ukuu.org.uk (Alan Cox), r...@conectiva.com.br (Rik van Riel),
        linux-ker...@vger.kernel.org
In-Reply-To: <20011227170036.70F1E23CBB@persephone.dmz.logatique.fr> 
from "Thomas Capricelli" at Dec 27, 2001 06:03:41 PM
X-Mailer: ELM [version 2.5 PL6]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Original-Message-Id: <E16JejN-0006Gy-00@the-village.bc.nu>
From: Alan Cox <a...@lxorguk.ukuu.org.uk>
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Thu, 27 Dec 2001 17:47:03 GMT
Message-ID: <fa.gi5ounv.1l54gp3@ifi.uio.no>
References: <fa.lh8umnv.1nn87rt@ifi.uio.no>
Lines: 9

I have a system I am happy with, I save stuff that looks worth applying into
a TO_APPLY directory then merge it in logical chunks.

Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!
ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Subject: Re: The direction linux is taking
To: rgo...@ras.ucalgary.ca (Richard Gooch)
Original-Date: 	Thu, 27 Dec 2001 18:02:40 +0000 (GMT)
Cc: r...@arm.linux.org.uk (Russell King), a...@lxorguk.ukuu.org.uk (Alan Cox),
        r...@conectiva.com.br (Rik van Riel),
        dana.laco...@peregrine.com (Dana Lacoste),
        linuz_kerne...@hotmail.com ('Eyal Sohya'),
        linux-ker...@vger.kernel.org
In-Reply-To: <200112271738.fBRHcSd30844@vindaloo.ras.ucalgary.ca> 
from "Richard Gooch" at Dec 27, 2001 10:38:28 AM
X-Mailer: ELM [version 2.5 PL6]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Original-Message-Id: <E16JerY-0006Jm-00@the-village.bc.nu>
From: Alan Cox <a...@lxorguk.ukuu.org.uk>
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Thu, 27 Dec 2001 17:54:50 GMT
Message-ID: <fa.gjlh1fv.1jlsl13@ifi.uio.no>
References: <fa.ltc9tiv.19hgn9o@ifi.uio.no>
Lines: 17

> So you just do what Linus does: delete those questions without
> replying. No matter what system you use, if you want to avoid an
> overflowing mailbox, you either have to silently drop patches, and/or
> silently drop questions/requests/begging letters. There isn't really
> much difference between the two.

The problem is that if Linus is simply ignoring you then you don't know
why, A simple "Clean up the ifdefs" would make a lot of difference. If
someone sent a patch its because they hit something they felt needed fixing
and as far as they can tell fixed it. If you want them to go elsewhere
ignore them, but its much more useful to give them at least brief answers
to actual patch files
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!
ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
X-Authentication-Warning: palladium.transmeta.com: 
mail set sender to n...@transmeta.com using -f
To: linux-ker...@vger.kernel.org
From: torva...@transmeta.com (Linus Torvalds)
Subject: Re: The direction linux is taking
Original-Date: 	Thu, 27 Dec 2001 18:05:40 +0000 (UTC)
Original-Message-ID: <a0fntk$ukm$1@penguin.transmeta.com>
Original-References: <20011227165752.A19...@flint.arm.linux.org.uk> 
<Pine.LNX.4.33L.0112271509570.12225-100...@duckman.distro.conectiva>
X-Complaints-To: news@transmeta.com
Original-NNTP-Posting-Date: 27 Dec 2001 18:07:44 GMT
Cache-Post-Path: palladium.transmeta.com!unkn...@penguin.transmeta.com
X-Cache: nntpcache 2.4.0b5 (see http://www.nntpcache.org/)
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Transmeta Corporation
Date: Thu, 27 Dec 2001 18:10:58 GMT
Message-ID: <fa.k51k14v.1mk702@ifi.uio.no>
References: <fa.op50j1v.11sv35@ifi.uio.no>
Lines: 67

In article <Pine.LNX.4.33L.0112271509570.12225-100...@duckman.distro.conectiva>,
Rik van Riel  <r...@conectiva.com.br> wrote:
>On Thu, 27 Dec 2001, Russell King wrote:
>
>> I envy Alan, Linus, and Marcelo for having the ability to silently
>> drop patches and wait for resends.

This is absolutely true - it's a _very_ powerful thing. Old patches
simply grow stale: keeping track of them is not necessarily at all
useful, and can add more work than anything else. 

One of the problems I had with jitterbug was that after a while the
thing just grew a lot, and I spent a lot of time with a cumbersome web
interface just acknowledging the patches.  And that was despite the fact
that not very many people actually actively used jitterbug to submit
patches to me, so I could see it just getting a _lot_ worse. 

>I'm not going to resend more than twice. If after that
>a critical bugfix isn't applied, I'll put it in our
>kernel RPM and the rest of the world has tough luck.

Which, btw, explains why I don't consider you a kernel maintainer, Rik,
and I don't tend to apply any patches at all from you.  It's just not
worth my time to worry about people who aren't willing to sustain their
patches.

When Al Viro sends me a patch that I apply, and later sends me a fix to
it that I miss for whatever reason, I can feel comfortable in the
knowledge that he _will_ follow up, not just whine.  This makes me very
willing to apply his patches in the first place.

Replace "Al Viro" with Jeff Garzik, David Miller, Alan Cox, etc etc. See
my point?

This is not about technology.  This is about sustainable development. 
The most important part to that is the developers themselves - I refuse
to put myself in a situation where _I_ need to scale, because that would
be stupid - people simply do not scale.  So I require others to do more
of the work. Think distributed development.

Note that things like CVS do not help the fundamental problem at all. 
They allow automatic acceptance of patches, and positively _encourage_
people to "dump" their patches on other people, and not act as real
maintainers. 

We've seen this several times in Linux - David, for example, used to
maintain his CVS tree, and he ended up being rather frustrated about
having to then maintain it all and clean up the bad parts because I
didn't want to apply them (and he didn't really want me to) and he
couldn't make people clean up themselves because "once it was in, it was
in". 

I know that source control advocates say that using source control makes
it easy to revert bad stuff, but that's simply not TRUE.  It's _not_
easy to revert bad stuff.  The only way to handle bad stuff is to make
people _responsible_ for their own sh*t, and have them maintain it
themselves. 

And you refuse to do that, and then you complain when others do not want
to maintain your code for you. 

		Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!
ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Date: 	Thu, 27 Dec 2001 16:24:40 -0200 (BRST)
From: Rik van Riel <r...@conectiva.com.br>
X-X-Sender:  <r...@duckman.distro.conectiva>
To: Linus Torvalds <torva...@transmeta.com>
Cc: <linux-ker...@vger.kernel.org>
Subject: Re: The direction linux is taking
In-Reply-To: <a0fntk$ukm$1@penguin.transmeta.com>
Original-Message-ID: 
<Pine.LNX.4.33L.0112271623220.12225-100000@duckman.distro.conectiva>
X-spambait: aardv...@kernelnewbies.org
X-spammeplease: 	aardv...@nl.linux.org
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Thu, 27 Dec 2001 18:26:26 GMT
Message-ID: <fa.om4qi1v.41iuj7@ifi.uio.no>
References: <fa.k51k14v.1mk702@ifi.uio.no>
Lines: 28

On Thu, 27 Dec 2001, Linus Torvalds wrote:

> >I'm not going to resend more than twice. If after that
> >a critical bugfix isn't applied, I'll put it in our
> >kernel RPM and the rest of the world has tough luck.
>
> Which, btw, explains why I don't consider you a kernel maintainer,
> Rik, and I don't tend to apply any patches at all from you.  It's just
> not worth my time to worry about people who aren't willing to sustain
> their patches.

OK, I'll setup something to automatically send you patches
as long as they're not applied, don't get any reaction and
still apply cleanly.

regards,

Rik
-- 
DMCA, SSSCA, W3C?  Who cares?  http://thefreeworld.net/

http://www.surriel.com/		http://distro.conectiva.com/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news.tele.dk!
small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!ifi.uio.no!
internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
X-Authentication-Warning: penguin.transmeta.com: torvalds owned process doing -bs
Original-Date: 	Thu, 27 Dec 2001 10:58:47 -0800 (PST)
From: Linus Torvalds <torva...@transmeta.com>
To: Rik van Riel <r...@conectiva.com.br>
cc: <linux-ker...@vger.kernel.org>
Subject: Re: The direction linux is taking
In-Reply-To: 
<Pine.LNX.4.33L.0112271623220.12225-100000@duckman.distro.conectiva>
Original-Message-ID: 
<Pine.LNX.4.33.0112271058070.1052-100000@penguin.transmeta.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Thu, 27 Dec 2001 19:03:12 GMT
Message-ID: <fa.o99hevv.hk2531@ifi.uio.no>
References: <fa.om4qi1v.41iuj7@ifi.uio.no>
Lines: 21


On Thu, 27 Dec 2001, Rik van Riel wrote:
>
> OK, I'll setup something to automatically send you patches
> as long as they're not applied, don't get any reaction and
> still apply cleanly.

No.

Did you read the part about "maintainership" at all?

I ignore automatic emails, the same way I ignore spam. Automating
patch-sending is _not_ maintainership.

		Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!
ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Date: 	Thu, 27 Dec 2001 17:16:10 -0200 (BRST)
From: Rik van Riel <r...@conectiva.com.br>
X-X-Sender:  <r...@duckman.distro.conectiva>
To: Linus Torvalds <torva...@transmeta.com>
Cc: <linux-ker...@vger.kernel.org>
Subject: Re: The direction linux is taking
In-Reply-To: 
<Pine.LNX.4.33.0112271058070.1052-100000@penguin.transmeta.com>
Original-Message-ID: 
<Pine.LNX.4.33L.0112271713580.12225-100000@duckman.distro.conectiva>
X-spambait: aardv...@kernelnewbies.org
X-spammeplease: 	aardv...@nl.linux.org
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Thu, 27 Dec 2001 19:18:58 GMT
Message-ID: <fa.om50jpv.41ssb4@ifi.uio.no>
References: <fa.o99hevv.hk2531@ifi.uio.no>
Lines: 38

On Thu, 27 Dec 2001, Linus Torvalds wrote:
> On Thu, 27 Dec 2001, Rik van Riel wrote:
> >
> > OK, I'll setup something to automatically send you patches
> > as long as they're not applied, don't get any reaction and
> > still apply cleanly.
>
> No.
>
> Did you read the part about "maintainership" at all?

Of course the patch will be updated when needed, but I still
have a few 6-month old patches lying around that still work
as expected and don't need any change.

I see absolutely no reason to not automate the resending of
these patches, once they need maintenance again I'll maintain
them.

> I ignore automatic emails, the same way I ignore spam. Automating
> patch-sending is _not_ maintainership.

Silently dropping bugfixes on the floor is not maintainership,
either.

regards,

Rik
-- 
DMCA, SSSCA, W3C?  Who cares?  http://thefreeworld.net/

http://www.surriel.com/		http://distro.conectiva.com/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!
ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
X-Authentication-Warning: penguin.transmeta.com: torvalds owned process doing -bs
Original-Date: 	Thu, 27 Dec 2001 11:29:02 -0800 (PST)
From: Linus Torvalds <torva...@transmeta.com>
To: Rik van Riel <r...@conectiva.com.br>
cc: <linux-ker...@vger.kernel.org>
Subject: Re: The direction linux is taking
In-Reply-To: 
<Pine.LNX.4.33L.0112271713580.12225-100000@duckman.distro.conectiva>
Original-Message-ID: 
<Pine.LNX.4.33.0112271126550.1052-100000@penguin.transmeta.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Thu, 27 Dec 2001 19:32:54 GMT
Message-ID: <fa.obpfe7v.j444rf@ifi.uio.no>
References: <fa.om50jpv.41ssb4@ifi.uio.no>
Lines: 23


On Thu, 27 Dec 2001, Rik van Riel wrote:
>
> Of course the patch will be updated when needed, but I still
> have a few 6-month old patches lying around that still work
> as expected and don't need any change.

Sure. Automatic re-mailing can be part of the maintainership, if the
testing of the validity of the patch is also automated (ie add a automated
note that says that it has been verified).

It's just that I actually _have_ had people who just put "mail torvalds <
crap" in their cron routines. It quickly caused them to become part of my
spam-filter, and thus _nothing_ ever showed up from them, whether
automated or not..

		Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!
newsfeed.direct.ca!look.ca!newshub2.rdc1.sfba.home.com!news.home.com!
newshub1-work.rdc1.sfba.home.com!gehenna.pell.portland.or.us!
nntp-server.caltech.edu!nntp-server.caltech.edu!mail2news96
Newsgroups: mlist.linux.kernel
Date: 	Thu, 27 Dec 2001 19:37:16 +0100 (CET)
From: Dave Jones <da...@suse.de>
X-To: Linus Torvalds <torva...@transmeta.com>
X-Cc: <linux-ker...@vger.kernel.org>
Subject: Re: The direction linux is taking
Message-ID: 
<linux.kernel.Pine.LNX.4.33.0112271928260.15706-100000@Appserv.suse.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Approved: n...@nntp-server.caltech.edu
Lines: 49

On Thu, 27 Dec 2001, Linus Torvalds wrote:

> This is absolutely true - it's a _very_ powerful thing. Old patches
> simply grow stale: keeping track of them is not necessarily at all
> useful, and can add more work than anything else.

*nod*, until they get scooped up into another tree -ac, -dj, -whatever
and fed to you whenever you're in the mood for resyncing.

> This is not about technology.  This is about sustainable development.
> The most important part to that is the developers themselves - I refuse
> to put myself in a situation where _I_ need to scale, because that would
> be stupid - people simply do not scale.  So I require others to do more
> of the work. Think distributed development.

Absolutely. When I decided to take on carrying the 2.4 patches in sync
with 2.5, I knew I was undertaking something of no small order.
Scooping up forward port patches, and silent-drop bits from l-k
is almost a full time job in itself when yourself and Marcelo release
kernels in quick succession 8-)

And when you're ready to resync what I've got so far (currently ~3mb),
it's going to be another full time job splitting it into bits to feed
you linus-bite-sized chunks. (ObSidenote: When this time comes btw,
if maintainers of relevant parts want to feed Linus their relevant
parts from my tree, that would be appreciated, and would keep _my_ load
down :-)

> We've seen this several times in Linux - David, for example, used to
> maintain his CVS tree, and he ended up being rather frustrated about
> having to then maintain it all and clean up the bad parts because I
> didn't want to apply them (and he didn't really want me to) and he
> couldn't make people clean up themselves because "once it was in, it was
> in".

"Used to" ? cvs @ vger.samba.org was still being maintained before
I went on xmas vacation. Did I miss something ?

Dave.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!
newsfeed.direct.ca!look.ca!newshub2.rdc1.sfba.home.com!news.home.com!
newshub1-work.rdc1.sfba.home.com!gehenna.pell.portland.or.us!
nntp-server.caltech.edu!nntp-server.caltech.edu!mail2news96
Newsgroups: mlist.linux.kernel
Date: 	Thu, 27 Dec 2001 11:25:13 -0800 (PST)
From: Linus Torvalds <torva...@transmeta.com>
X-To: Dave Jones <da...@suse.de>
X-cc: <linux-ker...@vger.kernel.org>
Subject: Re: The direction linux is taking
Message-ID: 
<linux.kernel.Pine.LNX.4.33.0112271105350.1052-100000@penguin.transmeta.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Approved: n...@nntp-server.caltech.edu
Lines: 99


On Thu, 27 Dec 2001, Dave Jones wrote:
> On Thu, 27 Dec 2001, Linus Torvalds wrote:
>
> > This is absolutely true - it's a _very_ powerful thing. Old patches
> > simply grow stale: keeping track of them is not necessarily at all
> > useful, and can add more work than anything else.
>
> *nod*, until they get scooped up into another tree -ac, -dj, -whatever
> and fed to you whenever you're in the mood for resyncing.

But that's nothing more than "somebody else maintains them".

I realize that quite often the author of the patch is not going to be its
maintainer, which is exactly why all the other trees are so useful.

Everybody should realize that "outside trees" are not a rogue thing. They
are _very_ important, for several reasons:

 - competition keeps people honest. If I was the only holder of the keys,
   nobody would even _know_ if I was corrupt. And nobody could choose with
   his feet.

   Look at politics: if you don't have choices, the one choice _will_ be
   corrupt even if it started out with all the best intentions. The old
   adage there is "Power corrupts. Absolute power corrupts absolutely".

 - Different taste. Let's face it, a lot of programming is about having
   taste. Sometimes I don't like the way things are done, and people prove
   me wrong by other means. See the whole thing about the VM stuff with
   Andrea's patches - one of the reasons I hadn't applied the much earlier
   patches by Andrea was that I didn't like the zone-balancing approach.

   Having external trees is _crucial_ for allowing different approaches to
   co-exist, in order to show their strengths and weaknesses. And I tend
   to be fairly open to admitting when I did something wrong, and somebody
   else had a better tree. At least I _try_.

 - Different goals. Many of the commercial vendors have vendor needs, and
   they (correctly) think that those needs are the most important thing,
   while I don't care about vendors and thus have different priorities.

   Again, multiple trees are absolutely required to make this work.

 - And imperfect patch retention. There's no question that I drop patches,
   some bad, but many good. And that's going to be true of _anybody_ who
   maintains anything, except somebody who just accepts anything without
   question (eg CVS).

I don't think I've ever spoken out against things like -ac, -dj and -aa: I
sometimes have to explain why I do not merge things whole-sale (which
would certainly be _technically_ the easiest solution much of the time),
and I often disagree with some part of the patch, but I'm actually
surprised how often I have to _defend_ having many trees.

Just a historical note: one of the things I hated most about Minix was
that while Andrew Tanenbaum allowed external patches to the system, nobody
else could make a whole distribution. Which meant that while there existed
many trees and maintainers that were "better" (notably Bruce Evans, who
was considered to be a God of Minix), they were really painful to use, in
that you had to always do it from patches.

I fully _expect_ that somebody better comes along. At some point, more
people will simply be using the -dj tree (or whatever), and that's fine.

> And when you're ready to resync what I've got so far (currently ~3mb),
> it's going to be another full time job splitting it into bits to feed
> you linus-bite-sized chunks. (ObSidenote: When this time comes btw,
> if maintainers of relevant parts want to feed Linus their relevant
> parts from my tree, that would be appreciated, and would keep _my_ load
> down :-)

This sounds absolutely wonderful..

Note that you will notice that it's a _huge_ undertaking, and one of the
things that Alan complained about was how the fact that _I_ avoid scaling
meant that he had to scale more. I think it's a very valid complaint, and
it may make a whole lot more sense (if it is possible) to have different
people caring about different parts.

Note that this may not be possible, due to lack of modularity. We've had
to actively change the tree layout of the kernel before just to make it
easier to maintain over several people. Which is painful, but not
certainly not impossible still..

> "Used to" ? cvs @ vger.samba.org was still being maintained before
> I went on xmas vacation. Did I miss something ?

Does he allow the wide and uncoordinated write access that he used to
allow? I thought he basically shut that down, and only allows a few people
now, exactly to avoid getting too horrible merge issues..

		Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
logbridge.uoregon.edu!news.net.uni-c.dk!uninett.no!uio.no!nntp.uio.no!
ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Date: 	Thu, 27 Dec 2001 17:46:51 -0200 (BRST)
From: Rik van Riel <r...@conectiva.com.br>
X-X-Sender:  <r...@duckman.distro.conectiva>
To: Linus Torvalds <torva...@transmeta.com>
Cc: <linux-ker...@vger.kernel.org>
Subject: Re: The direction linux is taking
In-Reply-To: 
<Pine.LNX.4.33.0112271126550.1052-100000@penguin.transmeta.com>
Original-Message-ID: 
<Pine.LNX.4.33L.0112271742470.12225-100000@duckman.distro.conectiva>
X-spambait: aardv...@kernelnewbies.org
X-spammeplease: 	aardv...@nl.linux.org
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Thu, 27 Dec 2001 19:50:07 GMT
Message-ID: <fa.olkujhv.4huvj1@ifi.uio.no>
References: <fa.obpfe7v.j444rf@ifi.uio.no>
Lines: 39

On Thu, 27 Dec 2001, Linus Torvalds wrote:
> On Thu, 27 Dec 2001, Rik van Riel wrote:
> >
> > Of course the patch will be updated when needed, but I still
> > have a few 6-month old patches lying around that still work
> > as expected and don't need any change.
>
> Sure. Automatic re-mailing can be part of the maintainership, if the
> testing of the validity of the patch is also automated (ie add a
> automated note that says that it has been verified).

Patch-bombing you with useless stuff has never been my
objective. I just want to make sure valid patches get
re-sent to you as long as there is a reason to believe
they still need to be sent.

As soon as any hint arrives that the patch shouldn't be
sent right now (a change was made to any of the files the
patch applies to, I see something suspect in the changelog,
the patch was applied, a reply was mailed to the patch...)
the patch will be moved away for manual inspection.

I guess I'll also build in some kind of backoff to make sure
the patch gets sent less often if you're not interested or too
busy.

regards,

Rik
-- 
DMCA, SSSCA, W3C?  Who cares?  http://thefreeworld.net/

http://www.surriel.com/		http://distro.conectiva.com/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!
newsfeed.direct.ca!look.ca!newsfeed.icl.net!diablo.netcom.net.uk!
netcom.net.uk!news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!
nntp.uio.no!ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Date: 	Thu, 27 Dec 2001 18:07:22 -0200 (BRST)
From: Rik van Riel <r...@conectiva.com.br>
X-X-Sender:  <r...@duckman.distro.conectiva>
To: Richard Gooch <rgo...@ras.ucalgary.ca>
Cc: Linus Torvalds <torva...@transmeta.com>, <linux-ker...@vger.kernel.org>
Subject: Re: The direction linux is taking
In-Reply-To: <200112271957.fBRJvdv00960@vindaloo.ras.ucalgary.ca>
Original-Message-ID: 
<Pine.LNX.4.33L.0112271802130.12225-100000@duckman.distro.conectiva>
X-spambait: aardv...@kernelnewbies.org
X-spammeplease: 	aardv...@nl.linux.org
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Thu, 27 Dec 2001 20:09:03 GMT
Message-ID: <fa.olkoipv.4hktb5@ifi.uio.no>
References: <fa.lqtk2iv.1b06r97@ifi.uio.no>
Lines: 45

On Thu, 27 Dec 2001, Richard Gooch wrote:

> If you get this working nicely, it might even be a generally useful
> thing. A set of perl scripts and easy interface commands could prove
> popular. I would certainly find it convenient to have a patch
> retransmission system that re-sent patches every time a new pre-patch
> came out, and emailed me when the patch no longer applies.

... or compiles, or applies with an offset

> If it could automatically de-queue when the patch is applied, or when
> I manually remove it, that would be even better.

... or when somebody replies to the patch and the reply
gets caught by a program invoked from your .procmailrc

If Linus replies he has seen the patch, don't keep
bombing him.

Of course when the patch gets dequeued, the program should
send you a mail with the reason.

> And if I make an update to a queued patch, it obsoletes the old one,
> that would be good too.

Good one, this needs to be added.

Any more requirements / ideas / volunteers / ... ?

(and remember, this thing is designed to make Linus his life
easier, too)

regards,

Rik
-- 
DMCA, SSSCA, W3C?  Who cares?  http://thefreeworld.net/

http://www.surriel.com/		http://distro.conectiva.com/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!
newsfeed.direct.ca!look.ca!newsfeed.icl.net!diablo.netcom.net.uk!
netcom.net.uk!news.tele.dk!small.news.tele.dk!129.240.148.23!
uio.no!nntp.uio.no!ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Date: 	Thu, 27 Dec 2001 18:07:22 -0200 (BRST)
From: Rik van Riel <r...@conectiva.com.br>
X-X-Sender:  <r...@duckman.distro.conectiva>
To: Richard Gooch <rgo...@ras.ucalgary.ca>
Cc: Linus Torvalds <torva...@transmeta.com>, <linux-ker...@vger.kernel.org>
Subject: Re: The direction linux is taking
In-Reply-To: <200112271957.fBRJvdv00960@vindaloo.ras.ucalgary.ca>
Original-Message-ID: 
<Pine.LNX.4.33L.0112271802130.12225-100000@duckman.distro.conectiva>
X-spambait: aardv...@kernelnewbies.org
X-spammeplease: 	aardv...@nl.linux.org
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Thu, 27 Dec 2001 20:09:03 GMT
Message-ID: <fa.olkoipv.4hktb5@ifi.uio.no>
References: <fa.lqtk2iv.1b06r97@ifi.uio.no>
Lines: 45

On Thu, 27 Dec 2001, Richard Gooch wrote:

> If you get this working nicely, it might even be a generally useful
> thing. A set of perl scripts and easy interface commands could prove
> popular. I would certainly find it convenient to have a patch
> retransmission system that re-sent patches every time a new pre-patch
> came out, and emailed me when the patch no longer applies.

... or compiles, or applies with an offset

> If it could automatically de-queue when the patch is applied, or when
> I manually remove it, that would be even better.

... or when somebody replies to the patch and the reply
gets caught by a program invoked from your .procmailrc

If Linus replies he has seen the patch, don't keep
bombing him.

Of course when the patch gets dequeued, the program should
send you a mail with the reason.

> And if I make an update to a queued patch, it obsoletes the old one,
> that would be good too.

Good one, this needs to be added.

Any more requirements / ideas / volunteers / ... ?

(and remember, this thing is designed to make Linus his life
easier, too)

regards,

Rik
-- 
DMCA, SSSCA, W3C?  Who cares?  http://thefreeworld.net/

http://www.surriel.com/		http://distro.conectiva.com/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!
ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Date: 	Thu, 27 Dec 2001 12:10:33 -0800
From: Larry McVoy <l...@bitmover.com>
To: Linus Torvalds <torva...@transmeta.com>
Cc: linux-ker...@vger.kernel.org
Subject: Re: The direction linux is taking
Original-Message-ID: <20011227121033.F25698@work.bitmover.com>
Mail-Followup-To: Linus Torvalds <torva...@transmeta.com>,
	linux-ker...@vger.kernel.org
Original-References: <20011227165752.A19...@flint.arm.linux.org.uk> 
<Pine.LNX.4.33L.0112271509570.12225-100...@duckman.distro.conectiva> 
<a0fntk$uk...@penguin.transmeta.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <a0fntk$ukm$1@penguin.transmeta.com>; 
from torvalds@transmeta.com on Thu, Dec 27, 2001 at 06:05:40PM +0000
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Thu, 27 Dec 2001 20:11:59 GMT
Message-ID: <fa.ha94nvv.1564ki2@ifi.uio.no>
References: <fa.k51k14v.1mk702@ifi.uio.no>
Lines: 55

On Thu, Dec 27, 2001 at 06:05:40PM +0000, Linus Torvalds wrote:
> Note that things like CVS do not help the fundamental problem at all. 
> They allow automatic acceptance of patches, and positively _encourage_
> people to "dump" their patches on other people, and not act as real
> maintainers. 

Huh.  I'm not sure I understand this.  Once you accept a patch into the
mainline source, are these people still supposed to maintain that patch?
I would think the patch is now sort of dead, and any subsequent changes
are a new patch, right?  If so, what I'm missing is how a source
management system makes a difference in this case, it seems sort of 
orthogonal.

> We've seen this several times in Linux - David, for example, used to
> maintain his CVS tree, and he ended up being rather frustrated about
> having to then maintain it all and clean up the bad parts because I
> didn't want to apply them (and he didn't really want me to) and he
> couldn't make people clean up themselves because "once it was in, it was
> in". 

Isn't this a limitation of CVS?  I really don't want to get into a
"BitKeeper is better" discussion, but the PPC guys use BK and manage to
extract the right parts of the tree to send you as patches.  In fact, BK
can extract any logical change as a patch with "bk export -tpatch <rev>".
If Dave had been using BK would that have helped or not?

> I know that source control advocates say that using source control makes
> it easy to revert bad stuff, but that's simply not TRUE.  It's _not_
> easy to revert bad stuff.  

It's trivial to revert bad stuff if other stuff hasn't come to depend
on that bad stuff, assuming a reasonable SCM system.  There are really
two issues here: one is the bookkeeping necessary to be able to say
"make this patch go away", and BK does that with a "bk cset -x<rev>",
but the second is much harder.  The second is "how do I undo this patch
now that other stuff has built on it?".  Where "built on it" means that
if I were to reverse patch the files, the reverse patch will have rejects.

If you can deal with #2, BK can deal with #1.  And I can give you help
with #2 in the form of showing you what changed and why.  It's basically
the same problem as merging and we do that well.

> The only way to handle bad stuff is to make
> people _responsible_ for their own sh*t, and have them maintain it
> themselves. 

Isn't this just a "reject" button on the patch?
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!
ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
X-Authentication-Warning: penguin.transmeta.com: torvalds owned process doing -bs
Original-Date: 	Thu, 27 Dec 2001 12:12:54 -0800 (PST)
From: Linus Torvalds <torva...@transmeta.com>
To: Rik van Riel <r...@conectiva.com.br>
cc: Richard Gooch <rgo...@ras.ucalgary.ca>, <linux-ker...@vger.kernel.org>
Subject: Re: The direction linux is taking
In-Reply-To: 
<Pine.LNX.4.33L.0112271802130.12225-100000@duckman.distro.conectiva>
Original-Message-ID: 
<Pine.LNX.4.33.0112271210250.1167-100000@penguin.transmeta.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Thu, 27 Dec 2001 20:16:49 GMT
Message-ID: <fa.oa9je7v.gk04rc@ifi.uio.no>
References: <fa.olkoipv.4hktb5@ifi.uio.no>
Lines: 22


On Thu, 27 Dec 2001, Rik van Riel wrote:
> > came out, and emailed me when the patch no longer applies.
>
> ... or compiles, or applies with an offset

Good.

We actually talked inside Transmeta about doing a lot of this automation
centralized (and OSDL took up some of that idea), but yes, from a resource
usage sanity standpoint this is something that _trivially_ can be done at
the sending side, and thus scales out perfectly (while trying to do it at
the receiving end requires some _mondo_ hardware that definitely doesn't
scale, especially for the "compiles cleanly" part).

		Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!
ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
X-Authentication-Warning: penguin.transmeta.com: torvalds owned process doing -bs
Original-Date: 	Thu, 27 Dec 2001 12:21:02 -0800 (PST)
From: Linus Torvalds <torva...@transmeta.com>
To: Larry McVoy <l...@bitmover.com>
cc: <linux-ker...@vger.kernel.org>
Subject: Re: The direction linux is taking
In-Reply-To: <20011227121033.F25698@work.bitmover.com>
Original-Message-ID: 
<Pine.LNX.4.33.0112271213210.1167-100000@penguin.transmeta.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Thu, 27 Dec 2001 20:24:59 GMT
Message-ID: <fa.oa9be7v.gk84rf@ifi.uio.no>
References: <fa.ha94nvv.1564ki2@ifi.uio.no>
Lines: 53


On Thu, 27 Dec 2001, Larry McVoy wrote:
> On Thu, Dec 27, 2001 at 06:05:40PM +0000, Linus Torvalds wrote:
> > Note that things like CVS do not help the fundamental problem at all.
> > They allow automatic acceptance of patches, and positively _encourage_
> > people to "dump" their patches on other people, and not act as real
> > maintainers.
>
> Huh.  I'm not sure I understand this.  Once you accept a patch into the
> mainline source, are these people still supposed to maintain that patch?

Yes, I actually do expect them to.

It obviously depends on the kind of patch: if it is a one-liner bug-fix,
the patch is pretty much dead (that is, of course, assuming it was a
_correct_ bug-fix and didn't expose any other latent bugs).

But for most things, it's a kind of "Tag, you're it" thing. You're
supposed to support the patch (ie step up and explain what it does if
anybody wonders), and help it evolve. Many patches are only stepping
stones.

(This, btw, is something that Al Viro does absolutely beautifully. I don't
know how many people look at Al's progression of patches, but they are
stand-alone patches on their own, while at the same time _also_ being part
of a larger migration to the inscrutable goals of Al - ie namespaces etc.
You may not realize just _how_ impressive that is, and what a absolute
wonder it is to work with the guy. Poetry in patches, indeed).

> > I know that source control advocates say that using source control makes
> > it easy to revert bad stuff, but that's simply not TRUE.  It's _not_
> > easy to revert bad stuff.
>
> It's trivial to revert bad stuff if other stuff hasn't come to depend
> on that bad stuff, assuming a reasonable SCM system.

Well, there's the other part to it - most bad stuff is just "random crap",
and may not have any physical bad tendencies except to make the code
uglier. Then, people don't even realize that they are doing things the
wrong way, because they do cut-and-paste, or they just can't do things the
sane way because the badness assumes a certain layout.

And THAT is where badness is actively hurtful, while not being buggy.
Which is why I'd much rather have people work on maintenance, and not rely
on the bogus argument of "we can always undo it".

		Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!
ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Date: 	Thu, 27 Dec 2001 12:33:44 -0800
From: Larry McVoy <l...@bitmover.com>
To: Linus Torvalds <torva...@transmeta.com>
Cc: Larry McVoy <l...@bitmover.com>, linux-ker...@vger.kernel.org
Subject: Re: The direction linux is taking
Original-Message-ID: <20011227123344.H25698@work.bitmover.com>
Mail-Followup-To: Linus Torvalds <torva...@transmeta.com>,
	Larry McVoy <l...@bitmover.com>, linux-ker...@vger.kernel.org
Original-References: <20011227121033.F25...@work.bitmover.com> 
<Pine.LNX.4.33.0112271213210.1167-100...@penguin.transmeta.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <Pine.LNX.4.33.0112271213210.1167-100000@penguin.transmeta.com>; 
from torvalds@transmeta.com on Thu, Dec 27, 2001 at 12:21:02PM -0800
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Thu, 27 Dec 2001 20:35:28 GMT
Message-ID: <fa.hap6ogv.16mak2f@ifi.uio.no>
References: <fa.oa9be7v.gk84rf@ifi.uio.no>
Lines: 71

On Thu, Dec 27, 2001 at 12:21:02PM -0800, Linus Torvalds wrote:
> 
> On Thu, 27 Dec 2001, Larry McVoy wrote:
> > On Thu, Dec 27, 2001 at 06:05:40PM +0000, Linus Torvalds wrote:
> > > Note that things like CVS do not help the fundamental problem at all.
> > > They allow automatic acceptance of patches, and positively _encourage_
> > > people to "dump" their patches on other people, and not act as real
> > > maintainers.
> >
> > Huh.  I'm not sure I understand this.  Once you accept a patch into the
> > mainline source, are these people still supposed to maintain that patch?
> 
> [Linus stuff]

But this didn't answer my question at all.  My question was why is this a 
problem related to a source management system?  I can see how to exactly
mimic what described Al doing in BK so if that is the definition of goodness,
the addition (or absence) of a SCM doesn't seem to change the answer.

I _think_ what you are saying is that an SCM where your repository is a 
wide open black hole with no quality control is a problem, but that's 
not the SCM's fault.  You are the filter, the SCM is simply an accounting/
filing system.

> > > I know that source control advocates say that using source control makes
> > > it easy to revert bad stuff, but that's simply not TRUE.  It's _not_
> > > easy to revert bad stuff.
> >
> > It's trivial to revert bad stuff if other stuff hasn't come to depend
> > on that bad stuff, assuming a reasonable SCM system.
> 
> Well, there's the other part to it - most bad stuff is just "random crap",
> and may not have any physical bad tendencies except to make the code
> uglier. Then, people don't even realize that they are doing things the
> wrong way, because they do cut-and-paste, or they just can't do things the
> sane way because the badness assumes a certain layout.
> 
> And THAT is where badness is actively hurtful, while not being buggy.
> Which is why I'd much rather have people work on maintenance, and not rely
> on the bogus argument of "we can always undo it".

No argument.  In fact, wild agreement.  I absolutely *hate* bad crap
being checked into the tree because when it is fixed later it obscures
the original reason for the addition of the code in the first place.
While we rarely reach it, I think we can agree it would be great if code
were checked in once and never modified again because it is perfect.
Obviously a pipe dream, but I think it is the sentiment you are expressing
- don't check in garbage, check in good stuff, and anything that makes
checking in garbage easier is a Bad Thing (tm).

Switching topics just slightly, isn't one of the main problems with SCM
systems that the end user does the merges rather than the maintainer?
Look at how you do it:

	a) release tree
	b) wait for patches
	c) weed through patches looking for good ones
	d) apply patches, which means merging in some cases
	e) repeat

but your typical SCM has the end user doing the merges, not the maintainer.
If you had an SCM system which allowed the maintainer to do all or some of
the merging, would that help?
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news.tele.dk!small.news.tele.dk!
129.240.148.23!uio.no!nntp.uio.no!ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Subject: Re: The direction linux is taking
To: l...@bitmover.com (Larry McVoy)
Original-Date: 	Thu, 27 Dec 2001 20:43:58 +0000 (GMT)
Cc: torva...@transmeta.com (Linus Torvalds), linux-ker...@vger.kernel.org
In-Reply-To: <20011227121033.F25698@work.bitmover.com> 
from "Larry McVoy" at Dec 27, 2001 12:10:33 PM
X-Mailer: ELM [version 2.5 PL6]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Original-Message-Id: <E16JhNe-0006mP-00@the-village.bc.nu>
From: Alan Cox <a...@lxorguk.ukuu.org.uk>
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Thu, 27 Dec 2001 20:36:07 GMT
Message-ID: <fa.h6hf4fv.16luq13@ifi.uio.no>
References: <fa.ha94nvv.1564ki2@ifi.uio.no>
Lines: 15

> Huh.  I'm not sure I understand this.  Once you accept a patch into the
> mainline source, are these people still supposed to maintain that patch?
> I would think the patch is now sort of dead, and any subsequent changes

The patch may be dead, but you want a likelyhood that the person who made
the patch will continue to fix it if it added new stuff. If its a bug fix
it may well be dead, if its a driver or a chunk of vm code then it needs
maintaining longer term.

Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!
ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
X-Authentication-Warning: penguin.transmeta.com: torvalds owned process doing -bs
Original-Date: 	Thu, 27 Dec 2001 12:41:15 -0800 (PST)
From: Linus Torvalds <torva...@transmeta.com>
To: Larry McVoy <l...@bitmover.com>
cc: <linux-ker...@vger.kernel.org>
Subject: Re: The direction linux is taking
In-Reply-To: <20011227123344.H25698@work.bitmover.com>
Original-Message-ID: <Pine.LNX.4.33.0112271236120.1167-100000@penguin.transmeta.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Thu, 27 Dec 2001 20:44:49 GMT
Message-ID: <fa.o9pdenv.h4e4ba@ifi.uio.no>
References: <fa.hap6ogv.16mak2f@ifi.uio.no>
Lines: 47


On Thu, 27 Dec 2001, Larry McVoy wrote:
> > >
> > > Huh.  I'm not sure I understand this.  Once you accept a patch into the
> > > mainline source, are these people still supposed to maintain that patch?
> >
> > [Linus stuff]
>
> But this didn't answer my question at all.  My question was why is this a
> problem related to a source management system?  I can see how to exactly
> mimic what described Al doing in BK so if that is the definition of goodness,
> the addition (or absence) of a SCM doesn't seem to change the answer.

Ok, I see what you are asking for.

No, I'm taking a bigger view. A patch is not just a "patch". A patch has a
lot of stuff around it, one being the unknowable information on whether
the sender of the patch is somebody who will do a good job maintaining the
things the patch impacts.

That's something a source control system doesn't give you - but that
doesn't mean that you cannot use a SCM as a tool anyway.

> I _think_ what you are saying is that an SCM where your repository is a
> wide open black hole with no quality control is a problem, but that's
> not the SCM's fault.  You are the filter, the SCM is simply an accounting/
> filing system.

Right. But that's true only if I use SCM as a _personal_ medium, which
doesn't help my external patch acceptance.

So even if I used CVS or BK internally, that's not what people _gripe_
about.  People want write access, not just a SCM.

> but your typical SCM has the end user doing the merges, not the maintainer.
> If you had an SCM system which allowed the maintainer to do all or some of
> the merging, would that help?

Well, that's what the filesystem is for me right now ;)

		Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
news.tele.dk!small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!
ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Date: 	Thu, 27 Dec 2001 12:50:28 -0800
From: Larry McVoy <l...@bitmover.com>
To: Linus Torvalds <torva...@transmeta.com>
Cc: Larry McVoy <l...@bitmover.com>, linux-ker...@vger.kernel.org
Subject: Re: The direction linux is taking
Original-Message-ID: <20011227125028.J25698@work.bitmover.com>
Mail-Followup-To: Linus Torvalds <torva...@transmeta.com>,
	Larry McVoy <l...@bitmover.com>, linux-ker...@vger.kernel.org
Original-References: <20011227123344.H25...@work.bitmover.com> 
<Pine.LNX.4.33.0112271236120.1167-100...@penguin.transmeta.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <Pine.LNX.4.33.0112271236120.1167-100000@penguin.transmeta.com>; 
from torvalds@transmeta.com on Thu, Dec 27, 2001 at 12:41:15PM -0800
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Thu, 27 Dec 2001 20:52:17 GMT
Message-ID: <fa.h9pep0v.15milie@ifi.uio.no>
References: <fa.o9pdenv.h4e4ba@ifi.uio.no>
Lines: 51

On Thu, Dec 27, 2001 at 12:41:15PM -0800, Linus Torvalds wrote:
> No, I'm taking a bigger view. A patch is not just a "patch". A patch has a
> lot of stuff around it, one being the unknowable information on whether
> the sender of the patch is somebody who will do a good job maintaining the
> things the patch impacts.
> 
> That's something a source control system doesn't give you - but that
> doesn't mean that you cannot use a SCM as a tool anyway.

OK, cool, just checking.  We're on the same page.

> > I _think_ what you are saying is that an SCM where your repository is a
> > wide open black hole with no quality control is a problem, but that's
> > not the SCM's fault.  You are the filter, the SCM is simply an accounting/
> > filing system.
> 
> Right. But that's true only if I use SCM as a _personal_ medium, which
> doesn't help my external patch acceptance.
> 
> So even if I used CVS or BK internally, that's not what people _gripe_
> about.  People want write access, not just a SCM.

I think it is important to distinguish between BK and CVS.  CVS can't do 
what you want, BK can.

People can't have write access in CVS for the obvious reasons, the tree
becomes a chaotic mess of stuff that hasn't been filtered.  But in BK,
because each workspace is a repository, people inherently have write
access to *their* repository.  So they get SCM.  And they may eventually
get their stuff into your tree if you ever accept the changeset.

There are problems with this, BK isn't perfect, but it is much closer 
to solving the set of problems you are describing that CVS can ever 
hope to be.

> > but your typical SCM has the end user doing the merges, not the maintainer.
> > If you had an SCM system which allowed the maintainer to do all or some of
> > the merging, would that help?
> 
> Well, that's what the filesystem is for me right now ;)

Yes, and it works great for easy merges.  It sucks for complicated merges.
BK can help you a great deal with those merges.  
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news.tele.dk!
small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!ifi.uio.no!
internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Date: 	Sat, 29 Dec 2001 11:37:49 -0800
From: Larry McVoy <l...@bitmover.com>
To: Oliver Xymoron <oxymo...@waste.org>
Cc: Christer Weinigel <win...@hog.ctrl-c.liu.se>, linux-ker...@vger.kernel.org
Subject: Re: The direction linux is taking
Original-Message-ID: <20011229113749.D19306@work.bitmover.com>
Mail-Followup-To: Oliver Xymoron <oxymo...@waste.org>,
	Christer Weinigel <win...@hog.ctrl-c.liu.se>,
	linux-ker...@vger.kernel.org
Original-References: <20011229190600.2556C36...@hog.ctrl-c.liu.se> 
<Pine.LNX.4.43.0112291313160.18183-100...@waste.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <Pine.LNX.4.43.0112291313160.18183-100000@waste.org>; 
from oxymoron@waste.org on Sat, Dec 29, 2001 at 01:18:46PM -0600
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Sat, 29 Dec 2001 19:39:16 GMT
Message-ID: <fa.h99mnnv.106ela0@ifi.uio.no>
References: <fa.j804idv.jgkdbn@ifi.uio.no>
Lines: 52

[patchbot stuff]

I normally stay out of these discussions because whatever I say usually
gets taken as "he's just promoting BitKeeper" but I think a point needs
to be made.  I promise not to mention BK.



One thing that people seem to be ignoring is that patches tend to need
to be merged.  The only way that can not be true is if the baseline is
revved every time a patch is applied, people get the new baseline before
they send in a patch.

If you have N people trying to patch the same file, you'll require N
releases and some poor shlep is going to have to resubmit their patch
N-1 times before it gets in.

If you look at this carefully, you'll see that in order to have an automated
system, you must serialize all development which touches the same files
(or the same areas in the same files if you are willing to automerge,
but automerging outside of an SCM is difficult to say the least).

I think this is basically why systems like what is being proposed fizzle
out; it's certainly come up over and over.  The world wants to work in
parallel (think "1000's of Linux developers world wide", yeah, it's BS
but there are certainly a couple hundred).  Forcing people to work in
serial isn't the answer.

One way to quantify this is to ask Linus, Alan, Marcelo, et al, how much
time they spend merging, i.e., how often do they get patch rejects?
Regardless of the answer, it will be interesting.  If it is a lot,
then the patchbot idea has marginal usefulness.  If it is none at all,
then that says development is serialized, which means we may be leaving
a lot of progress on the floor.

I wouldn't be surprised if the serialized case is the answer, or close
to it.  It's rare that I hear Open Source leaders complain about merging,
which suggests fairly serialized processes.  In the commercial world,
there is a ton of parallel development and merging is about 90% of what
people do when they are interacting with the SCM system.  Checkin accounts
for about 8%, and after that it's all over the place.

Anyway, I'm interested to see if there are screams of "all I ever do is
merge and I hate it" or "merging?  what's that?".
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news.tele.dk!
small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!ifi.uio.no!
internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Date: 	Sat, 29 Dec 2001 16:03:34 -0500
From: Benjamin LaHaise <b...@redhat.com>
To: Oliver Xymoron <oxymo...@waste.org>,
        Christer Weinigel <win...@hog.ctrl-c.liu.se>,
        linux-ker...@vger.kernel.org
Subject: Re: The direction linux is taking
Original-Message-ID: <20011229160334.A9919@redhat.com>
Original-References: <20011229190600.2556C36...@hog.ctrl-c.liu.se> 
<Pine.LNX.4.43.0112291313160.18183-100...@waste.org> 
<20011229113749.D19...@work.bitmover.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20011229113749.D19306@work.bitmover.com>; 
from lm@bitmover.com on Sat, Dec 29, 2001 at 11:37:49AM -0800
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Sat, 29 Dec 2001 21:06:16 GMT
Message-ID: <fa.dsujbhv.u480qe@ifi.uio.no>
References: <fa.h99mnnv.106ela0@ifi.uio.no>
Lines: 23

On Sat, Dec 29, 2001 at 11:37:49AM -0800, Larry McVoy wrote:
> If you have N people trying to patch the same file, you'll require N
> releases and some poor shlep is going to have to resubmit their patch
> N-1 times before it gets in.

Wrong.  Most patches are independant, and even touch different functions.  
Things like "add member foo of type baz to struct z" are independant 
changes even if they conflict when patching.

> Anyway, I'm interested to see if there are screams of "all I ever do is
> merge and I hate it" or "merging?  what's that?".

How about "I'm sick of resending this one line bugfix to maintainer of 
$foo who keeps dropping it"?  That's the problem that patchbot is meant 
to solve, not the merging problem.  If the people responsible for applying 
patches were perfect, we wouldn't need it.

		-ben
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
logbridge.uoregon.edu!news.tele.dk!small.news.tele.dk!129.240.148.23!
uio.no!nntp.uio.no!ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Date: 	Sat, 29 Dec 2001 14:04:10 -0800
From: Larry McVoy <l...@bitmover.com>
To: Benjamin LaHaise <b...@redhat.com>
Cc: Oliver Xymoron <oxymo...@waste.org>,
        Christer Weinigel <win...@hog.ctrl-c.liu.se>,
        linux-ker...@vger.kernel.org
Subject: Re: The direction linux is taking
Original-Message-ID: <20011229140410.A13883@work.bitmover.com>
Mail-Followup-To: Benjamin LaHaise <b...@redhat.com>,
	Oliver Xymoron <oxymo...@waste.org>,
	Christer Weinigel <win...@hog.ctrl-c.liu.se>,
	linux-ker...@vger.kernel.org
Original-References: <20011229190600.2556C36...@hog.ctrl-c.liu.se> 
<Pine.LNX.4.43.0112291313160.18183-100...@waste.org> 
<20011229113749.D19...@work.bitmover.com> <20011229160334.A9...@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <20011229160334.A9919@redhat.com>; 
from bcrl@redhat.com on Sat, Dec 29, 2001 at 04:03:34PM -0500
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Sat, 29 Dec 2001 22:05:36 GMT
Message-ID: <fa.h68uo7v.1062nae@ifi.uio.no>
References: <fa.dsujbhv.u480qe@ifi.uio.no>
Lines: 35

On Sat, Dec 29, 2001 at 04:03:34PM -0500, Benjamin LaHaise wrote:
> On Sat, Dec 29, 2001 at 11:37:49AM -0800, Larry McVoy wrote:
> > If you have N people trying to patch the same file, you'll require N
> > releases and some poor shlep is going to have to resubmit their patch
> > N-1 times before it gets in.
> 
> Wrong.  Most patches are independant, and even touch different functions.  

Really?  And the data which shows this absolute statement to be true is
where?  I'm happy to believe data, but there is no data here.

> Things like "add member foo of type baz to struct z" are independant 
> changes even if they conflict when patching.

So what?  A conflict is anything that the patch(1) can't handle automatically.
The fact that the conflicts are independent changes is irrelevant, patch
doesn't care.

> > Anyway, I'm interested to see if there are screams of "all I ever do is
> > merge and I hate it" or "merging?  what's that?".
> 
> How about "I'm sick of resending this one line bugfix to maintainer of 
> $foo who keeps dropping it"?  That's the problem that patchbot is meant 
> to solve, not the merging problem.

OK, so go solve it already.  Just don't be surprised when if it doesn't
get used because it is yet another 10% solution.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
newsmi-us.news.garr.it!newsmi-eu.news.garr.it!NewsITBone-GARR!
newsfeeds.belnet.be!news.belnet.be!news.tele.dk!small.news.tele.dk!
129.240.148.23!uio.no!nntp.uio.no!ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Subject: Re: The direction linux is taking
To: l...@bitmover.com (Larry McVoy)
Original-Date: 	Sat, 29 Dec 2001 22:58:27 +0000 (GMT)
Cc: b...@redhat.com (Benjamin LaHaise), oxymo...@waste.org (Oliver Xymoron),
        win...@hog.ctrl-c.liu.se (Christer Weinigel),
        linux-ker...@vger.kernel.org
In-Reply-To: <20011229140410.A13883@work.bitmover.com> 
from "Larry McVoy" at Dec 29, 2001 02:04:10 PM
X-Mailer: ELM [version 2.5 PL6]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Original-Message-Id: <E16KSQt-0005zf-00@the-village.bc.nu>
From: Alan Cox <a...@lxorguk.ukuu.org.uk>
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Sat, 29 Dec 2001 22:54:02 GMT
Message-ID: <fa.h2j187v.1gncu91@ifi.uio.no>
References: <fa.h68uo7v.1062nae@ifi.uio.no>
Lines: 18

> > Wrong.  Most patches are independant, and even touch different functions.  
> 
> Really?  And the data which shows this absolute statement to be true is
> where?  I'm happy to believe data, but there is no data here.

I rarely get clashes in merges with either 2.2 or with 2.4-ac when I was
doing it. Offsets from multiple patches to the same file happen some times
but its very rare two people had overlapping changes and when it happened
it almost always meant that the two of them needed to talk because they were
fixing the same thing or adding related features.
 
The big exception is Configure.help which is a nightmare for patch, and the
one file I basically always did hand merges on
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news.tele.dk!
small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!ifi.uio.no!
internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Original-Date: 	Sat, 29 Dec 2001 15:14:40 -0800
From: Larry McVoy <l...@bitmover.com>
To: Alan Cox <a...@lxorguk.ukuu.org.uk>
Cc: Larry McVoy <l...@bitmover.com>, Benjamin LaHaise <b...@redhat.com>,
        Oliver Xymoron <oxymo...@waste.org>,
        Christer Weinigel <win...@hog.ctrl-c.liu.se>,
        linux-ker...@vger.kernel.org
Subject: Re: The direction linux is taking
Original-Message-ID: <20011229151440.A21760@work.bitmover.com>
Mail-Followup-To: Alan Cox <a...@lxorguk.ukuu.org.uk>,
	Larry McVoy <l...@bitmover.com>, Benjamin LaHaise <b...@redhat.com>,
	Oliver Xymoron <oxymo...@waste.org>,
	Christer Weinigel <win...@hog.ctrl-c.liu.se>,
	linux-ker...@vger.kernel.org
Original-References: <20011229140410.A13...@work.bitmover.com> 
<E16KSQt-0005zf...@the-village.bc.nu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <E16KSQt-0005zf-00@the-village.bc.nu>; 
from alan@lxorguk.ukuu.org.uk on Sat, Dec 29, 2001 at 10:58:27PM +0000
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Sat, 29 Dec 2001 23:16:09 GMT
Message-ID: <fa.h6oso7v.12m4kq0@ifi.uio.no>
References: <fa.h2j187v.1gncu91@ifi.uio.no>
Lines: 39

On Sat, Dec 29, 2001 at 10:58:27PM +0000, Alan Cox wrote:
> > > Wrong.  Most patches are independant, and even touch different functions.  
> > 
> > Really?  And the data which shows this absolute statement to be true is
> > where?  I'm happy to believe data, but there is no data here.
> 
> I rarely get clashes in merges with either 2.2 or with 2.4-ac when I was
> doing it. Offsets from multiple patches to the same file happen some times
> but its very rare two people had overlapping changes and when it happened
> it almost always meant that the two of them needed to talk because they were
> fixing the same thing or adding related features.

So that means that pretty much 100% of development to any one area is being
done by one person?!?   That's cool, but doesn't it limit the speed at which
forward progress can be made?  And does that mean for any area there is only
one person who really understands it?

I'm not sure that you want single threading of development to be something
enforced by your development process, and that's what it is starting to 
sound like more and more.  Isn't it true that a lack of merge conflicts
means that there is no parallel development in that area?  

We have lots of commercial customers using BK on the Linux kernel, they
are doing embedded this and that.  The rate of change that they make is
much greater than the rate of change made in the Linus maintained tree.
I'm not saying it's good or bad, it's just different.  I can say that
merging is a huge issue in commercial shops.  It's interesting to hear 
that it is not in Linux.

Some sociology guy with a CS background should do a study on this and 
explore the differences.  Is fast change better?  Is slow change better?
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news.tele.dk!
small.news.tele.dk!129.240.148.23!uio.no!nntp.uio.no!ifi.uio.no!
internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Subject: Re: The direction linux is taking
To: l...@bitmover.com (Larry McVoy)
Original-Date: 	Sun, 30 Dec 2001 02:36:57 +0000 (GMT)
Cc: a...@lxorguk.ukuu.org.uk (Alan Cox), l...@bitmover.com (Larry McVoy),
        b...@redhat.com (Benjamin LaHaise),
        oxymo...@waste.org (Oliver Xymoron),
        win...@hog.ctrl-c.liu.se (Christer Weinigel),
        linux-ker...@vger.kernel.org
In-Reply-To: <20011229151440.A21760@work.bitmover.com> 
from "Larry McVoy" at Dec 29, 2001 03:14:40 PM
X-Mailer: ELM [version 2.5 PL6]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Original-Message-Id: <E16KVqL-0006dX-00@the-village.bc.nu>
From: Alan Cox <a...@lxorguk.ukuu.org.uk>
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Sun, 30 Dec 2001 02:28:42 GMT
Message-ID: <fa.gp44u7v.1t6gg92@ifi.uio.no>
References: <fa.h6oso7v.12m4kq0@ifi.uio.no>
Lines: 13

> So that means that pretty much 100% of development to any one area is being
> done by one person?!?   That's cool, but doesn't it limit the speed at which

It means that pretty much all development in one area is already being
co-ordinated. It also means that bug fixes tend to be small and not overlap
other changes.

The "central person" thing within groups seems to just evolve
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!
newsfeed.direct.ca!look.ca!newsfeed1.cidera.com!Cidera!news2.dg.net.ua!
bn.utel.com.ua!carrier.kiev.ua!horse.lucky.net!carrier.kiev.ua!
solar.carrier.kiev.ua!not-for-mail
From: Larry McVoy <l...@bitmover.com>
Newsgroups: lucky.linux.kernel
Subject: Re: The direction linux is taking
Date: Sun, 30 Dec 2001 02:53:39 +0000 (UTC)
Organization: unknown
Lines: 69
Sender: n...@solar.carrier.kiev.ua
Approved: newsmas...@lucky.net
Message-ID: <20011229184921.B27114@work.bitmover.com>
References: <20011229151440.A21760@work.bitmover.com> 
<E16KVqL-0006dX-00@the-village.bc.nu>
NNTP-Posting-Host: solar.carrier.kiev.ua
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: solar.carrier.kiev.ua 1009680820 11656 193.193.193.124 (30 Dec 2001 02:53:40 GMT)
X-Complaints-To: usenet@solar.carrier.kiev.ua
NNTP-Posting-Date: Sun, 30 Dec 2001 02:53:40 +0000 (UTC)
Mail-Followup-To: Alan Cox <a...@lxorguk.ukuu.org.uk>,
X-Mailer: Mutt 1.0.1i
In-Reply-To: <E16KVqL-0006dX-00@the-village.bc.nu>; 
from alan@lxorguk.ukuu.org.uk on Sun, Dec 30, 2001 at 02:36:57AM +0000
X-Mailing-List: 	linux-kernel@vger.kernel.org
X-Comment-To: Alan Cox

On Sun, Dec 30, 2001 at 02:36:57AM +0000, Alan Cox wrote:
> > So that means that pretty much 100% of development to any one area is being
> > done by one person?!?   That's cool, but doesn't it limit the speed at which
> 
> It means that pretty much all development in one area is already being
> co-ordinated. It also means that bug fixes tend to be small and not overlap
> other changes.

It also means that your rate of change in a single area is limited to 
the output of one human being.  Either the human doing the work or
the human doing the merging.  So far, it seems more like nobody is 
doing any merging, Dave says someone does but nobody else has spoken
up and I tend to think that merging is not a common process in the
Linux tree, the rate of change sort of indicates that.  I suspect 
that people avoid merge conflicts because they hurt, because of 
the poor tools. 

    "Docter it hurts when I have to merge"
    "So don't do that."

Single threading development is fine, it has benefits, but it also
has costs.  It's a tradeoff.

No commercial software firm would but up with a development process
which caused that to be the case.  They may want it to be the case,
but they want to be able to choose.  We used to have pretty good merge
technology, much better than CVS, and we still got beat up all the time
about it until we made it what it is today.  

The point there is that if commercial firms coordinated the merging by
hand, either by doing it by hand or avoiding it by hand - one of which
has to be true in the Linux development community - then we would have
never heard a word about our merge technology.  In this respect, the
commercial shops are way way ahead of Linux.  They can choose to work
like Linux does, that's an option, and yet they don't.  It's way too
time consuming for little or no gain.  You should think about that.
They learn from you, they're cherry picking your best stuff, what are
you getting from them?

There are others out here who have worked at big OS shops, they can
back this up.  Hey, Pete, what would happen at Sun if they took 
filemerge away?  How long do you think that would last?

I can also tell you that your description does not at all match what
is happening in the Linux/PPC development nor the MySQL development.
They have merge conflicts all the time and we have years of data to prove
it.  If you would like the exact numbers for the PPC tree, for example,
I can give them to you.  I can also give you numbers for BK itself;
we're a small team but we have merge conflicts daily.  We wouldn't
make any progress if we were all waiting on each other all the time.
Nor would we be able to support the code if only one person got to work
on a particular area; that's a dangerous approach, it means that you are
dependent on that one person.  I can see it for Linus, he's sort of Mr
Good Taste, but I can't see it making sense for particular sections of
the code.  Each section should have at least two active experts.

The point is that while you may live in a world where merging is rare,
but I suspect that's almost certainly caused by poor tools.  If that
weren't the case, can you explain why when the PPC team moved over to BK,
we saw lots of merge conflicts?  BK didn't make those up, they reflect
what the people did faithfully.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
newsfeeds.belnet.be!news.belnet.be!news.tele.dk!small.news.tele.dk!
129.240.148.23!uio.no!nntp.uio.no!ifi.uio.no!internet-mailinglist
Newsgroups: fa.linux.kernel
Return-Path: <linux-kernel-ow...@vger.kernel.org>
Subject: Re: The direction linux is taking
To: l...@bitmover.com (Larry McVoy)
Original-Date: 	Sun, 30 Dec 2001 10:07:36 +0000 (GMT)
Cc: a...@lxorguk.ukuu.org.uk (Alan Cox), l...@bitmover.com (Larry McVoy),
        b...@redhat.com (Benjamin LaHaise),
        oxymo...@waste.org (Oliver Xymoron),
        win...@hog.ctrl-c.liu.se (Christer Weinigel),
        linux-ker...@vger.kernel.org
In-Reply-To: <20011229184921.B27114@work.bitmover.com> 
from "Larry McVoy" at Dec 29, 2001 06:49:21 PM
X-Mailer: ELM [version 2.5 PL6]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Original-Message-Id: <E16KcsS-0000hb-00@the-village.bc.nu>
From: Alan Cox <a...@lxorguk.ukuu.org.uk>
Sender: linux-kernel-ow...@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org
Organization: Internet mailing list
Date: Sun, 30 Dec 2001 10:02:17 GMT
Message-ID: <fa.h1ksvvv.11l0nh4@ifi.uio.no>
References: <fa.h7pgnfv.13mgk29@ifi.uio.no>
Lines: 25

> the human doing the merging.  So far, it seems more like nobody is 
> doing any merging, Dave says someone does but nobody else has spoken

Lots of people do. I get all my wireless, my isdn, my usb
patches all nicely prepacked and merged for example.

> up and I tend to think that merging is not a common process in the
> Linux tree, the rate of change sort of indicates that.  I suspect 

The primary limit on the rate of change is the rate at which Linus merges
stuff, nothing else.

> is happening in the Linux/PPC development nor the MySQL development.
> They have merge conflicts all the time and we have years of data to prove

For the ppc folks I guess because they are keeping a parallel tree. Thats a 
totally different animal because you collide continually with things you've
submitted and changes in the core tree.

Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

			        About USENET

USENET (Users’ Network) was a bulletin board shared among many computer
systems around the world. USENET was a logical network, sitting on top
of several physical networks, among them UUCP, BLICN, BERKNET, X.25, and
the ARPANET. Sites on USENET included many universities, private companies
and research organizations. See USENET Archives.

		       SCO Files Lawsuit Against IBM

March 7, 2003 - The SCO Group filed legal action against IBM in the State 
Court of Utah for trade secrets misappropriation, tortious interference, 
unfair competition and breach of contract. The complaint alleges that IBM 
made concentrated efforts to improperly destroy the economic value of 
UNIX, particularly UNIX on Intel, to benefit IBM's Linux services 
business. See SCO vs IBM.

The materials and information included in this website may only be used
for purposes such as criticism, review, private study, scholarship, or
research.

Electronic mail:			       WorldWideWeb:
   tech-insider@outlook.com			  http://tech-insider.org/