gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnu-arch-users] Re: Linus


From: Miles Bader
Subject: [Gnu-arch-users] Re: Linus
Date: Thu, 9 Oct 2003 19:39:59 -0400
User-agent: Mutt/1.3.28i

On Thu, Oct 09, 2003 at 12:46:21PM -0700, Tom Lord wrote:
> The first thing missing here, and this seems to be true of BK, arch,
> svn, and everything else, is an actual patch queue.
> 
> Why should Miles need to resend an identical patch more than once?
> That's absurd.
> 
> Why isn't it the case that he sends it once, and then if he wants to
> know it's status, he looks at some web page?  Are Linus' limits on his
> ability to process email _really_ supposed to be a bottleneck on linux
> kernel development?

I think some of it is historical; I gather than traditionally Linus used
various mailbox files as his `short-term queue', and on submitters to be his
`long term queue'; the latter is a bit weird, but it does have the advantage
that it keeps things `fresh' -- people will regenerate patches against the
latest release, and presumably drop a patch if it becomes unnecessary.  With
a more active `pull from this remote branch' system, maybe such concerns are
less important (because the submitter would keep the branch updated), and
more automatic mechanisms are more practical.

> One idea is that it's Linus' database.   It's his queue.   A patch is
> "applied" or "rejected" or "pending" depending on what Linus does.
> 
> A different idea is that it's a shared database.   It's everybody's
> queue where we're all equal.   For example, can I query the database
> this way:

I think that Linus is pretty conservative about changing this, especially now
that many of the `major submitters' are using BK; I've seen various people
suggesting automatic queues of one sort or another, and Linus pretty much
rejecting them out-of-hand, saying (essentially, but filtered through by
biased eyes, and poor memory :-) `I don't want it, the current system works
for me.'  I've seen him reject both suggestions that _he_ keep a longer-term
queue (after all, if everyone else is willing to do the work for him ...),
and suggestions for some sort of automatic central queue system (I think he
_really_ doesn't want the same patches blindly submitted forever, and indeed
I think he said he'd likely just drop patches from such a system without even
looking at them).

A system would have to be _much better_ than the current one to make him use
it -- and I think that means better from _his_ point of view, not the
submitters.

Pull systems like arch or BK offer an improvement because they make it
easier to prevent stale patches.

Your description of a `confidence measure' for patches also seems
interesting.  The way it currently seems to work is that he basically wants
most changes filtered through Andrew Morton, Alan Cox, or whoever, receiving
their vote of confidence, and a degree of testing in their tree -- but of
course the same sort of problem occurs at a lower level with Andrew or Alan,
though they're generally a lot more willing to play fast and loose with what
goes into their trees than Linus (I think not least because they seem to
personally have much better facilities for managing [dare I say, queuing?]
patches in their tree).  A more formalized system might make the whole
process a lot smoother.

[I am curious about is how Linus's interaction with the `major submitters'
like Andrew works.  It's clear that Andrew maintains his own patch queue of
sorts (since he posts a summary of it to lkml periodically), and that Linus
doesn't just merge everything in Andrews tree, though he does merge large
parts of it.  I presume Linus uses BK to do the actual merging, but I wonder
how exactly the decision of whether/what to merge happens.  For instance, if
Linus just trusts Andrew completely, maybe Andrew maintains a `ready to
merge' branch which Linus just periodically pulls; if this is the case, then
I guess it's not a really scalable process (Linus clearly wouldn't want to do
that for most submitters).  With Alan Cox it's even more interesting because
Alan doesn't use BK...]

[Geez, I'm not actually sure if the above contains a point or not...]

-Miles
-- 
The secret to creativity is knowing how to hide your sources.
  --Albert Einstein




reply via email to

[Prev in Thread] Current Thread [Next in Thread]