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

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

Re: [Gnu-arch-users] Linus


From: Davide Libenzi
Subject: Re: [Gnu-arch-users] Linus
Date: Thu, 9 Oct 2003 13:09:14 -0700 (PDT)

On Thu, 9 Oct 2003, Tom Lord wrote:

> "factor of 2" for whom?   Let me try to paint a picture.
>
> 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?

This happens with patches coming from either not main-maintainers or ppl
not using BK. Andrew (and other folks) does not need to resend patches
because it is Linus that pulls from their archive the stuff he's willing
to merge at a given stage. Personally I stopped sending patch to Linus and
I always go to Andrew. When the patch is in Andrew's tree I'm sure that
sooner or later Linus will pull it. Obviously the patch must have a "mean"
and, in theory, should be discussed/approved on lkml before. In some way I
do agree this model, since it removes the load from Linus and introduces a
multiple-layer of trust. Because, let's make it clear, the merge job is
freakin' boring. This being said, I definitely believe that a better model
exist. A model that both leaves Linus the final word on what goes mainline
and at the same time reduces the pain of the merge process. IMHO Linus is
getting more tired with time to do the merge-man and anything that will
relieve him in the process will have a pretty good success. About the
linux kernel development bottleneck, if you look close, nothing major has
been lost along the path. Stuff that did not get merged were likely stuff
that was not worth to be merged. Sort of natural selection thingy ;)




- Davide





reply via email to

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