Message-ID: <200201282213.g0SMDcU25653@snark.thyrsus.com>
Content-Type: text/plain; charset=US-ASCII
From: Rob Landley <land...@trommello.org>
Subject: A modest proposal -- We need a patch penguin
Date: Mon, 28 Jan 2002 23:20:10 +0100
X-Mailer: KMail [version 1.3.1]
MIME-Version: 1.0
Content-Transfer-Encoding: 7BIT
Sender: robo...@news.nic.it
X-Mailing-List: linux-kernel@vger.kernel.org
Approved: robo...@news.nic.it (1.20)
NNTP-Posting-Host: a.917.anti-phl.bofh.it
Newsgroups: linux.kernel
Organization: linux.*_mail_to_news_unidirectional_gateway
Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
news.tele.dk!small.news.tele.dk!212.177.105.133!news.mailgate.org!bofh.it!
robomod
X-Original-Cc: torva...@transmeta.com, a...@lxorguk.ukuu.org.uk (Alan Cox),
da...@suse.de (Dave Jones), e...@thyrsus.com
X-Original-Date: Mon, 28 Jan 2002 09:10:56 -0500
X-Original-Sender: linux-kernel-ow...@vger.kernel.org
X-Original-To: linux-ker...@vger.kernel.org
Lines: 277
Patch Penguin Proposal.
1) Executive summary.
2) The problem.
3) The solution.
4) Ramifications.
-- Executive summary.
Okay everybody, this is getting rediculous. Patches FROM MAINTAINERS are
getting dropped on the floor on a regular basis. This is burning out
maintainers and is increasing the number of different kernel trees (not yet a
major fork, but a lot of cracks and fragmentation are showing under the
stress). Linus needs an integration lieutenant, and he needs one NOW.
We need to create the office of "patch penguin", whose job would be to make
Linus's life easier by doing what Alan Cox used to do, and what Dave Jones is
unofficially doing right now. (In fact, I'd like to nominate Dave Jones for
the office, although it's Linus's decision and it would be nice if Dave got
Alan Cox's blessing as well.)
And if we understand this position, and formalize it, we can make better use
of it. It can solve a lot of problems in linux development.
-- The problem.
Linus doesn't scale, and his current way of coping is to silently drop the
vast majority of patches submitted to him onto the floor. Most of the time
there is no judgement involved when this code gets dropped. Patches that fix
compile errors get dropped. Code from subsystem maintainers that Linus
himself designated gets dropped. A build of the tree now spits out numerous
easily fixable warnings, when at one time it was warning-free. Finished code
regularly goes unintegrated for months at a time, being repeatedly resynced
and re-diffed against new trees until the code's maintainer gets sick of it.
This is extremely frustrating to developers, users, and vendors, and is
burning out the maintainers. It is a huge source of unnecessary work. The
situation needs to be resolved. Fast.
If you think I'm preaching to the choir, skip to the next bit called "the
solution". If not, read on...
The Linux tree came very close to forking during 2.4. We went eleven months
without a development tree. The founding of the Functionally Overloaded Linux
Kernel project was a symptom of an enormous unintegrated patch backlog
building up pressure until at least a small fork was necessary. Even with 2.5
out, the current high number of seperate development trees accepting
third-party is still alarmingly high. Linus and Marcelo have been joined by
Dave Jones, Alan Cox, Andrea Arcangeli, Michael Cohen, and others, with
distributors maintaining their own significantly forked kernel trees as a
matter of course. Developers like Andrea, Robert Love and Rik van Riel either
distribute others' relatively unrelated patches with their patch sets, or
base their patches on other, as yet unintegrated patches for extended periods
of time.
Discussion of this problem was covered by kernel traffic and Linux Weekly
News:
http://kt.zork.net/kernel-traffic/kt20020114_150.html#5
http://lwn.net/2002/0103/kernel.php3 (search for "patch management").
During 2.4, the version skew between Alan Cox's tree and Linus's tree got as
bad as it's ever been. Several of the bug fixes in Alan's tree (which he
stopped maintaining months ago) still are not present in 2.4.17 or 2.5. Rik
van Riel has publicly complained that Linus dropped his VM patches on the
floor for several months, a contributing factor to the 2.4 VM's failure to
stabilize for almost a -YEAR- after its release. (This is a bad sign. Whether
Rik's or Andrea's VM is superior is a side issue. Alan Cox, and through him
Red Hat, got Rik's VM to work acceptably by integrating patches from that
VM's maintainer. The fact Linus didn't do as well is a symptom of this larger
problem. The kind of subsystem swapping so major it requires a new maintainer
should not be necessary during a stable series.)
Speaking of Andrea Arcangeli, he's now integrating third-party patches into
his own released development trees, because 2.5 isn't suitable to do
development against and 2.4 doesn't have existing work (like low latency)
he's trying to extend.
Andre Hedrick just had to throw a temper tantrum to get any attention paid to
his IDE patches, and he's the official IDE maintainer. Eric Raymond tells me
his help file updates have now been ignored for 33 consecutive releases
(again, he's the maintainer), and this combined with recent major changes
Linus unilaterally made to 2.5's help files (still without syncing with the
maintainer's version before doing so) has created a lot of extra and totally
unnecessary work for Eric, and he tells me it's made the version skew between
2.4 and 2.5 almost unmanageable.
Andrew Morton's lock splitting low latency work has no forseeable schedule
for inclusion, despite the fact it's needed whether or not Robert Love's
preemption patch goes in. Ingo Molnar's O(1) scheduler did go in, but that
was largely a case of good timing: it came right on the heels of a public
argument about why Linus had not accepted patches to the scheduler for
several years. The inclusion of code like JFS, XFS, and Daniel Phillips' ext2
indexing patch are left up to distributions to integrate and ship long before
they make it into Linus's tree. (Remember the software raid code in 2.2?)
These are just the patches that have persisted, how much other good work
doesn't last because its author loses interest after six months of the silent
treatment? The mere existence of the "Functionally Overloaded Linux Kernel"
(FOLK) project, to collect together as many unintegrated patches as possible,
was a warning sign that things were not going smoothly on the patch
integration front.
The release of 2.5 has helped a bit, but by no means solved the problem. Dave
Jones started his tree because 2.4 fixes Marcello had accepted were not
finding their way into 2.5. Even code like Keith Owens' new build system and
CML2, both of which Linus approved for inclusion at the Kernel summit almost
a year ago and even tentatively scheduled for before 2.5.2, are still not
integrated with no clear idea if they ever will be. (Yes Linus can change his
mind about including them, but total silence isn't the best way to indicate
this. Why leave Keith and Eric hanging, and wasting months or even years of
their time still working on code Linus may not want?)
The fact that 2.5 has "pre" releases seems suggestive of a change in mindset.
A patch now has to be widely used, tested, and recommended even to get into
2.5, yet how does the patch get such testing before it's integrated into a
buildable kernel? Chicken and egg problem there, you want more testing but
without integration each testers can test fewer patches at once.
There has even been public talk of CRON jobs to resubmit patches to Linus
periodically for as long as it takes him to get around to dealing with them.
Linus has actually endorsed this approach (provided that re-testing of the
patches against the newest release before they are remailed is also
automated). This effort has spawned a mailing list. That's just nuts. The
fact that Linus doesn't scale isn't going to be solved by increasing the
amount of mail he gets. When desperate measures are being seriously
considered, we must be in desperate times.
-- The solution.
The community needs to offload some work from Linus, so he can focus on what
he does that nobody else can. This offloading and delegation has been done
before, with the introduction of subsystem maintainers. We just need to
extend the maintainer concept to include an official and recognized
integration maintainer.
During 2.1, when Linus burned out, responsibility for various subsystems were
delegated to lieutenants to make Linus' job more manageable. Lieutenants are
maintainers of various parts of the tree who collect and clean up patches,
and make the first wave of obvious decisions ("this patch doesn't apply",
"this bit doesn't compile", "my machine panicked", "look, it's not SMP safe")
before sending tested code off to Linus. Linus still spends a lot of his time
reading and auditing code, but by increasing the average quality of the code
Linus looks at, the maintainers make his job easier. The more work
maintainers can do the less Linus has to.
So what tasks does Linus still personally do? He's an architect. He steers
the project, vetoing patches he doesn't like and suggesting changes in
direction to the developers. And he's the final integrator, pulling together
dispirate patches into one big system.
The job of architect is something only Linus can do. The job of integrator is
something many people can do. Alan Cox did it for years. Dave Jones is doing
it now, and Michael Cohen has yet another tree. Every Linux distributor has
its own tree. Integrating patches so they don't conflict and porting them to
new versions is hard work, but not brain surgery.
Linus is acting as a central collection point for patches, and patches are
getting lost on their way to that collection point. Patches as big as UML and
EXT3 were going into Alan Cox's tree during 2.4, and now new patches are
going into Dave Jones's tree to be tested out and queued for Linus.
Integration is a task that can be delegated, and it has been. In Perl's
model, Larry Wall is the benevolent dictator and architect, but integration
work is done by the current holder of the "patch pumpkin". In Linux, Alan Cox
used to be the de facto holder of the patch penguin, and now Dave Jones is
maintaining a tree which can accept and integrate patches, and then feed them
on to Linus when Linus is ready.
This system should be formalized, we need the patch penguin to become
official. The patch penguin seems to have passed from Alan Cox to Dave Jones.
If we recognize this, we can make much better use of it.
--- Ramifications.
The holder of the patch penguin's job would be to accept patches from people
other than linus, make them work together in a publicly compilable and
testable tree, and feed good patches on to Linus. This may sound simple and
obvious, but it's currenlty not happening and its noticeable by its absence.
The purpose of the patch penguin tree is to make life easier, both for Linus
and the developer community. With a designated patch collector and
integrator, Linus's job becomes easier. Linus would still maintain and
release his own kernel trees (the way he did when Alan Cox regularly fed him
patches), and Linus could still veto any patch he doesn't like (whether it
came from the patch penguin, directly from a subsystem maintainer, or
elsewhere). But Linus wouldn't be asked to act as the kernel's public CVS
tree anymore. He could focus on being the architect.
The bulk of the patch penguin's work would be to accept, integrate, and
update patches from designated subsystem maintainers, maintaining his own
tree (seperate from linus's) containing the integrated collection of pending
patches awaiting inclusion in Linus's tree. Patches submitted directly to the
patch penguin could be redirected to subsystem maintainers where appropriate,
or bounced with a message to that effect (at the patch penguin's option).
This integration and patch tracking work is a fairly boring, thankless task,
but it's work somebody other than Linus can do, which Linus has to do
otherwise. (And which Linus is NOT doing a good job at right now.)
The rest of the patch-penguin holder's job is to feed Linus patches. The
patch penguin holder's tree would fundamentally be a delta against the most
recent release from Linus (like the "-ac patches" used to be). If Linus takes
several releases to get around to looking at a new patch, the patch penguin
would resynchronize their tree with each new Linus release, doing the fixups
on the pending patch set (or bullying the source of each patch into doing
so). It would be the patch penguin's job to keep up with Linus, not the other
way around. When a change happens in Linus's tree that didn't come from the
patch penguin, the patch penguin integrates the change into their tree
automatically.
The holder of the patch penguin would feed Linus good patches, by Linus's
standards. Not just tested ones, but small bite-sized patches, one per email
as plain text includes, with an explanation of what each patch does at the
top of the mail. (Just the way Linus likes them. :) Current pending patches
from the patch penguin tree could even be kept at a public place (like
kernel.org) so Linus could pull rather than push, and grab them when he has
time. The patch penguin tree would make sure that when Linus is ready for a
patch, the patch is ready for Linus.
The patch penguin tree can act as a buffer between Linus and the flood of
patches from the field. When Linus is not ready for a patch yet, he can hold
off on taking it into his tree, and doesn't have to worry about the patch
being lost or out of date by the time he's ready to accept it. When Linus is
focusing on something like the new block I/O code, the backlog of other
patches naturally feeds into the patch penguin tree until Linus is ready to
look at them. People won't have to complain about dropped patches, and Linus
doesn't have to worry that patches haven't been tested enough before being
submitted to him. Users who want to live on the really bleeding edge have a
place to go for a kernel that's likely to break. Testers can find bugs en
masse without having to do integration work (which is in and of itself a
source of potential bugs).
Linus would still have veto power. He gets to reject any patch he doesn't
like, and can ask for the integration lieutenant to back that patch out of
the patch penguin tree. That's one big difference between the patch penguin
tree and Linus's tree: the patch penguin tree is provisional. Stuff that goes
in it can still get backed out in a version or two. Of course Linus would
have to explicitly reject a patch to get it out of the patch penguin tree,
meaning its developer stops fruitlessly re-submitting it to Linus, and maybe
even gets a quick comment from Linus as to WHY it was unacceptable so they
can fix it. (From the developer's point of view, this is a good thing. They
either get feedback of closure.)
Linus sometimes needs time off. Not just for vacations, but to focus on
specific subsections, like integrating Jens Axobe's BIO patches at the start
of 2.5. Currently, these periods hopelessly stall or tangling development.
But in Linus's absence, the patch penguin could continue to maintain a delta
against the last Linus tree, and generate a sequence of small individual
patches like a trail of bread crumbs for Linus to follow when he gets back.
Linus could take a month off, and catch back up in a fraction of that time
when he returned. (And if Linus were to get hit by a bus, the same
infrastructure would allow the community to select and support a new
architect, which might help companies like IBM sleep better at night.) And if
Linus rejected patches halfway through the bread crumb trail requiring a lot
of shuffling in later patches, well, that's more work for the patch penguin,
not more work for Linus.
One reason Linus doesn't like CVS is he won't let other people check code
into his tree. (This is not a capricious decision on Linus's part: no
architect can function if he doesn't know what's in the system. Code review
of EVERYTHING is a vital part of Linus's job.) With a patch penguin tree,
there's no more pressure on Linus to use CVS. The patch penguin can use CVS
if he wants to, and if he wants to give the subsystem maintainers commit
access to the patch penguin tree, that's his business. The patch penguin's
own internal housekeeping toolset shouldn't affect the patches he feeds on to
Linus one way or the other.
Again, Linus likes stuff tested by a wide audience before it's sent to him.
With a growing list of multiple trees maintained by Dave Jones, Alan Cox,
Michael Cohen, Andrea Arcangeli, development and testing become fragmented.
With a single patch penguin tree, the patches drain into a common pool and
the backlog of unintegrated patches can't build up dangerous amounts of
pressure to interfere with development. A single shared "pending" tree means
the largest possible group of potential testers.
-
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/
Message-ID: <200201290137.g0T1bwB24120@karis.localdomain>
Date: Tue, 29 Jan 2002 02:40:17 +0100
From: Francesco Munda <sy...@libero.it>
Subject: Re: A modest proposal -- We need a patch penguin
In-Reply-To: <200201282213.g0SMDcU25653@snark.thyrsus.com>
References: <200201282213.g0SMDcU25653@snark.thyrsus.com>
X-Mailer: Sylpheed version 0.7.0 (GTK+ 1.2.6; i686-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: robo...@news.nic.it
X-Mailing-List: linux-kernel@vger.kernel.org
Approved: robo...@news.nic.it (1.20)
NNTP-Posting-Host: a.796.anti-phl.bofh.it
Newsgroups: linux.kernel
Organization: linux.*_mail_to_news_unidirectional_gateway
Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news.mailgate.org!
newsfeeder.edisontel.com!bofh.it!robomod
X-Original-Cc: linux-ker...@vger.kernel.org
X-Original-Date: Tue, 29 Jan 2002 02:37:57 +0100
X-Original-Sender: linux-kernel-ow...@vger.kernel.org
X-Original-To: Rob Landley <land...@trommello.org>
Lines: 22
On Mon, 28 Jan 2002 09:10:56 -0500
Rob Landley <land...@trommello.org> wrote:
> Patch Penguin Proposal.
>
> [...]
You mean some sort of proxy/two-tier development? A "commit/rollback"
transaction model on the kernel itself?
I deeply agree with you, especially in keeping "many eyes" to look at the
same kernel tree, and not chosing one of the many subtrees; as added bonus,
this stuff is buzzword compliant! What we can ask more? :)
Now, Linus' call to accept _your_ patch. Fingers crossed already.
-- FM
-
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!not-for-mail
From: Rob Landley <land...@trommello.org>
Newsgroups: lucky.linux.kernel
Subject: Re: A modest proposal -- We need a patch penguin
Date: Tue, 29 Jan 2002 03:43:59 +0000 (UTC)
Organization: unknown
Lines: 104
Sender: n...@horse.lucky.net
Approved: newsmas...@lucky.net
Message-ID: <200201290341.g0T3fNU30909@snark.thyrsus.com.lucky.linux.kernel>
References: <200201282213.g0SMDcU25653@snark.thyrsus.com>
<200201290137.g0T1bwB24120@karis.localdomain>
NNTP-Posting-Host: horse.lucky.net
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
X-Trace: horse.lucky.net 1012275839 87612 193.193.193.118
(29 Jan 2002 03:43:59 GMT)
X-Complaints-To: usenet@horse.lucky.net
NNTP-Posting-Date: Tue, 29 Jan 2002 03:43:59 +0000 (UTC)
X-Mailer: KMail [version 1.3.1]
In-Reply-To: <200201290137.g0T1bwB24120@karis.localdomain>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Comment-To: Francesco Munda
On Monday 28 January 2002 08:37 pm, Francesco Munda wrote:
> On Mon, 28 Jan 2002 09:10:56 -0500
>
> Rob Landley <land...@trommello.org> wrote:
> > Patch Penguin Proposal.
> >
> > [...]
>
> You mean some sort of proxy/two-tier development? A "commit/rollback"
> transaction model on the kernel itself?
Think how Alan Cox's tree used to work. Just because Alan accepted a patch
didn't guarantee Linus wasn't going to come up with a reason to shoot it
down. It just meant the patch wasn't going to be ignored, and if it WAS
dropped there would probably going to be some kind of explanation.
Whether the patch penguin wants to use some kind of tool to maintain their
tree (like CVS) with a "commit/rollback" model is a seperate issue. Linus
isn't going to use it, and linus isn't going to have to see it. Linus gets
the kid of patches he likes, which have already had merge clashes and the
really obvious thinkos resolved before he sees them, and have probably even
been tested by the foolhardy individuals currently downloading the -ac, -dj,
and -aa trees.
Right now, Alan's tree is in the process of going back into circulation. He
tells me that his tree is basically a delta against marcello (2.4), and DJ is
doing a delta against linus (2.5). Over time, the need for a 2.4 delta will
probably diminish as new development shifts over to 2.5. Right now, the
patch constipation we've been seeing is, in my opinion, directing development
to occur against 2.4 that should at the very least be eyeing 2.5. (Alan is
probably NOT interested in integrating patches that Marcelo has no intention
of eventually integrating into 2.5. So he's not taking the new development
integration pressure off, that's DJ's job.)
I think DJ could definitely use a clearer mandate.
> I deeply agree with you, especially in keeping "many eyes" to look at the
> same kernel tree, and not chosing one of the many subtrees; as added bonus,
> this stuff is buzzword compliant! What we can ask more? :)
>
> Now, Linus' call to accept _your_ patch. Fingers crossed already.
I'm getting a lot more support off the list than on the list. People seem to
be afraid to cc: linux-kernel. I underestimated how deeply steeped in
politics this issue seems to have become. It seems a fairly straightforward
optmiziation, mainly a clarification of of the way things have been done in
the past and a formalization of a position that got a bit confused in the
transition from one officeholder to another.
Before posting here, I bounced an earlier draft off of both Alan Cox and Dave
Jones. Alan's response was, and I quote:
> I'm certainly fine with DaveJ being the victim 8)
Dave didn't seem to have any major objections but raised a lot technical
points to the effect of "I'm already doing this bit". Both of them gave me
permission to post most of our conversation to the list, but seem unwilling
to do it themselves. :)
I've gotten several other agreements, some from people trying to find an
off-list place we could discuss it (okay, so what's THIS list for again)?
And one person, who shall remain nameless (at least as long as he refuses to
speak for himself. :) brought up the subject of Linus co-designing bitkeeper
way back when to cope with exactly some of these problems.
Bitkeeper is a technical tool attempting to deal with a social problem.
Merging patches, resolving conflicts between them, testing them, and keeping
them current as the tree changes under them requires programmer work. A
human needs to do it. Whether that human uses bitkeeper, CVS, a directory
full of patch files, or manually keeps all the patches in printouts in a shoe
box is a side issue. A human can feed Linus better patches than any software
tool possibly could.
Now if the patch penguin wants to use bitkeeper for his own internal
patch-wrangling, that's a seperate issue. One you should take up with the
patch penguin, once we have one. (Of course the developer community and the
maintainers might exert some pressure on the patch penguin to use CVS, but
how is this a bad thing from Linus's perspective: it means they'e NOT bugging
HIM about using CVS anymore. And again, this is an enhancement/detail that
can be resolved later.)
As for attracting Linus's attention, there's a penguin and egg problem here:
without an integration lieutenant Linus is largely too swamped to reliably be
aware of this kind of thread on the list, so how can he get the suggestion to
anoint someone with holy penguin pee to basically act as his secretary and
clean up this mess of patches so he can properly sort through them once
they've been organized and laid out in front of him in nice neat rows. Hence
the drive to get people to agree to it so the thread grows large enough to
attract Linus's attention, and also passes his "it's been discussed enough to
find any particularly obvious holes with it" filter...
So everybody who thinks this is a good idea, please say so. Those who don't
like it, please say so too so the objection can be aired and maybe resolved.
The core idea here really is to save Linus time and effort. Everything else
is either a direct consequence of that, or a fringe benefit.
> -- FM
Rob
-
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/
From: torva...@transmeta.com (Linus Torvalds)
Subject: Re: A modest proposal -- We need a patch penguin
Date: Tue, 29 Jan 2002 04:30:13 +0100
Organization: Transmeta Corporation
Message-ID: <a354iv$ai9$1@penguin.transmeta.com>
References: <200201282213.g0SMDcU25653@snark.thyrsus.com>
<200201290137.g0T1bwB24120@karis.localdomain>
Cache-Post-Path: palladium.transmeta.com!unkn...@penguin.transmeta.com
X-Cache: nntpcache 2.4.0b5 (see http://www.nntpcache.org/)
Sender: robo...@news.nic.it
X-Mailing-List: linux-kernel@vger.kernel.org
Approved: robo...@news.nic.it (1.20)
NNTP-Posting-Host: a.483.anti-phl.bofh.it
Newsgroups: linux.kernel
Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!nntp.infostrada.it!
bofh.it!robomod
X-Original-Date: Tue, 29 Jan 2002 03:23:11 +0000 (UTC)
X-Original-Sender: linux-kernel-ow...@vger.kernel.org
X-Original-To: linux-ker...@vger.kernel.org
X-Original-X-Complaints-To: n...@transmeta.com
X-Original-X-Trace: palladium.transmeta.com 1012274617 906 127.0.0.1
(29 Jan 2002 03:23:37 GMT)
Lines: 67
In article <200201290137.g0T1bwB24...@karis.localdomain>,
Francesco Munda <sy...@libero.it> wrote:
>
>I deeply agree with you, especially in keeping "many eyes" to look at the
>same kernel tree, and not chosing one of the many subtrees; as added bonus,
>this stuff is buzzword compliant! What we can ask more? :)
Some thinking, for one thing.
One "patch penguin" scales no better than I do. In fact, I will claim
that most of them scale a whole lot worse.
The fact is, we've had "patch penguins" pretty much forever, and they
are called subsystem maintainers. They maintain their own subsystem, ie
people like David Miller (networking), Kai Germaschewski (ISDN), Greg KH
(USB), Ben Collins (firewire), Al Viro (VFS), Andrew Morton (ext3), Ingo
Molnar (scheduler), Jeff Garzik (network drivers) etc etc.
If there are problems with certain patches, it tends to be due to one or
more of:
- the subsystem is badly modularized (quite common, originally. I don't
think many people realize how _far_ Linux has come in the last five
years wrt issues like architectures, driver independence, filesystem
infrastructure etc). And it still happens.
- lack of maintainer interest. Many "maintainers" are less interested
in true merging than in trying to just push whatever code they have,
and only ever grow their patches instead of keeping them in pieces.
This is usually a matter of getting used to it, and the best people
get used to it really quickly (Andrea, for example, used to not do
this well at all, but look at how he does it now! From a merge
standpoint, his patches have gone from "horrible" to "very good")
- personality/communication issues. Yes, they happen. I've tried to
have other people be "filters" for the people I cannot work with, but
I have to say that most of the time when I can't work with somebody,
others have real problems with those people too.
(An example of a very successful situation: David Miller and Alexey
Kuznetsov: Alexey used to have these rather uncontrolled patches that
I couldn't judge or work with but that obviously had a lot of
potential, and David acting as a filter made them a very successful
team.)
In short, if you have areas or patches that you feel have had problems,
ask yourself _why_ those areas have problems.
A word of warning: good maintainers are hard to find. Getting more of
them helps, but at some point it can actually be more useful to help the
_existing_ ones. I've got about ten-twenty people I really trust, and
quite frankly, the way people work is hardcoded in our DNA. Nobody
"really trusts" hundreds of people. The way to make these things scale
out more is to increase the network of trust not by trying to push it on
me, but by making it more of a _network_, not a star-topology around me.
In short: don't try to come up with a "patch penguin". Instead try to
help existing maintainers, or maybe help grow new ones. THAT is the way
to scalability.
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/
Message-ID: <200201290446.g0T4kZU31923@snark.thyrsus.com>
Content-Type: text/plain; charset=US-ASCII
From: Rob Landley <land...@trommello.org>
Subject: Re: A modest proposal -- We need a patch penguin
Date: Tue, 29 Jan 2002 06:00:08 +0100
X-Mailer: KMail [version 1.3.1]
References: <200201282213.g0SMDcU25653@snark.thyrsus.com>
<200201290137.g0T1bwB24120@karis.localdomain> <a354iv$ai9$1@penguin.transmeta.com>
In-Reply-To: <a354iv$ai9$1@penguin.transmeta.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7BIT
Sender: robo...@news.nic.it
X-Mailing-List: linux-kernel@vger.kernel.org
Approved: robo...@news.nic.it (1.20)
NNTP-Posting-Host: a.85.anti-phl.bofh.it
Newsgroups: linux.kernel
Organization: linux.*_mail_to_news_unidirectional_gateway
Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
newsfeeds.belnet.be!news.belnet.be!newsfeed00.sul.t-online.de!
t-online.de!bofh.it!robomod
X-Original-Date: Mon, 28 Jan 2002 23:47:31 -0500
X-Original-Sender: linux-kernel-ow...@vger.kernel.org
X-Original-To: torva...@transmeta.com (Linus Torvalds),
linux-ker...@vger.kernel.org
Lines: 142
On Monday 28 January 2002 10:23 pm, Linus Torvalds wrote:
> In article <200201290137.g0T1bwB24...@karis.localdomain>,
>
> Francesco Munda <sy...@libero.it> wrote:
> >I deeply agree with you, especially in keeping "many eyes" to look at the
> >same kernel tree, and not chosing one of the many subtrees; as added
> > bonus, this stuff is buzzword compliant! What we can ask more? :)
>
> Some thinking, for one thing.
>
> One "patch penguin" scales no better than I do. In fact, I will claim
> that most of them scale a whole lot worse.
Sure. But Alan doesn't, and Dave Jones (with enough experience) shouldn't.
You have architecture duties. You're worried about the future of the code.
You have to understand just about everybody's subsystem, so you can veto a
patch from somebody like Jens Axboe or Andre Hedrick if you have an objection
to it.
An integration maintainer would NOT be making any major architectural
decisions, they would be integrating the code from the maintainers,
collecting the patches for the unmaintained areas of code, and resolving
issues between maintainers that are purely implementation details.
Then you code review what they do anyway as the architect, saying whether or
not it's a good idea. But you don't have to deal with the obvious grunt work
that's largely a matter of figuring out which bits don't compile because
person A was not talking to person B.
> The fact is, we've had "patch penguins" pretty much forever, and they
> are called subsystem maintainers. They maintain their own subsystem, ie
> people like David Miller (networking), Kai Germaschewski (ISDN), Greg KH
> (USB), Ben Collins (firewire), Al Viro (VFS), Andrew Morton (ext3), Ingo
> Molnar (scheduler), Jeff Garzik (network drivers) etc etc.
I'm suggesting an integration maintainer, whose explicit job is to put
together patches from the various subsystem maintainers, and only directly
accept patches for areas of code that do not HAVE any other subsystem
maintainer.
Alan Cox used to do this (and is starting to do it again for Marcelo in 2.4).
Dave Jones is currently the guy doing this for you, taking patches, sorting
through them, and then feeding them on to you.
> If there are problems with certain patches, it tends to be due to one or
> more of:
>
> - the subsystem is badly modularized (quite common, originally. I don't
> think many people realize how _far_ Linux has come in the last five
> years wrt issues like architectures, driver independence, filesystem
> infrastructure etc). And it still happens.
Yup. Architecture issue. Still your problem, I'm fraid.
> - lack of maintainer interest. Many "maintainers" are less interested
> in true merging than in trying to just push whatever code they have,
> and only ever grow their patches instead of keeping them in pieces.
Patch penguin's job. Foist this grunt work off on him.
> This is usually a matter of getting used to it, and the best people
> get used to it really quickly (Andrea, for example, used to not do
> this well at all, but look at how he does it now! From a merge
> standpoint, his patches have gone from "horrible" to "very good")
And needed patches from people who aren't very good have to wait years for
the developer to learn how to feed you the right kind of patches?
If the patch is for a specific subsystem, then obviously your first line of
defense fighting off sturgeon's law is the subsystem maintainer. But you
don't seem to have been taking patches even from subsystem maintainers in a
timely manner, and how can people tell the difference between you dropping a
patch because you have an objection to it and you dropping a patch because
your mailbox overfloweth? (You keep complaining people never send you
patches. People are suggesting automated patch remailers to spam your
mailbox even harder. There has GOT to be a better way...)
> - personality/communication issues. Yes, they happen. I've tried to
> have other people be "filters" for the people I cannot work with, but
> I have to say that most of the time when I can't work with somebody,
> others have real problems with those people too.
>
> (An example of a very successful situation: David Miller and Alexey
> Kuznetsov: Alexey used to have these rather uncontrolled patches that
> I couldn't judge or work with but that obviously had a lot of
> potential, and David acting as a filter made them a very successful
> team.)
>
> In short, if you have areas or patches that you feel have had problems,
> ask yourself _why_ those areas have problems.
Query: Do you not believe you have been dropping a significant number of good
patches on the floor?
> A word of warning: good maintainers are hard to find. Getting more of
> them helps, but at some point it can actually be more useful to help the
> _existing_ ones. I've got about ten-twenty people I really trust, and
> quite frankly, the way people work is hardcoded in our DNA. Nobody
> "really trusts" hundreds of people. The way to make these things scale
> out more is to increase the network of trust not by trying to push it on
> me, but by making it more of a _network_, not a star-topology around me.
You don't see an integration maintainer as a step in the right direction?
(It's not a star topology, it's a tree.)
Having lots of dispirate overlapping trees fragments development, fragments
the testers, and makes an awful lot more WORK for everybody involved.
> In short: don't try to come up with a "patch penguin". Instead try to
> help existing maintainers, or maybe help grow new ones. THAT is the way
> to scalability.
Are you saying that Alan Cox's didn't serve a purpose during the 2.2 kernel
time frame, and that Dave Jones is currently wasting his time?
I'm confused here: "don't try to come up with a patch penguin", "help
existing maintainers" (that's the patch penguin's job) "help grow new
[maintainers]"... The patch penguin IS an integration maintainer. That's
what I'm talking about. (Patch penguin, patch pumpkin. Patch pumkin, patch
penguin. I can say "integration maintainer" if it would help...)
I missed a curve somewhere. Maybe the original message wasn't clear? I am
suggesting making Dave Jones the integration maintainer (a position he
currently unofficially holds, and which Alan Cox did before him), and simply
telling everybody who's complaining that their patches are getting silently
dropped or ignored to try getting them into HIS tree first before bothering
you about it.
I'm not asking for a major change here, I'm talking about clarifying the
current ad-hoc development process. Formalizing an existing de facto
position so people farther out in the development process know what to do and
where to go.
> Linus
Rob
-
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: Mon, 28 Jan 2002 22:00:19 -0800 (PST)
From: Linus Torvalds <torva...@transmeta.com>
X-To: Rob Landley <land...@trommello.org>
X-cc: <linux-ker...@vger.kernel.org>
Subject: Re: A modest proposal -- We need a patch penguin
Message-ID:
<linux.kernel.Pine.LNX.4.33.0201282153160.10900-100000@penguin.transmeta.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Approved: n...@nntp-server.caltech.edu
Lines: 51
On Mon, 28 Jan 2002, Rob Landley wrote:
>
> > A word of warning: good maintainers are hard to find. Getting more of
> > them helps, but at some point it can actually be more useful to help the
> > _existing_ ones. I've got about ten-twenty people I really trust, and
> > quite frankly, the way people work is hardcoded in our DNA. Nobody
> > "really trusts" hundreds of people. The way to make these things scale
> > out more is to increase the network of trust not by trying to push it on
> > me, but by making it more of a _network_, not a star-topology around me.
>
> You don't see an integration maintainer as a step in the right direction?
> (It's not a star topology, it's a tree.)
No, I don't really think an "integration manager" works well.
I think it helps a lot to have people pick up patches that nobody else
wants to maintain, and to gather them up. Andrea does that to some degree.
But it is _much_ better if you have somebody who is a point-man for
specific areas.
The problem with an overall guy is that there can't be too many of them.
The very thing you are _complaining_ about is in fact that there are a
number of over-all guys without clear focus, which only leads to confusion
about who handles what.
Clarity is good.
> Are you saying that Alan Cox's didn't serve a purpose during the 2.2 kernel
> time frame, and that Dave Jones is currently wasting his time?
No, I'm saying that there are not very many peopel who can do it, and who
can get the kind of trust that they are _everywhere_. Let's face it, Alan
grew to be respected because he did lots of different stuff over many
years, and he proved himself more than capable. And I suspect he's _quite_
happy not being in the middle of it right now.. It's a tough job.
It's a lot more likely to find people who can maintain _parts_. And if
there are patches that fall out of those parts, that tends to indicate a
lack of modularity, and perhaps a lack of maintainer for those parts.
And more likely, even if you _do_ find ten people who can do everything,
you don't want them to.
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: Mon, 28 Jan 2002 22:12:49 -0800
From: Larry McVoy <l...@bitmover.com>
X-To: Linus Torvalds <torva...@transmeta.com>
X-Cc: Rob Landley <land...@trommello.org>, linux-ker...@vger.kernel.org
Subject: Re: A modest proposal -- We need a patch penguin
Message-ID: <linux.kernel.20020128221249.A5583@work.bitmover.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Approved: n...@nntp-server.caltech.edu
Lines: 33
On Mon, Jan 28, 2002 at 10:00:19PM -0800, Linus Torvalds wrote:
> And more likely, even if you _do_ find ten people who can do everything,
> you don't want them to.
[and other things, in general saying that he wasn't happy with the approach]
What you didn't do, Linus, is paint a picture which allows development
to scale up. Perhaps you don't want it to do so; looking back on Sun's
development process has taught me that a lot of it was just a way to
slow things down enough that the architects could keep up with the many
hacks going on here there and everywhere. If this was Sun, I'd say that
slowing things down is good.
But cast your mind back to your "Linux is evolution" line of reasoning
and ask yourself if that does not mean that allowing the fastest
forward progress is what you want. It would seem so, but at this point,
Linus, it is hard to predict what you think, so I'll pass on guessing.
What would be nice is if you came out with a clear statement, similar
to Rob's written summary, that said what it is that you would like to
see happen to address the issues that have come up over and over again.
The alternative is that sooner or later someone or some group will come
up with a better answer, there will be an ugly fight, and a lot of time
will get wasted when we could have learned how to grow up nicely.
--
---
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!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: Mon, 28 Jan 2002 22:49:04 -0800 (PST)
From: Linus Torvalds <torva...@transmeta.com>
X-To: Larry McVoy <l...@bitmover.com>
X-cc: Rob Landley <land...@trommello.org>, <linux-ker...@vger.kernel.org>
Subject: Re: A modest proposal -- We need a patch penguin
Message-ID:
<linux.kernel.Pine.LNX.4.33.0201282217220.10929-100000@penguin.transmeta.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Approved: n...@nntp-server.caltech.edu
Lines: 117
On Mon, 28 Jan 2002, Larry McVoy wrote:
>
> What you didn't do, Linus, is paint a picture which allows development
> to scale up.
Actually, I thought I did.
Basic premise: development is done by humans.
Now, look at how humans work. I don't know _anybody_ who works with
hundreds of people. You work with 5-10 people, out of a pool of maybe
30-50 people. Agreed?
Now, look at the suggested "patch penguin", and realize that the
suggestion doesn't add any scaling at all: it only adds a simple layer
that has all the same scaling problems.
What I'm saying is
- I'm never going to work with hundreds of people directly, because it is
fundamentally against my nature, by virtue of being human.
- adding a "patch penguin" doesn't help, because _he_ (or she, although I
didn't see any women nominated) is also going to be human. So either
the patch penguin is going to do a bad job (and I won't start trusting
him/her), or the patch penguin is going to have all the same issues
people complain about.
Those are obvious truths. If you don't see them as being obvious truths,
you just haven't been thinking things through.
Did Alan do a good job? Yes. He did a _great_ job. But let's face it: (a)
he got really tired of doing it and (b) it really works only with one or
two Alan's, not with more - because with more you get people complaining
about the -aa tree vs the -dj tree vs the -marcelo tree vs the -linus
tree.
So Alan doesn't scale up either - I doubt you'll find a "better Alan", and
I _seriously_ doubt you'll be able to have multiple Alan's.
Does anybody really doubt this?
Now, if you've read this far, and you agree with these issues, I suspect
you know the solution as well as I do. It's the setup I already mentioned:
a network of maintainers, each of whom knows other maintainers.
And there's overlap. I'm not talking about a hierarchy here: it's not the
"general at the top" kind of tree-like setup. The network driver people
are in the same general vicinity as the people doing network protocols,
and there is obviously a lot of overlap.
Are there problems with maintainership? Yes. The main one being that it's
too damn easy to step on any toes. Which is why you want the modularity,
ie you do NOT want to have files issues that slash across different
maintenance boundaries (unless they have clearly defined interfaces:
that's where the importance of a clear VFS interface design comes in etc)
For an example of this, look at init/main.c in 2.2.x, in 2.4.x, and in
2.5.x. BIG changes. And most of the changes have very little to do with
what that file actually does (relatively little), and _everything_ to do
with the fact that it is the file that "instantiates" almost everything
and thus crosses all boundaries.
And notice how the "initcall" etc setup has changed, and cut a lot of
those dependencies. That's very much by design: look at what a device
driver had to do (and know) to be either a compiled-in driver or a modular
driver a few years ago. And look at a driver today.
In short, I'm saying that the true path to scalability is:
- lack of dependencies on a source level
This implies good interfaces that do NOT have common source files for
different projects. In particular, it implies dynamic add/remove
without the rest of the system having to know at all.
- lack of people (whether patch-penguins or me) who have to follow
everything.
This, in turn, implies two things:
(a) it is not the maintainers who pull things into their trees (because
they aren't always there, and they don't know everything). It is
the developers who _push_ onto maintainers.
(b) if you as a developer cannot find a maintainer who you know, it is
YOUR problem, and you cannot blame some super-penguin in the blue
yonder for not caring about you. You may have to maintain your
patch-set yourself. Or you should find a maintainer who cares about
the work you do, and who helps feed it forward.
I know, I know. It's easier to whine about other people than it is to take
responsibility for your own actions. It's so easy to complain about "Linus
doesn't apply my patches", and so hard to just face the fact that Linus
never _will_ care about all patches, and that if you cannot find anybody
else to care about them either, then maybe they should die or you should
take care and feed them yourself.
I'm a bastard. I'm spending a lot of time applying patches, but it's not
my whole life. Never has been, never will be. I'll always be better at
applying patches from those ten people that I know and I trust than I'll
be at applying patches from people I don't trust.
If you're a developer, and you can't get through to me, ask yourself if
you can get through to somebody else.
And if you can't get through to anybody else either, ask yourself whether
maybe the problem is at _your_ end.
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/
Date: Tue, 29 Jan 2002 13:10:14 +0100
From: Ingo Molnar <mi...@elte.hu>
Reply-To: <mi...@elte.hu>
Subject: Re: A modest proposal -- We need a patch penguin
In-Reply-To: <200201290446.g0T4kZU31923@snark.thyrsus.com>
Message-ID: <Pine.LNX.4.33.0201291324560.3610-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: robo...@news.nic.it
X-Mailing-List: linux-kernel@vger.kernel.org
Approved: robo...@news.nic.it (1.20)
NNTP-Posting-Host: a.582.anti-phl.bofh.it
Newsgroups: linux.kernel
Organization: linux.*_mail_to_news_unidirectional_gateway
Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
newsfeeds.belnet.be!news.belnet.be!newsfeed00.sul.t-online.de!t-online.de!
bofh.it!robomod
References: <200201290446.g0T4kZU31923@snark.thyrsus.com>
X-Original-Cc: Linus Torvalds <torva...@transmeta.com>,
<linux-ker...@vger.kernel.org>
X-Original-Date: Tue, 29 Jan 2002 14:54:27 +0100 (CET)
X-Original-Sender: linux-kernel-ow...@vger.kernel.org
X-Original-To: Rob Landley <land...@trommello.org>
Lines: 164
On Mon, 28 Jan 2002, Rob Landley wrote:
> (You keep complaining people never send you patches. People are
> suggesting automated patch remailers to spam your mailbox even harder.
> There has GOT to be a better way...)
None of the examples you cited so far are convincing to me, and i'd like
to explain why. I've created and submitted thousands of patches to the
Linux kernel over the past 4 years (my patch archive doesnt go back more
than 4 years):
# ls patches | wc -l
2818
a fair percentage of those went to Linus as well, and while having seen
some of them rejected does hurt mentally, i couldnt list one reject from
Linus that i wouldnt reject *today*. But i sure remember being frustrated
about rejects when they happened. In any case, i have some experience in
submitting patches and i'm maintaining a few subsystems, so here's my take
on the 'patch penguin' issue:
If a patch gets ignored 33 times in a row then perhaps the person doing
the patch should first think really hard about the following 4 issues:
- cleanliness
- concept
- timing
- testing
a violation of any of these items can cause patch to be dropped *without
notice*. Face it, it's not Linus' task to teach people how to code or how
to write correct patches. Sure, he still does teach people most of the
time, but you cannot *expect* him to be able to do it 100% of the time.
1) cleanliness
code cleanliness is a well-know issue, see Documentation/CodingStyle. If
a patch has such problems then maintainers are very likely to help - Linus
probably wont and shouldnt. I'm truly shocked sometimes, how many active
and experienced kernel developers do not follow these guidelines. While
the Linux coding style might be arbitrary in places, all coding styles are
arbitrary in some areas, and only one thing is important above all:
consistency between kernel subsystems. If i go from one kernel subsystem
to another then i'd like to have the same 'look and feel' of source code -
i think this is a natural desire we all share. If anyone doesnt see the
importance of this issue then i'd say he hasnt seen, hacked and maintained
enough kernel code yet. I'd say the absolute positive example here is Al
Viro. I think most people just do not realize the huge amount of
background cleanup work Al did in the past 2 years. And guess what? I bet
Linus would be willing to apply Al's next patch blindfolded.
impact: a patch penguin might help here - but he probably wont scale as
well as the current set of experienced kernel hackers scale, many of whom
are happy to review patches for code cleanliness (and other) issues.
2) concept
many of the patches which were rejected for a long time are *difficult*
issues. And one thing many patch submitters miss: even if the concept of
the patch is correct, you first have to start by cleaning up *old* code,
see issue 1). Your patch is not worth a dime if you leave in old cruft, or
if the combination of old cruft and your new code is confusing. Also, make
sure the patch is discussed and developed openly, not on some obscure
list. linux-ker...@vger.kernel.org will do most of the time. I do not want
to name specific patches that violate this point (doing that in public
just offends people needlessly - and i could just as well list some of my
older patches), but i could list 5 popular patches immediately.
impact: a patch penguin just wont solve this concept issue, because, by
definition, he doesnt deal with design issues. And most of the big patch
rejections happen due to exactly these concept issues.
3) timing
kernel source code just cannot go through arbitrary transitions. Eg. right
now the scheduler is being cleaned up (so far it was more than 50
sub-patches and they are still coming) - and work is going on to maximize
the quality of the preemption patch, but until the base scheduler has
stabilized there is just no point in applying the preemption patch - no
matter how good the preemption patch is. Robert understands this very
much. Many other people do not.
impact: a patch penguin just wont solve this issue, because a patch
penguin cannot let his tree transition arbitrarily either. Only separately
maintained and tested patches/trees can handle this issue.
4) testing
there are code areas and methods which need more rigorous testing and
third-party feedback - no matter how good the patch. Most notably, if a
patch exports some new user-space visible interface, then this item
applies. An example is the aio patch, which had all 3 items right but was
rejected due to this item. [things are improving very well on the aio
front so i think this will change in the near future.]
impact: a patch penguin just wont solve this issue, because his job, by
definition, is not to keep patches around indefinitely, but to filter them
to Linus. Only separately maintained patches/trees help here. More people
are willing to maintain separate trees is good (-dj, -ac, -aa, etc.), one
tree can do a nontrivial transition at a time, and by having more of them
we can eg. get one of them testing aio, the other one testing some other
big change. A single patch penguin will be able to do only one nontrivial
transition - and it's not his task to do nontrivial transitions to begin
with.
Many people who dont actually maintain any Linux code are quoting Rik's
complains as an example. I'll now have to go on record disagreeing with
Rik humbly, i believe he has done a number of patch-management mistakes
during his earlier VM development, and i strongly believe the reason why
Linus ignored some of his patches were due to these issues. Rik's flames
against Linus are understandable but are just that: flames. Fortunately
Rik has learned meanwhile (we all do) and his rmap patches are IMHO
top-notch. Joining the Andrea improvements and Rik's tree could provide a
truly fantastic VM. [i'm not going to say anything about the IDE patches
situation because while i believe Rik understands public criticism, i
failed to have an impact on Andre before :-) ]
also, many people just start off with a single big patch. That just doesnt
work and you'll likely violate one of the 4 items without even noticing
it. Start small, because for small patches people will have the few
minutes needed to teach you. The bigger a patch, the harder it is to
review it, and the less likely it happens. Also, if a few or your patches
have gone into the Linux tree that does not mean you are senior kernel
hacker and can start off writing the one big, multi-megabyte super-feature
you dreamt about for years. Start small and increase the complexity of
your patches slowly - and perhaps later on you'll notice that that
super-feature isnt all that super anymore. People also underestimate the
kind of complexity explosion that occurs if a large patch is created.
Instead of 1-2 places, you can create 100-200 problems.
face it, most of the patches rejected by Linus are not due to overload. He
doesnt guarantee to say why he rejects patches - *and he must not*. Just
knowing that your patch got rejected and thinking it all over again often
helps finding problems that Linus missed first time around. If you submit
to Linus then you better know exactly what you do.
if you are uncertain about why a patch got rejected, then shake off your
frustration and ask *others*. Many kernel developers, including myself,
are happy to help reviewing patches. But people do have egos, and it
happens very rarely that people ask it on public lists why their patches
got rejected, because people do not like talking about failures. And the
human nature makes it much easier to attack than to talk about failures.
Which fact alone pretty much shows that most of the time the problem is
with the patch submitter, not with Linus.
it's so much easier to blame Linus, or maintainers. It's so much easier to
fire off an email flaming Linus and getting off the steam than to actually
accept the possibility of mistake and *fix* the patch. I'll go on record
saying that good patches are not ignored, even these days when the number
of active kernel hackers has multipled. People might have to go through
several layers first, and finding some kernel hacker who is not as loaded
as Linus to review your patch might be necessery as well (especially if
the patch is complex), but if you go through the right layers then you can
be sure that nothing worthwile gets rejected arbitrarily.
Ingo
-
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/
Date: Tue, 29 Jan 2002 13:40:10 +0100
From: Dave Jones <da...@suse.de>
Subject: Re: A modest proposal -- We need a patch penguin
Message-ID: <20020129132228.A9149@suse.de>
Mail-Followup-To: Dave Jones <da...@suse.de>,
Rob Landley <land...@trommello.org>,
Francesco Munda <sy...@libero.it>, linux-ker...@vger.kernel.org
References: <200201282213.g0SMDcU25653@snark.thyrsus.com>
<200201290137.g0T1bwB24120@karis.localdomain>
<200201290341.g0T3fNU30909@snark.thyrsus.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <200201290341.g0T3fNU30909@snark.thyrsus.com>;
from landley@trommello.org on Mon, Jan 28, 2002 at 10:42:19PM -0500
Sender: robo...@news.nic.it
X-Mailing-List: linux-kernel@vger.kernel.org
Approved: robo...@news.nic.it (1.20)
NNTP-Posting-Host: a.821.anti-phl.bofh.it
Newsgroups: linux.kernel
Organization: linux.*_mail_to_news_unidirectional_gateway
Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!nntp.infostrada.it!bofh.it!
robomod
X-Original-Cc: Francesco Munda <sy...@libero.it>, linux-ker...@vger.kernel.org
X-Original-Date: Tue, 29 Jan 2002 13:22:28 +0100
X-Original-Sender: linux-kernel-ow...@vger.kernel.org
X-Original-To: Rob Landley <land...@trommello.org>
Lines: 87
On Mon, Jan 28, 2002 at 10:42:19PM -0500, Rob Landley wrote:
> probably diminish as new development shifts over to 2.5. Right now, the
> patch constipation we've been seeing is, in my opinion, directing development
> to occur against 2.4 that should at the very least be eyeing 2.5. (Alan is
> probably NOT interested in integrating patches that Marcelo has no intention
> of eventually integrating into 2.5. So he's not taking the new development
> integration pressure off, that's DJ's job.)
>
> I think DJ could definitely use a clearer mandate.
* Initially, -dj was "pick up fixes from 2.4".
* Then when Linus broke various other parts of 2.5, I took fixes
for various bits. (Some of those went back his way, others didn't,
others are still in the process)
(I'm a believer in the 'eat your own dogfood' thing, and run my
tree on several testboxes -- being able to compile/boot/test
this tree became more important at the cost of the tree growing
a little further away from -linus)
* Some developers also wanting to develop against 2.5 found the
quickest way to get a compilable, workable 2.5 tree was to
grab my snapshot, and work against my tree until Linus gets his
together. And hence, the input layer & fb layer changes.
This was one I had to think about a bit before deciding if
I was going to start accepting such patches.
In theory, as we're now in 2.5, there should be no need for this,
but whilst Linus is busy focusing on the block layer, scheduler
or other flavour of the week, James, Vojtech etc can at least
get some extra testers before their code hits -linus.
By the time that the new input/fb stuff is ready for Linus' tree
hopefully a lot of the more obvious problems will be shaken out,
and Linus can have a set of patches for a "new xxx layer" that
works for at least everyone who's been testing it in -dj.
Where to go from here? More of the same. It's a fulltime job
keeping up with Marcelo & Linus, and reviewing, merging, and
chasing down the right people. One thing I'm not entirely
enthusiastic about doing, is making policy decisions.
I've had questions from people asking me if I'll merge xxx's
implementation of ACLs for example. Without knowing which way
Linus is going to turn on such an issue, I'm naturally hesitant.
Another thing of note is that the merge process with Linus
isn't as straightforward as running splitdiff, and pushing the
chunks to Linus. Some bits require a timing (although this is
sometimes hard to get right) so I can push him filesystem
changes when Al isn't turning the VFS upside down for eg.
Other bits I won't push because maintainers have mailed me
asking me not to. And other bits, because the maintainers
can do a better job of splitting,pushing and describing than
I can (typical example: the fbdev/input stuff)
> Dave didn't seem to have any major objections but raised a lot technical
> points to the effect of "I'm already doing this bit". Both of them gave me
> permission to post most of our conversation to the list, but seem unwilling
> to do it themselves. :)
Time, Headcold, time, blah, excuses 8)
But to reiterate, yes. Most of what you described is exactly whats
taking place, although a lot of it happens behind the scenes, not
on Linux-kernel, not on irc, but me being a pita chasing maintainers
"Hey xxx sent me a patch, aren't you working on this? You two should
talk..". It's like being a switchboard operator at times, plugging
in the right cables, connecting the right people.
> As for attracting Linus's attention, there's a penguin and egg problem here:
> without an integration lieutenant Linus is largely too swamped to reliably be
> aware of this kind of thread on the list
Linus' concern that people don't scale is perhaps not unfounded.
Since I started doing this, the number of hours involved has increased
on a day by day basis. If there comes a time where >I'm< not scaling
and start dropping patches, then maybe an extra tier is needed. *shrug*
For now at least, things seem to be working out quite well on the whole.
I'm not aware of any particularly important fix/cleanup that has been
dropped on the floor since I started scooping them up.
--
| 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: Tue, 29 Jan 2002 09:30:59 -0500
From: Skip Ford <skip.f...@verizon.net>
X-To: Linus Torvalds <torva...@transmeta.com>
X-Cc: linux-ker...@vger.kernel.org
Subject: Re: A modest proposal -- We need a patch penguin
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID:
<linux.kernel.20020129143359.BBSA15035.out018.verizon.net@pool-141-150-235-204.
delv.east.verizon.net>
Approved: n...@nntp-server.caltech.edu
Lines: 40
Linus Torvalds wrote:
[snip]
> A word of warning: good maintainers are hard to find. Getting more of
> them helps, but at some point it can actually be more useful to help the
> _existing_ ones. I've got about ten-twenty people I really trust, and
Then why not give the subsystem maintainers patch permissions on your tree.
Sort of like committers. The problem people have is that you're dropping
patches from those ten-twenty people you trust.
Each subsystem maintainer should handle patches to that subsystem, and
you should remove your own patch permissions for only those subsystems.
You could get involved with only changes in direction that affect more
than one subsystem.
> quite frankly, the way people work is hardcoded in our DNA. Nobody
> "really trusts" hundreds of people. The way to make these things scale
> out more is to increase the network of trust not by trying to push it on
> me, but by making it more of a _network_, not a star-topology around me.
>
> In short: don't try to come up with a "patch penguin". Instead try to
> help existing maintainers, or maybe help grow new ones. THAT is the way
> to scalability.
-
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: Tue, 29 Jan 2002 09:36:28 -0800 (PST)
From: Linus Torvalds <torva...@transmeta.com>
X-To: Skip Ford <skip.f...@verizon.net>
X-cc: <linux-ker...@vger.kernel.org>, Andrea Arcangeli <and...@suse.de>
Subject: Re: A modest proposal -- We need a patch penguin
Message-ID:
<linux.kernel.Pine.LNX.4.33.0201290914270.7701-100000@athlon.transmeta.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Approved: n...@nntp-server.caltech.edu
Lines: 56
On Tue, 29 Jan 2002, Skip Ford wrote:
>
> Linus Torvalds wrote:
> [snip]
> > A word of warning: good maintainers are hard to find. Getting more of
> > them helps, but at some point it can actually be more useful to help the
> > _existing_ ones. I've got about ten-twenty people I really trust, and
>
> Then why not give the subsystem maintainers patch permissions on your tree.
> Sort of like committers. The problem people have is that you're dropping
> patches from those ten-twenty people you trust.
No. Ask them, and they will (I bet) pretty uniformly tell you that I'm
_not_ dropping their patches (although I'm sometimes critical of them,
and will tell them that they do not get applied).
Sure, it happens occasionally that they really do get dropped, just
because I get too much email, but these people know how to re-send every
once in a while, and keep their patches separate.
I think there is some confusion about who I trust. Being listed as
MAINTAINER doesn't mean you are automatically trusted. The MAINTAINERS
list is not meant for me _at_all_ in fact, it's meant more as one of the
places for _others_ to search for a contact with.
Examples of people who I trust: Ingo Molnar, Jeff Garzik, Alan Cox, Al
Viro, David Miller, Greg KH, Andrew Morton etc. They've shown what I call
"good taste" for a long time. But it's not always a long process - some
of you may remember Bill Hawes, for example, who came out of nowhere
rather quickly.
There are other categories: Andrea, for example, is in a category all of
his own under "absolutely stunning, but sometimes somewhat erratic", which
just means that I have to think a lot more about his patches. I love his
experimentation, especially now that he maintains separate patches (and
I'd also love for him to be more active in pushing the non-experimental
parts towards me, hint hint, Andrea)
And there are categories of people who just own a big enough chunk that is
separate enough that I trust them for that area: architecture maintainers
etc tend to be here, as long as they only affect their own architecture.
But you have to realize that there are a _lot_ of people on the
maintainers list that I don't implicitly trust. And being loud and
wellknown on the mailing lists or IRC channels doesn't make them any more
trusted.
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!newsfeed1.cidera.com!Cidera!news2.dg.net.ua!
bn.utel.com.ua!carrier.kiev.ua!not-for-mail
From: Rob Landley <land...@trommello.org>
Newsgroups: lucky.linux.kernel
Subject: Re: A modest proposal -- We need a patch penguin
Date: Tue, 29 Jan 2002 18:53:26 +0000 (UTC)
Organization: unknown
Lines: 263
Sender: n...@horse.lucky.net
Approved: newsmas...@lucky.net
Message-ID: <200201291845.g0TIjSU16741@snark.thyrsus.com.lucky.linux.kernel>
References: <Pine.LNX.4.33.0201291324560.3610-100000@localhost.localdomain>
NNTP-Posting-Host: horse.lucky.net
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
X-Trace: horse.lucky.net 1012330406 74151 193.193.193.118 (29 Jan 2002 18:53:26 GMT)
X-Complaints-To: usenet@horse.lucky.net
NNTP-Posting-Date: Tue, 29 Jan 2002 18:53:26 +0000 (UTC)
X-Mailer: KMail [version 1.3.1]
In-Reply-To: <Pine.LNX.4.33.0201291324560.3610-100000@localhost.localdomain>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Comment-To: mi...@elte.hu
On Tuesday 29 January 2002 08:54 am, Ingo Molnar wrote:
> On Mon, 28 Jan 2002, Rob Landley wrote:
> - cleanliness
> - concept
> - timing
> - testing
>
> a violation of any of these items can cause patch to be dropped *without
> notice*. Face it, it's not Linus' task to teach people how to code or how
> to write correct patches. Sure, he still does teach people most of the
> time, but you cannot *expect* him to be able to do it 100% of the time.
I'm trying to identify stuff that isn't necessarily Linus's job, and doesn't
seem to be being done, and seeing if somebody ELSE can do it. My proposal
was my take on improving things. If now is not the time for it, maybe
smaller steps can be taken first.
Possibly Linus needs a "bounce this message to kernelnewbies.org's 'please
teach this guy how to program' list?" key, as an alternative to the delete
key? For patches that try to do something useful and simply don't manage to?
This is one of the things I thought a patch penguin (and troupe of volunteer
patch secretaries operating under a patch penguin) might be able to do.
Right now, there's no troupe of patch secretaries because the patch
submission queue is linus's mailbox. (The real irreplaceable job of the
patch penguin is queueing stuff for linus split out of the tree, so the patch
penguin doesn't have to scale that much better than Linus does. Other people
working with the patch penguin could theoretically help
massage/test/integrate/update patches. And of course linus could still take
patches directly from maintainers if he had the bandwidth to do so. He can
obviously even write his own code when he has time...)
Linux-kernel used to serve all these functions (it was the patch queue and
the patch cleanup and sorting discussion list, and some people on it were a
bit like patch secretaries), but the volume has gotten too high for it to
function as such anymore. Posting a patch here less than a dozen times
doesn't really count as submitting it to Linus anymore.
One demarcation that COULD be made is 2.4 vs 2.5. There could probably be
seperate "stable" vs "development" lists. Probably been suggested before and
shot down, but does work aimed at Marcelo and work aimed at Linus really need
to be on the same list?
> 2) concept
>
> many of the patches which were rejected for a long time are *difficult*
> issues. And one thing many patch submitters miss: even if the concept of
> the patch is correct, you first have to start by cleaning up *old* code,
> see issue 1). Your patch is not worth a dime if you leave in old cruft, or
> if the combination of old cruft and your new code is confusing. Also, make
> sure the patch is discussed and developed openly, not on some obscure
> list. linux-ker...@vger.kernel.org will do most of the time. I do not want
> to name specific patches that violate this point (doing that in public
> just offends people needlessly - and i could just as well list some of my
> older patches), but i could list 5 popular patches immediately.
>
> impact: a patch penguin just wont solve this concept issue, because, by
> definition, he doesnt deal with design issues. And most of the big patch
> rejections happen due to exactly these concept issues.
Definitely Linus's job. But of those top 5 patches, how many of the patch
pushers have had their ideas actually critiqued so they know why they're not
going in? (If it's just a question of "this work needs to be done
first/also", that's a manageable problem.)
> 3) timing
>
> kernel source code just cannot go through arbitrary transitions. Eg. right
> now the scheduler is being cleaned up (so far it was more than 50
> sub-patches and they are still coming) - and work is going on to maximize
> the quality of the preemption patch, but until the base scheduler has
> stabilized there is just no point in applying the preemption patch - no
> matter how good the preemption patch is. Robert understands this very
> much. Many other people do not.
>
> impact: a patch penguin just wont solve this issue, because a patch
> penguin cannot let his tree transition arbitrarily either. Only separately
> maintained and tested patches/trees can handle this issue.
A patch penguin's tree could apply more "speculative" patches than Linus,
because the nature of the tree is that some of the patches in it get backed
out, or at the very least don't go on to Linus yet.
It's also a nice buffer of patches for Linus. Even a relatively small buffer
is a good thing to prevent data loss (16550a anyone? Better than nothing...)
As long as the patches in the queue are maintained and kept up to date
(which is work that is not being coordinated right now: person A's change
breaks person B's patch, how does person A know if he doesn't apply person
B's patch to his tree?).
And there's also the possibility that "judgement call" patches the patch
penguin didn't want to include could be listed as "known to apply cleanly
against this tree, but not included". Just a page listing URLs to patches
that are being tracked. This has not previously been done by Alan, Dave, or
Andrea, and maybe there's a reason why...
> 4) testing
>
> there are code areas and methods which need more rigorous testing and
> third-party feedback - no matter how good the patch. Most notably, if a
> patch exports some new user-space visible interface, then this item
> applies. An example is the aio patch, which had all 3 items right but was
> rejected due to this item. [things are improving very well on the aio
> front so i think this will change in the near future.]
>
> impact: a patch penguin just wont solve this issue, because his job, by
> definition, is not to keep patches around indefinitely, but to filter them
> to Linus.
Yes and no. Alan did more than that. His tree contained stuff (like User
Mode Linux) that he didn't immediately mean to forward to Linus. Stuff HAS
historically gone into patch penguin trees because the patch penguin likes
the idea but believes it needs wider testing.
This stuff is usually a compile option. XFS and JFS come to mind here,
although that just points out we need a unified journaling layer, which is an
ongoing discussion. (Will a unified journaling layer come about until a tree
exists that contains XFS, JFS, EXT3, and ReiserFS, and then people start
scrutinizing the mess and combining common code? I dunno...)
> Only separately maintained patches/trees help here. More people
> are willing to maintain separate trees is good (-dj, -ac, -aa, etc.), one
> tree can do a nontrivial transition at a time,
That's a seperately maintained patch that has not been integrated into a
tree. All patches apply to a Linux tree in order to get compiled into a
system, and all patches could be downloaded as a tree (as the XFS guys do).
When I say tree I'm talking about a tree that's integrating patches from more
than one source. This is a step that comes after the patch has gone about as
far as it's likely to as a seperate patch, seems to work pretty well, and
needs testing by a wider audience in order to squeeze out more bugs or get
more code review and comments on its design.
> and by having more of them
> we can eg. get one of them testing aio, the other one testing some other
> big change.
Sure. This happens now. The question is, what happens after the JFS people
say "okay, we've reached version 1.0 now, please try this" and the patch
still doesn't get integrated into a "beat me, whip me, make me break" tree
for wider testing for months and months and months?
> A single patch penguin will be able to do only one nontrivial
> transition - and it's not his task to do nontrivial transitions to begin
> with.
I don't know what you mean here.
> Many people who dont actually maintain any Linux code are quoting Rik's
> complains as an example. I'll now have to go on record disagreeing with
> Rik humbly, i believe he has done a number of patch-management mistakes
> during his earlier VM development, and i strongly believe the reason why
> Linus ignored some of his patches were due to these issues. Rik's flames
> against Linus are understandable but are just that: flames. Fortunately
> Rik has learned meanwhile (we all do) and his rmap patches are IMHO
> top-notch. Joining the Andrea improvements and Rik's tree could provide a
> truly fantastic VM. [i'm not going to say anything about the IDE patches
> situation because while i believe Rik understands public criticism, i
> failed to have an impact on Andre before :-) ]
I understand that a lot of the problems aren't purely on Linus's end. You
didn't add Richard Gooch to that list with Rik and Andre (although Al seems
to have decided it's one of his missions in life to keep Richard adhering to
the coding style.... :)
But right now the individual maintainers need to be really good at patch
management or the system breaks down. This isn't exactly a scalability
question, this is a reliability question. There's no failure recovery
mechanism here: if one part of the distributed system breaks the results are
visible at the end. You can't scale to more components if all of them most
work perfectly every time and expect to have a more reliable system.
> also, many people just start off with a single big patch. That just doesnt
> work and you'll likely violate one of the 4 items without even noticing
> it. Start small, because for small patches people will have the few
> minutes needed to teach you.
The kernel is currently FULL of warnings when it used to have none, and
outright compile errors that go unfixed for several versions if they occur in
less-often used subsystems.
Small patches seem more likely to get dropped than big ones. This could be
an artifact of perception, I dunno...
> The bigger a patch, the harder it is to
> review it, and the less likely it happens. Also, if a few or your patches
> have gone into the Linux tree that does not mean you are senior kernel
> hacker and can start off writing the one big, multi-megabyte super-feature
> you dreamt about for years. Start small and increase the complexity of
> your patches slowly - and perhaps later on you'll notice that that
> super-feature isnt all that super anymore. People also underestimate the
> kind of complexity explosion that occurs if a large patch is created.
> Instead of 1-2 places, you can create 100-200 problems.
>
> face it, most of the patches rejected by Linus are not due to overload. He
> doesnt guarantee to say why he rejects patches - *and he must not*. Just
> knowing that your patch got rejected and thinking it all over again often
> helps finding problems that Linus missed first time around. If you submit
> to Linus then you better know exactly what you do.
There seems to be a perception that on at least some of the occasions Linus
said "it didn't get applied because nobody ever sent me that patch", people
were under the impression that the patch HAD been sent to him.
Sending a patch and hearing no reply, resending the same patch and then
having it applied... That sends mixed signals. Resending the same patch a
dozen times before it gets applied, how do you know if it's being rejected
for a reason or if it's just a bad time?
> it's so much easier to blame Linus, or maintainers.
It's not a question of "blame". Why does everybody keep thinking it's a
question of blame?
It's "There seems to be a problem. How do we fix it?"
The replies I've gotten range from denying there is any problem, assurances
that the situation is functioning as maximum possible efficiency and cannot
be improved, assurances that the problem is purely perceptual on my part, and
a couple variations on "just live with it".
If this is the consensus...
> It's so much easier to
> fire off an email flaming Linus and getting off the steam than to actually
> accept the possibility of mistake and *fix* the patch. I'll go on record
> saying that good patches are not ignored, even these days when the number
> of active kernel hackers has multipled.
So patches that fix simple build breakage in things like the radeon or ymfpci
drivers do not need to be resubmitted for multiple point releases?
> People might have to go through
> several layers first, and finding some kernel hacker who is not as loaded
> as Linus to review your patch might be necessery as well (especially if
> the patch is complex), but if you go through the right layers then you can
> be sure that nothing worthwile gets rejected arbitrarily.
Uh-huh. Find people to review your patch, go through the right layers...
And a paralell tree to Linus's, dedicated to patch processing and tracking
patches, with a patch submission system dedicated to routing patches to the
proper maintainers, reviewing and cross-checking patches from maintainers,
resolving conflicts, subjecting the lot to public scrutiny and being a
one-stop-shopping place for people who want to find bugs in something...
Like Alan Cox did for years, and like Dave Jones is doing now... This is a
totally different subject then?
Are people saying this is a bad thing? Saying that this is useless?
Oh well, it was just a suggestion. Seemed kind of a safe one since we were
already mostly DOING it...
> Ingo
Rob
-
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!not-for-mail
From: Rob Landley <land...@trommello.org>
Newsgroups: lucky.linux.kernel
Subject: Re: A modest proposal -- We need a patch penguin
Date: Tue, 29 Jan 2002 23:57:51 +0000 (UTC)
Organization: unknown
Lines: 74
Sender: n...@horse.lucky.net
Approved: newsmas...@lucky.net
Message-ID: <200201292332.g0TNWwU21215@snark.thyrsus.com.lucky.linux.kernel>
References: <Pine.LNX.4.33.0201290914270.7701-100000@athlon.transmeta.com>
NNTP-Posting-Host: horse.lucky.net
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
X-Trace: horse.lucky.net 1012348671 3409 193.193.193.118 (29 Jan 2002 23:57:51 GMT)
X-Complaints-To: usenet@horse.lucky.net
NNTP-Posting-Date: Tue, 29 Jan 2002 23:57:51 +0000 (UTC)
X-Mailer: KMail [version 1.3.1]
In-Reply-To: <Pine.LNX.4.33.0201290914270.7701-100000@athlon.transmeta.com>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Comment-To: Linus Torvalds
On Tuesday 29 January 2002 12:36 pm, Linus Torvalds wrote:
> On Tue, 29 Jan 2002, Skip Ford wrote:
> > Linus Torvalds wrote:
> > [snip]
> >
> > > A word of warning: good maintainers are hard to find. Getting more of
> > > them helps, but at some point it can actually be more useful to help
> > > the _existing_ ones. I've got about ten-twenty people I really trust,
> > > and
> >
> > Then why not give the subsystem maintainers patch permissions on your
> > tree. Sort of like committers. The problem people have is that you're
> > dropping patches from those ten-twenty people you trust.
>
> No. Ask them, and they will (I bet) pretty uniformly tell you that I'm
> _not_ dropping their patches (although I'm sometimes critical of them,
> and will tell them that they do not get applied).
Andre Hedrick, Eric Raymond, Rik van Riel, Michael Elizabeth Chastain, Axel
Boldt...
> I think there is some confusion about who I trust. Being listed as
> MAINTAINER doesn't mean you are automatically trusted. The MAINTAINERS
> list is not meant for me _at_all_ in fact, it's meant more as one of the
> places for _others_ to search for a contact with.
Ah. So being listed in the maintainers list doesn't mean someone is actually
a maintainer it makes sense to forward patches to?
Are you backing away from the maintainer system, or were the rest of us
misinterpreting what it meant all along? Does being a maintainer mean you
feel you have delegated any actual authority to them at all, or is it merely
a third party tech support contact point?
You seem to be saying "send patches to maintainers, support the maintainers
better, but don't expect me to necessarily take patches from them". Who
should patches be sent TO?
> Examples of people who I trust: Ingo Molnar, Jeff Garzik, Alan Cox, Al
> Viro, David Miller, Greg KH, Andrew Morton etc. They've shown what I call
> "good taste" for a long time. But it's not always a long process - some
> of you may remember Bill Hawes, for example, who came out of nowhere
> rather quickly.
So listed "maintainers" may need to forward patches to these people, and get
them to sign off on them, in order to get their patches at least reviewed for
inclusion into your tree?
If that's the process, fine. I'm just trying to clarify what the process IS,
other than spamming your mailbox with a cron job (as has been suggested and
actually taken seriously as long as re-testing is also automated)...
> And there are categories of people who just own a big enough chunk that is
> separate enough that I trust them for that area: architecture maintainers
> etc tend to be here, as long as they only affect their own architecture.
>
> But you have to realize that there are a _lot_ of people on the
> maintainers list that I don't implicitly trust. And being loud and
> wellknown on the mailing lists or IRC channels doesn't make them any more
> trusted.
I've noticed that rather a lot of development seems to be moving to IRC. How
is this NOT to be interpreted as a lack of endorsement of the functionality
of the other channels? Is IRC "just nice", or does IRC address a problem not
otherwise being addressed?
> Linus
Rob
-
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: Tue, 29 Jan 2002 13:00:57 -0500
From: "Eric S. Raymond" <e...@thyrsus.com>
X-To: Linux Kernel List <linux-ker...@vger.kernel.org>
Subject: Re: A modest proposal -- We need a patch penguin
Message-ID: <linux.kernel.20020129130057.A15914@thyrsus.com>
Reply-To: e...@thyrsus.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Organization: Eric Conspiracy Secret Labs
Approved: n...@nntp-server.caltech.edu
Lines: 38
Ingo Molnar:
>If a patch gets ignored 33 times in a row then perhaps the person doing
>the patch should first think really hard about the following 4 issues:
>
> - cleanliness
> - concept
> - timing
> - testing
>
>a violation of any of these items can cause patch to be dropped *without
>notice*. Face it, it's not Linus' task to teach people how to code or how
>to write correct patches. Sure, he still does teach people most of the
>time, but you cannot *expect* him to be able to do it 100% of the time.
Since the "33 times in a row" seems to refer to my bad experience with the
Configure.help patches, I think I need to correct a misconception.
The patches in question were *documentation*. No concept issue, no
timing issue, no testing issue (I don't know what a "cleanliness"
issue would be in this context). I know that Michael Elizabeth
Chastain, the listed CML1 maintainer, has had similar frustrating
exoeriences trying to get documentation patches folded in.
We're not talking about obscure internals changes that could break the
kernel, we're talking zero-risk patches submitted by official maintainers.
This is not a situation that ought to require a lot of judgment or
attention on Linus's part.
The fact that Linus *does* have to pass on all such patches, and is
dropping a lot of them them on the floor, is the clearest possible
example of the weaknesses in the present system.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
-
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: Tue, 29 Jan 2002 15:50:43 -0800 (PST)
From: Linus Torvalds <torva...@transmeta.com>
To: Rob Landley <land...@trommello.org>
cc: Skip Ford <skip.f...@verizon.net>, <linux-ker...@vger.kernel.org>,
Andrea Arcangeli <and...@suse.de>
Subject: Re: A modest proposal -- We need a patch penguin
In-Reply-To: <200201292332.g0TNWwU21215@snark.thyrsus.com>
Original-Message-ID: <Pine.LNX.4.33.0201291538530.1747-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: Tue, 29 Jan 2002 23:57:56 GMT
Message-ID: <fa.ob9ve7v.jk84r9@ifi.uio.no>
References: <fa.i92a79v.en4qai@ifi.uio.no>
Lines: 57
On Tue, 29 Jan 2002, Rob Landley wrote:
> > >
> > > Then why not give the subsystem maintainers patch permissions on your
> > > tree. Sort of like committers. The problem people have is that you're
> > > dropping patches from those ten-twenty people you trust.
> >
> > No. Ask them, and they will (I bet) pretty uniformly tell you that I'm
> > _not_ dropping their patches (although I'm sometimes critical of them,
> > and will tell them that they do not get applied).
>
> Andre Hedrick, Eric Raymond, Rik van Riel, Michael Elizabeth Chastain, Axel
> Boldt...
NONE of those are in the ten-twenty people group.
How many people do you think fits in a small group? Hint. It sure isn't
all 300 on the maintainers list.
> Ah. So being listed in the maintainers list doesn't mean someone is actually
> a maintainer it makes sense to forward patches to?
Sure it does.
It just doesn't mean that they should send stuff to _me_.
Did you not understand my point about scalability? I can work with a
limited number of people, and those people can work with _their_ limited
number of people etc etc.
The MAINTAINERS file is _not_ a list of people I work with on a daily
basis. In fact, I don't necessarily even recognize the names of all those
people.
Let's take an example. Let's say that you had a patch for ppp. You'd send
the patch to Paul Mackerras. He, in turn, would send his patches to David
Miller (who knows a hell of a lot better what it's all about than I do).
And he in turn sends them to me.
They are both maintainers. That doesn't mean that I necessarily work with
every maintainer directly.
Or look at USB: I get the USB patches from Greg, and he gets them from
various different people. Johannes Erdfelt is the maintainer for uhci.c,
and he sends them to Greg, not to me.
Why? Because having hundreds of people emailing me _obviously_ doesn't
scale. Never has, never will. It may work over short timeperiods wih lots
of energy, but it obviously isn't a stable setup.
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-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: A modest proposal -- We need a patch penguin
To: land...@trommello.org (Rob Landley)
Original-Date: Wed, 30 Jan 2002 00:08:04 +0000 (GMT)
Cc: torva...@transmeta.com (Linus Torvalds), skip.f...@verizon.net (Skip Ford),
linux-ker...@vger.kernel.org, and...@suse.de (Andrea Arcangeli)
In-Reply-To: <200201292332.g0TNWwU21215@snark.thyrsus.com>
from "Rob Landley" at Jan 29, 2002 06:34:06 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: <E16ViIG-0005bo-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: Wed, 30 Jan 2002 00:02:27 GMT
Message-ID: <fa.h1j2svv.11meihs@ifi.uio.no>
References: <fa.i92a79v.en4qai@ifi.uio.no>
Lines: 18
> > Viro, David Miller, Greg KH, Andrew Morton etc. They've shown what I call
> > "good taste" for a long time. But it's not always a long process - some
> > of you may remember Bill Hawes, for example, who came out of nowhere
> > rather quickly.
>
> So listed "maintainers" may need to forward patches to these people, and get
> them to sign off on them, in order to get their patches at least reviewed for
> inclusion into your tree?
Count me out of that job. If you want something in 2.5 don't bug me. I
simply don't care
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>
Original-Date: Tue, 29 Jan 2002 22:07:00 -0200 (BRST)
From: Rik van Riel <r...@conectiva.com.br>
X-X-Sender: <r...@imladris.surriel.com>
To: Linus Torvalds <torva...@transmeta.com>
Cc: Rob Landley <land...@trommello.org>, Skip Ford <skip.f...@verizon.net>,
<linux-ker...@vger.kernel.org>, Andrea Arcangeli <and...@suse.de>
Subject: Re: A modest proposal -- We need a patch penguin
In-Reply-To: <Pine.LNX.4.33.0201291538530.1747-100000@penguin.transmeta.com>
Original-Message-ID:
<Pine.LNX.4.33L.0201292205370.32617-100000@imladris.surriel.com>
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: Wed, 30 Jan 2002 00:14:48 GMT
Message-ID: <fa.o0jom6v.sim0oi@ifi.uio.no>
References: <fa.ob9ve7v.jk84r9@ifi.uio.no>
Lines: 33
On Tue, 29 Jan 2002, Linus Torvalds wrote:
> > Andre Hedrick, Eric Raymond, Rik van Riel, Michael Elizabeth
> > Chastain, Axel Boldt...
>
> NONE of those are in the ten-twenty people group.
>
> How many people do you think fits in a small group? Hint. It sure
> isn't all 300 on the maintainers list.
That's fine with me, but _who_ do I send VM patches to if
I can't send them to you ?
There is no maintainer for mm/* or kernel/*, it's just you.
I agree it would be nice to have somebody from within the
ten-twenty people group take care of that, but we'll need
to have _somebody_ ...
regards,
Rik
--
"Linux holds advantages over the single-vendor commercial OS"
-- Microsoft's "Competing with Linux" document
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: Tue, 29 Jan 2002 16:39:47 -0800 (PST)
From: Linus Torvalds <torva...@transmeta.com>
To: Rik van Riel <r...@conectiva.com.br>
cc: Rob Landley <land...@trommello.org>, Skip Ford <skip.f...@verizon.net>,
<linux-ker...@vger.kernel.org>, Andrea Arcangeli <and...@suse.de>
Subject: Re: A modest proposal -- We need a patch penguin
In-Reply-To: <Pine.LNX.4.33L.0201292205370.32617-100000@imladris.surriel.com>
Original-Message-ID: <Pine.LNX.4.33.0201291610020.1747-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: Wed, 30 Jan 2002 00:42:25 GMT
Message-ID: <fa.o8pvdnv.h4c4b1@ifi.uio.no>
References: <fa.o0jom6v.sim0oi@ifi.uio.no>
Lines: 38
On Tue, 29 Jan 2002, Rik van Riel wrote:
>
> That's fine with me, but _who_ do I send VM patches to if
> I can't send them to you ?
The VM stuff right now seems to be Andrea, Dave or you yourself (right now
I just wish you would split up your patches like Andrea does, that way I
can cherry-pick).
> There is no maintainer for mm/* or kernel/*, it's just you.
As to kernel/ there are actually maintainers for some sub-areas, the most
noticeable being Ingo on the scheduler. The rest of kernel/ hasn't ever
been much of a problem, really.
The VM is a big issue, of course. And that one isn't likely to go away
anytime soon as a point of contention. And it's not easy to modularize,
apart from the obvious pieces (ie "filemap.c" vs the rest).
You may not believe me when I say so, but I personally _really_ hope your
rmap patches will work out. I may not have believed in your patches in a
2.4.x kind of timeframe, but for 2.6.x I'm more optimistic. As to how to
actually modularize it better to make points of contention smaller, I
don't know how.
At the same time, while I can understand your personal pain, I don't think
most of the problems have been with the VM (maintenance-wise, that is.
Most of the _technical_ problems really have been with the VM, it's just
the most complex piece).
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!
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>
X-Authentication-Warning: penguin.transmeta.com: torvalds owned process doing -bs
Original-Date: Tue, 29 Jan 2002 23:48:05 -0800 (PST)
From: Linus Torvalds <torva...@transmeta.com>
To: Daniel Phillips <phill...@bonn-fries.net>
cc: Alexander Viro <v...@math.psu.edu>, Ingo Molnar <mi...@elte.hu>,
Rob Landley <land...@trommello.org>, <linux-ker...@vger.kernel.org>,
Rik van Riel <r...@conectiva.com.br>
Subject: Re: A modest proposal -- We need a patch penguin
In-Reply-To: <E16Vp2w-0000CA-00@starship.berlin>
Original-Message-ID: <Pine.LNX.4.33.0201292326110.1428-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: Wed, 30 Jan 2002 07:50:26 GMT
Message-ID: <fa.o9phdfv.g46538@ifi.uio.no>
References: <fa.hme5u9v.jgakbd@ifi.uio.no>
Lines: 27
Calm down guys. Al, Daniel, peace.
It was fun while people were just ragging on me (it tends to happen about
every 6 months or so, and I have a thick skin - and every time it happens
some problems do get unearthed and that's fine), but let's not make this
degenerate into a real hate-fest..
Shake hands, please.
-- tangential --
One thing intrigued me in this thread - which was not the discussion
itself, but the fact that Rik is using bitkeeper.
How many other people are actually using bitkeeper already for the kernel?
I know the ppc guys have, for a long time, but who else is? bk, unlike
CVS, should at least be _able_ to handle a "network of people" kind of
approach.
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/
Date: Wed, 30 Jan 2002 16:50:16 +0100
From: Tom Rini <tr...@kernel.crashing.org>
Subject: Re: A modest proposal -- We need a patch penguin
Message-ID: <20020130154233.GK25973@opus.bloom.county>
References: <E16Vp2w-0000CA-00@starship.berlin>
<Pine.LNX.4.33.0201292326110.1428-100000@penguin.transmeta.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.33.0201292326110.1428-100000@penguin.transmeta.com>
User-Agent: Mutt/1.3.27i
Sender: robo...@news.nic.it
X-Mailing-List: linux-kernel@vger.kernel.org
Approved: robo...@news.nic.it (1.20)
NNTP-Posting-Host: a.841.anti-phl.bofh.it
Newsgroups: linux.kernel
Organization: linux.*_mail_to_news_unidirectional_gateway
Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
newsmi-us.news.garr.it!newsbo.news.garr.it!newsrm.news.garr.it!
NewsITBone-GARR!newsfeeder.edisontel.com!bofh.it!robomod
X-Original-Cc: Daniel Phillips <phill...@bonn-fries.net>,
Alexander Viro <v...@math.psu.edu>, Ingo Molnar <mi...@elte.hu>,
Rob Landley <land...@trommello.org>, linux-ker...@vger.kernel.org,
Rik van Riel <r...@conectiva.com.br>
X-Original-Date: Wed, 30 Jan 2002 08:42:33 -0700
X-Original-Sender: linux-kernel-ow...@vger.kernel.org
X-Original-To: Linus Torvalds <torva...@transmeta.com>
Lines: 29
On Tue, Jan 29, 2002 at 11:48:05PM -0800, Linus Torvalds wrote:
> -- tangential --
>
> One thing intrigued me in this thread - which was not the discussion
> itself, but the fact that Rik is using bitkeeper.
>
> How many other people are actually using bitkeeper already for the kernel?
> I know the ppc guys have, for a long time, but who else is? bk, unlike
> CVS, should at least be _able_ to handle a "network of people" kind of
> approach.
It does in some ways anyhow. Following things downstream is rather
painless, but one of the things we in the PPC tree hit alot is when we
have a new file in one of the sub trees and want to move it up to the
'stable' tree, or when it shows up in your/marcelo's tree. bk send only
works for same base tree type things (ie a clone of tree X, some
changes, not a clone of tree Y, which was a clone of tree X but has lots
of changes and has tree X changes pulled in frequently). Unfortunaly I
don't think this is an easy problem to work on either.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
-
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/
Date: Wed, 30 Jan 2002 17:10:14 +0100
From: Larry McVoy <l...@bitmover.com>
Subject: Re: A modest proposal -- We need a patch penguin
Message-ID: <20020130080308.D18381@work.bitmover.com>
Mail-Followup-To: Larry McVoy <l...@work.bitmover.com>,
Tom Rini <tr...@kernel.crashing.org>,
Linus Torvalds <torva...@transmeta.com>,
Daniel Phillips <phill...@bonn-fries.net>,
Alexander Viro <v...@math.psu.edu>, Ingo Molnar <mi...@elte.hu>,
Rob Landley <land...@trommello.org>, linux-ker...@vger.kernel.org,
Rik van Riel <r...@conectiva.com.br>
References: <E16Vp2w-0000CA-00@starship.berlin>
<Pine.LNX.4.33.0201292326110.1428-100000@penguin.transmeta.com>
<20020130154233.GK25973@opus.bloom.county>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20020130154233.GK25973@opus.bloom.county>;
from trini@kernel.crashing.org on Wed, Jan 30, 2002 at 08:42:33AM -0700
Sender: robo...@news.nic.it
X-Mailing-List: linux-kernel@vger.kernel.org
Approved: robo...@news.nic.it (1.20)
NNTP-Posting-Host: a.892.anti-phl.bofh.it
Newsgroups: linux.kernel
Organization: linux.*_mail_to_news_unidirectional_gateway
Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
newsmi-us.news.garr.it!newsbo.news.garr.it!newsrm.news.garr.it!
NewsITBone-GARR!newsfeeder.edisontel.com!bofh.it!robomod
X-Original-Cc: Linus Torvalds <torva...@transmeta.com>,
Daniel Phillips <phill...@bonn-fries.net>,
Alexander Viro <v...@math.psu.edu>, Ingo Molnar <mi...@elte.hu>,
Rob Landley <land...@trommello.org>, linux-ker...@vger.kernel.org,
Rik van Riel <r...@conectiva.com.br>
X-Original-Date: Wed, 30 Jan 2002 08:03:08 -0800
X-Original-Sender: linux-kernel-ow...@vger.kernel.org
X-Original-To: Tom Rini <tr...@kernel.crashing.org>
Lines: 62
On Wed, Jan 30, 2002 at 08:42:33AM -0700, Tom Rini wrote:
> On Tue, Jan 29, 2002 at 11:48:05PM -0800, Linus Torvalds wrote:
> It does in some ways anyhow. Following things downstream is rather
> painless, but one of the things we in the PPC tree hit alot is when we
> have a new file in one of the sub trees and want to move it up to the
> 'stable' tree
Summary: only an issue because Linus isn't using BK.
Details:
The source of this problem is that there is no Linux/BK tree. To
understand, read on. The PPC team "tracks" the kernel using BK.
There is a paper with pictures describing what they do at
http://www.bitkeeper.com/tracking.ps
To do this, they have a BK repository which is the "pristine" source,
i.e., it has nothing but released code from Linus. They import new work
into that repository using "bk import -tpatch" which takes traditional
patches.
There is a "child" repository which is a copy of the "pristine". The
child repository is used to hold not only the pristine work but also
all the work from the PPC team. Think of it as "Linux+PPC".
To get patches back to Linus, the PPC maintainer (used to be Cort, now
Paul) will export changes as a traditional patch from the "Linux+PPC"
repository and send them to Linus. These changes, sometimes modified,
make their way back to the PPC team through the "pristine" tree. That's
the source of the problem.
So the work flow is
patches -> pristine
v
v
Linux+PPC -> patches to Linus
The problem is when a file is created in the Linux+PPC tree, sent to Linus,
comes back as a patch, is imported in pristine, and then is sent to
Linux+PPC.
BitKeeper tracks files just like a file system, by a BK form of an inode.
That file that came in as a patch is a different inode, what is logically
the same file was created twice. Much like if you created foo and bar
and then said "mv foo bar", BitKeeper will complain at you that the file
exists already.
This problem goes away if the PPC team could send Linus BK patches and
Linus sent out his changes as BK patches. It doesn't require a wholesale
switch to BK, Linus can still take traditional patches and send them out,
but if he maintained a BK tree as well, the problem Troy described goes
away.
--
---
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>
Original-Date: Wed, 30 Jan 2002 14:14:52 -0200 (BRST)
From: Rik van Riel <r...@conectiva.com.br>
X-X-Sender: <r...@imladris.surriel.com>
To: Larry McVoy <l...@bitmover.com>
Cc: Tom Rini <tr...@kernel.crashing.org>,
Linus Torvalds <torva...@transmeta.com>,
Daniel Phillips <phill...@bonn-fries.net>,
Alexander Viro <v...@math.psu.edu>, Ingo Molnar <mi...@elte.hu>,
Rob Landley <land...@trommello.org>, <linux-ker...@vger.kernel.org>
Subject: Re: A modest proposal -- We need a patch penguin
In-Reply-To: <20020130080308.D18381@work.bitmover.com>
Original-Message-ID: <Pine.LNX.4.33L.0201301408540.11594-100000@imladris.surriel.com>
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: Wed, 30 Jan 2002 18:18:58 GMT
Message-ID: <fa.o1jglmv.qiu18g@ifi.uio.no>
References: <fa.h3pun7v.11mqlq6@ifi.uio.no>
Lines: 40
On Wed, 30 Jan 2002, Larry McVoy wrote:
> On Wed, Jan 30, 2002 at 08:42:33AM -0700, Tom Rini wrote:
> > On Tue, Jan 29, 2002 at 11:48:05PM -0800, Linus Torvalds wrote:
> > It does in some ways anyhow. Following things downstream is rather
> > painless, but one of the things we in the PPC tree hit alot is when we
> > have a new file in one of the sub trees and want to move it up to the
> > 'stable' tree
>
> Summary: only an issue because Linus isn't using BK.
Bitkeeper also seems to have some problems applying out-of-order
changesets or applying them partially.
Changesets sent by 'bk send' are also much harder to read than
unidiffs ;)
I think for bitkeeper to be useful for the kernel we really need:
1) 'bk send' format Linus can read easily
2) the ability to send individual changes (for example, the
foo_net.c fixes from 1.324 and 1.350) in one nice unidiff
3) the ability for Linus to apply patches that are slightly
"out of order" - a direct consequence of (2)
regards,
Rik
--
"Linux holds advantages over the single-vendor commercial OS"
-- Microsoft's "Competing with Linux" document
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/
Date: Wed, 30 Jan 2002 17:40:16 +0100
From: Larry McVoy <l...@bitmover.com>
Subject: Re: A modest proposal -- We need a patch penguin
Message-ID: <20020130083254.H23269@work.bitmover.com>
Mail-Followup-To: Larry McVoy <l...@work.bitmover.com>,
Rik van Riel <r...@conectiva.com.br>, Larry McVoy <l...@bitmover.com>,
Tom Rini <tr...@kernel.crashing.org>,
Linus Torvalds <torva...@transmeta.com>,
Daniel Phillips <phill...@bonn-fries.net>,
Alexander Viro <v...@math.psu.edu>, Ingo Molnar <mi...@elte.hu>,
Rob Landley <land...@trommello.org>, linux-ker...@vger.kernel.org
References: <20020130080308.D18381@work.bitmover.com>
<Pine.LNX.4.33L.0201301408540.11594-100000@imladris.surriel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <Pine.LNX.4.33L.0201301408540.11594-100000@imladris.surriel.com>;
from riel@conectiva.com.br on Wed, Jan 30, 2002 at 02:14:52PM -0200
Sender: robo...@news.nic.it
X-Mailing-List: linux-kernel@vger.kernel.org
Approved: robo...@news.nic.it (1.20)
NNTP-Posting-Host: a.685.anti-phl.bofh.it
Newsgroups: linux.kernel
Organization: linux.*_mail_to_news_unidirectional_gateway
Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
newsmi-us.news.garr.it!newsbo.news.garr.it!newsrm.news.garr.it!
NewsITBone-GARR!news.mailgate.org!bofh.it!robomod
X-Original-Cc: Larry McVoy <l...@bitmover.com>,
Tom Rini <tr...@kernel.crashing.org>,
Linus Torvalds <torva...@transmeta.com>,
Daniel Phillips <phill...@bonn-fries.net>,
Alexander Viro <v...@math.psu.edu>, Ingo Molnar <mi...@elte.hu>,
Rob Landley <land...@trommello.org>, linux-ker...@vger.kernel.org
X-Original-Date: Wed, 30 Jan 2002 08:32:54 -0800
X-Original-Sender: linux-kernel-ow...@vger.kernel.org
X-Original-To: Rik van Riel <r...@conectiva.com.br>
Lines: 67
On Wed, Jan 30, 2002 at 02:14:52PM -0200, Rik van Riel wrote:
> On Wed, 30 Jan 2002, Larry McVoy wrote:
> > On Wed, Jan 30, 2002 at 08:42:33AM -0700, Tom Rini wrote:
> > > On Tue, Jan 29, 2002 at 11:48:05PM -0800, Linus Torvalds wrote:
> > > It does in some ways anyhow. Following things downstream is rather
> > > painless, but one of the things we in the PPC tree hit alot is when we
> > > have a new file in one of the sub trees and want to move it up to the
> > > 'stable' tree
> >
> > Summary: only an issue because Linus isn't using BK.
>
> Bitkeeper also seems to have some problems applying out-of-order
> changesets or applying them partially.
It does indeed and I think this is a far more serious issue than, for
example, the shouting SCCS subdirectories. So let's discuss it.
> Changesets sent by 'bk send' are also much harder to read than
> unidiffs ;)
Yeah but if you do a bk send -d it prefixes them with unidiffs or
you can do
cat patch | bk receive /home/bk/vmtree
cd /home/bk/vmtree/RESYNC
bk csets
and you are looking at the changes in the changeset viewer which most
people think is nicer than unidiffs.
> I think for bitkeeper to be useful for the kernel we really need:
>
> 1) 'bk send' format Linus can read easily
That's done.
> 2) the ability to send individual changes (for example, the
> foo_net.c fixes from 1.324 and 1.350) in one nice unidiff
That's possible now but not a really good idea.
> 3) the ability for Linus to apply patches that are slightly
> "out of order" - a direct consequence of (2)
This is really the main point. There are two issues, one is out of order
and the other is what we call "false dependencies". I think it is the
latter that bites you most of the time. The reason you want out of order
is because of the false dependencies, at least that is my belief, let
me tell you what they are and you tell me.
Suppose that you make 3 changes, a driver change, a vm change, and a
networking change. Suppose that you want to send the networking change
to Linus. With patch, you just diff 'em and send and hope that patch
can put it together on the other end. With BK as it stands today, there
is a linear dependency between all three changes and if you want to send
the networking change, you also have to send the other 2.
How much of the out order stuff goes away if you could send changes out
of order as long as they did not overlap (touch the same files)?
--
---
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>
Original-Date: Wed, 30 Jan 2002 19:35:03 +0100 (CET)
From: Ingo Molnar <mi...@elte.hu>
Reply-To: <mi...@elte.hu>
To: Larry McVoy <l...@bitmover.com>
Cc: Rik van Riel <r...@conectiva.com.br>, Tom Rini <tr...@kernel.crashing.org>,
Linus Torvalds <torva...@transmeta.com>,
Daniel Phillips <phill...@bonn-fries.net>,
Alexander Viro <v...@math.psu.edu>,
Rob Landley <land...@trommello.org>,
linux-kernel <linux-ker...@vger.kernel.org>
Subject: Re: A modest proposal -- We need a patch penguin
In-Reply-To: <20020130083254.H23269@work.bitmover.com>
Original-Message-ID: <Pine.LNX.4.33.0201301933390.11022-100000@localhost.localdomain>
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: Wed, 30 Jan 2002 17:23:49 GMT
Message-ID: <fa.ntkr45v.19mcn81@ifi.uio.no>
References: <fa.hapcnnv.16mkla5@ifi.uio.no>
Lines: 17
On Wed, 30 Jan 2002, Larry McVoy wrote:
> How much of the out order stuff goes away if you could send changes
> out of order as long as they did not overlap (touch the same files)?
could this be made: 'as long as they do not touch the same lines of code,
taking 3 lines of context into account'? (ie. unified diff definition of
'collisions' context.)
Ingo
-
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: Wed, 30 Jan 2002 08:43:31 -0800
From: Larry McVoy <l...@bitmover.com>
X-To: Ingo Molnar <mi...@elte.hu>
X-Cc: Larry McVoy <l...@bitmover.com>, Rik van Riel <r...@conectiva.com.br>,
Tom Rini <tr...@kernel.crashing.org>,
Linus Torvalds <torva...@transmeta.com>,
Daniel Phillips <phill...@bonn-fries.net>,
Alexander Viro <v...@math.psu.edu>,
Rob Landley <land...@trommello.org>,
linux-kernel <linux-ker...@vger.kernel.org>
Subject: Re: A modest proposal -- We need a patch penguin
Message-ID: <linux.kernel.20020130084331.K23269@work.bitmover.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Approved: n...@nntp-server.caltech.edu
Lines: 26
On Wed, Jan 30, 2002 at 07:35:03PM +0100, Ingo Molnar wrote:
>
> On Wed, 30 Jan 2002, Larry McVoy wrote:
>
> > How much of the out order stuff goes away if you could send changes
> > out of order as long as they did not overlap (touch the same files)?
>
> could this be made: 'as long as they do not touch the same lines of code,
> taking 3 lines of context into account'? (ie. unified diff definition of
> 'collisions' context.)
No. What you described is diff/patch. We have that already and if it
really worked in all the cases there would be no need for BitKeeper to
exist. I'll be the first to admit that BK is too pedantic about change
ordering and atomicity, but you need to see that there is a spectrum and
if we slid BK over to what you described it would be a meaningless tool,
it would basically be a lot of code implementing what people already do
with diff/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!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: Wed, 30 Jan 2002 19:48:35 +0100 (CET)
From: Ingo Molnar <mi...@elte.hu>
Reply-To: <mi...@elte.hu>
X-To: Larry McVoy <l...@bitmover.com>
X-Cc: Rik van Riel <r...@conectiva.com.br>, Tom Rini <tr...@kernel.crashing.org>,
Linus Torvalds <torva...@transmeta.com>,
Daniel Phillips <phill...@bonn-fries.net>,
Alexander Viro <v...@math.psu.edu>,
Rob Landley <land...@trommello.org>,
linux-kernel <linux-ker...@vger.kernel.org>
Subject: Re: A modest proposal -- We need a patch penguin
Message-ID:
<linux.kernel.Pine.LNX.4.33.0201301943050.11581-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Approved: n...@nntp-server.caltech.edu
Lines: 37
On Wed, 30 Jan 2002, Larry McVoy wrote:
> No. What you described is diff/patch. We have that already and if it
> really worked in all the cases there would be no need for BitKeeper to
> exist. I'll be the first to admit that BK is too pedantic about
> change ordering and atomicity, but you need to see that there is a
> spectrum and if we slid BK over to what you described it would be a
> meaningless tool, it would basically be a lot of code implementing
> what people already do with diff/patch.
eg. i sent 8 different scheduler update patches 5 days ago:
[patch] [sched] fork-fix 2.5.3-pre5
[patch] [sched] yield-fixes 2.5.3-pre5
[patch] [sched] SCHED_RR fix, 2.5.3-pre5
[patch] [sched] set_cpus_allowed() fix, 2.5.3-pre5
[patch] [sched] entry.S offset fix, 2.5.3-pre5.
[patch] [sched] cpu_logical_map fixes, balancing, 2.5.3-pre5
[patch] [sched] compiler warning fix, 2.5.3-pre3
[patch] [sched] unlock_task_rq() cleanup, 2.5.3-pre3
these patches, while many of them are touching the same file (sched.c) are
functionally orthogonal, and can be applied in any order. Linus has
applied all of them, but he might have omitted any questionable one and
still apply the rest.
how would such changes be expressed via BK, and would it be possible for
Linus to reject/accept an arbitrary set of these patches?
Ingo
-
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: Wed, 30 Jan 2002 09:25:29 -0800
From: Larry McVoy <l...@bitmover.com>
X-To: Ingo Molnar <mi...@elte.hu>
X-Cc: Larry McVoy <l...@bitmover.com>, Rik van Riel <r...@conectiva.com.br>,
Tom Rini <tr...@kernel.crashing.org>,
Linus Torvalds <torva...@transmeta.com>,
Daniel Phillips <phill...@bonn-fries.net>,
Alexander Viro <v...@math.psu.edu>,
Rob Landley <land...@trommello.org>,
linux-kernel <linux-ker...@vger.kernel.org>
Subject: Re: A modest proposal -- We need a patch penguin
Message-ID: <linux.kernel.20020130092529.O23269@work.bitmover.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Approved: n...@nntp-server.caltech.edu
Lines: 89
On Wed, Jan 30, 2002 at 07:48:35PM +0100, Ingo Molnar wrote:
> eg. i sent 8 different scheduler update patches 5 days ago:
>
> [patch] [sched] fork-fix 2.5.3-pre5
> [patch] [sched] yield-fixes 2.5.3-pre5
> [patch] [sched] SCHED_RR fix, 2.5.3-pre5
> [patch] [sched] set_cpus_allowed() fix, 2.5.3-pre5
> [patch] [sched] entry.S offset fix, 2.5.3-pre5.
> [patch] [sched] cpu_logical_map fixes, balancing, 2.5.3-pre5
> [patch] [sched] compiler warning fix, 2.5.3-pre3
> [patch] [sched] unlock_task_rq() cleanup, 2.5.3-pre3
>
> these patches, while many of them are touching the same file (sched.c) are
> functionally orthogonal, and can be applied in any order. Linus has
> applied all of them, but he might have omitted any questionable one and
> still apply the rest.
>
> how would such changes be expressed via BK, and would it be possible for
> Linus to reject/accept an arbitrary set of these patches?
There is a way to do this in BK that would work just fine. It pushes some
work back onto the developer, but if you are willing to do it, we have no
problem doing what you want with BK in its current form and I suspect that
the work is very similar to what you are already doing.
In your list above, all of the patches are against 2.5.3-pre5. If you did
the work for each patch against the 2.5.3-pre5 baseline, checking it in,
saving the BK patch, removing that changeset from the tree, and then going
onto the next change, what you'd have is exactly the same set of patches
as you have no. Literally. You could type the appropriate command to BK
and you should be able to generate a bit for bit identical patch.
In BK's mind, what you have done is to make a very "bushy" set of changes,
they are all "side by side". If you think of a graph of changes, you started
with
[older changes]
v
[2.5.3-pre4]
v
[2.5.3-pre5]
and then you added one change below that, multiple times. If you were to
combine all of those changes in a BK tree, it would look like
[older changes]
v
[2.5.3-pre4]
v
[2.5.3-pre5]
[sched1] [sched2] [sched3] [sched4] [sched5] [sched6] [sched7]
and BK would be happy to allow you to send any subset of the sched changes
to Linus and it would work *exactly* how you want it to work. If we could
get people to work like this, there are no problems. Just to make it really
clear you would do this
for p in patch_list
do bk vi sched.c # that will lock it if isn't
hack, debug, test
bk citool # check it in and make a changeset
bk makepatch -r+ > ~/bk-patches/patch.$p
bk undo -fr+ # get back to the same baseline
done
Here's what people actually do. They make the first change, then make
the second change in the same tree that already has the first change,
and so on. BitKeeper faithfully records the linear sequence of changes
and enforces that the changes propogate as that linear sequence. You can
skip some at the end but you can't skip any in the middle.
In your particular case, we really need out of order changesets to allow
the second type of work flow and cherry picking. However, a fairly common
case is that the changes are all in unrelated files and *even then*
BitKeeper enforces the linearity. That's the problem I think we need to
fix first, it's not a complete solution, but it is the 80-90% solution.
Until we give you a 100% solution, you have to realize that you are making
side by side changes and actually do it that way.
If any of this is not clear to anyone, please speak up and I'll try and
draw some pictures and add some explanation.
--
---
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!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: Wed, 30 Jan 2002 10:23:01 -0800 (PST)
From: Linus Torvalds <torva...@transmeta.com>
X-To: Larry McVoy <l...@bitmover.com>
X-cc: Ingo Molnar <mi...@elte.hu>, Rik van Riel <r...@conectiva.com.br>,
Tom Rini <tr...@kernel.crashing.org>,
Daniel Phillips <phill...@bonn-fries.net>,
Alexander Viro <v...@math.psu.edu>,
Rob Landley <land...@trommello.org>,
linux-kernel <linux-ker...@vger.kernel.org>
Subject: Re: A modest proposal -- We need a patch penguin
Message-ID:
<linux.kernel.Pine.LNX.4.33.0201301005260.1989-100000@penguin.transmeta.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Approved: n...@nntp-server.caltech.edu
Lines: 90
On Wed, 30 Jan 2002, Larry McVoy wrote:
>
> There is a way to do this in BK that would work just fine. It pushes some
> work back onto the developer, but if you are willing to do it, we have no
> problem doing what you want with BK in its current form and I suspect that
> the work is very similar to what you are already doing.
The thing is, bk should be able to do this on its own.
The rule on check-in should be: if the resultant changeset can be
automatically merged with an earlier changeset, it should be _parallel_ to
that changeset, not linear.
And note the "automatically merged" part. That still guarantees your
database consistency at all levels.
Let us assume that you have a tree that looks like
a -> b -> c
together with modifications "d". Now, "bk ci" (or, because this is more
expensive than a plain "ci", you can call it "bk backmerge" or something,
and all sane people will just stop using "ci") should instead of doing a
plain
a -> b -> c -> d
it would see how far back it can go with an automatic merge and add "d" at
the _furthest_ point possible. So let's assume that "d" really cannot be
merged with "b" but doesn't clash with "c", so what you'd create with "bk
backmerge" is the "maximally parallel version:
a -> b -> c
\
> d
Now, you'll say that this is exponentially expensive to do, and I agree.
But CPU-time is cheap, and notice that this "backmerge" would be done not
in one centralized location, but in parallel at different developers.
(Yeah, my example may look "cheap", but if you do exclusively backmerging,
then after a while your trees will have lots of very wide development, and
the m,ore interesting backmerge is when you already have
a -> b -> c -> f
-> d
-> e
and you're adding "g", and it doesn't merge with "c" but not with "d" and
"e", so you have to test every path backwards to see where you can push
it. In this case you'd end up with
a -> b -> c -> f
-> g
-> d
-> e
kind of tree.)
Just how expensive would that be? I'd be willing to make my machine sweat
a bit, if it would just automatically generate the most parallel
changesets possible.. And I bet you could do _this_ fairly easily if you
didn't care too much about trying to be too efficient.
You're saying your merges are perfect. USE that knowledge, and make it do
"bk backmerge".
(Once you do backmerge, the false dependencies no longer exist, AND
suddenly "bk" actually gives people information that they didn't have
before: the revision history actually tells you the _true_ dependencies in
the tree, not some stupid "this is the order in which things were checked
in" stuff that doesn't add any value that can't be seen from the changeset
directly)
Larry, give me that, and I'll promise to use bk exclusively for two months
to shake it out..
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/