From: Thomas Gleixner <tglx@linutronix.de>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Theodore Tso <tytso@mit.edu>, LKML <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@elte.hu>, "H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [GIT pull] x86 fixes for 2.6.26
Date: Sat, 17 May 2008 22:37:16 +0200 (CEST) [thread overview]
Message-ID: <alpine.LFD.1.10.0805172022180.14337@apollo.tec.linutronix.de> (raw)
In-Reply-To: <alpine.LFD.1.10.0805170944000.3020@woody.linux-foundation.org>
Linus,
On Sat, 17 May 2008, Linus Torvalds wrote:
> and in that sense they look very much non-managerial. But those ~200
> commits are still just two hundred out of 1900 commits total! We *need*
> managers, not just grunts. And I can well imagine how stressful it is to
> not just do the two hundred commits, but also try to orchestrate the other
> ~1700 ones.
Hey, I can confirm that. :)
One of the main obstacles of going a more managerial way is that x86
is not yet in a shape which allows us to have real independent topic
branches. The other one is the way we worked for 5 years in
maintaining the preempt-rt patch and the related subprojects which
trickled slowly into mainline. The second obstacle is the one which is
easier to overcome.
The work which was started by the x86 merger is still in progress and
there is aside of the obvious "merge the two _32/_64 versions" a lot
of work necessary to distangle stuff which is intermingled across the
arch/x86 code base for historic reason.
The balancing act between cleaning up these problems and at the same
time not stalling further development completely is what causes quite
a lot of work and in consequence the headaches with our repository
management.
We are not yet at a point where we can rely on a probabilistic non
conflict of e.g. mcheck changes with boot process modifications.
We made pretty good progress to get there, but it would be naive to
say that we are ready for a pure topic related reliance on downstream
developers, which you can observe for example in networking. And
networking did not switch into this mode from one day to the other
either and has the luxory of a rather clean code base which makes it
easy to have clearly separated and (most of the time) independent
topic branches.
I really want to emphasise that the developers who were confronted by
us with the request to clean up stuff _before_ adding new features
were very cooperative and are responsible for the majority of the 1900
commits which we juggled into shape. If you have a close look at the
nature of the commits which were done by Ingo and me, you'll notice
that they are often just the fixup of the fallout of this patch
flood. Honestly, I did not imagine that the uptake of the new x86 tree
would be so huge.
We know that we need to adjust our workflow and trim it into the
lazy^Wmanagerial direction, but this needs some time to establish the
"independent" sub topics and find out those downstream developers who
are willing and capable to do their own topic. This is something which
does not happen overnight, but you are right that providing a stable
base to work on and an append-only forest of topic trees/branches is
definitely helpful.
Thanks,
tglx
next prev parent reply other threads:[~2008-05-17 20:38 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-16 22:38 Thomas Gleixner
2008-05-16 22:47 ` Linus Torvalds
2008-05-16 22:51 ` Linus Torvalds
2008-05-16 23:44 ` Thomas Gleixner
2008-05-17 0:03 ` Linus Torvalds
2008-05-17 0:28 ` David Miller
2008-05-17 1:38 ` Linus Torvalds
2008-05-17 19:39 ` Ingo Molnar
2008-05-17 20:00 ` Linus Torvalds
2008-05-17 21:02 ` Thomas Gleixner
2008-05-17 21:36 ` Linus Torvalds
2008-05-17 1:57 ` Theodore Tso
2008-05-17 3:19 ` Linus Torvalds
2008-05-17 14:58 ` Theodore Tso
2008-05-17 17:05 ` Linus Torvalds
2008-05-17 20:37 ` Thomas Gleixner [this message]
2008-05-17 20:26 ` Junio C Hamano
2008-05-17 22:45 ` Jesper Juhl
2008-05-18 0:35 ` Linus Torvalds
2008-05-18 2:22 ` Stephen Rothwell
2008-05-18 22:09 ` Jesper Juhl
2008-05-18 22:26 ` Linus Torvalds
2008-05-20 0:01 ` Jesper Juhl
2008-05-23 21:49 Thomas Gleixner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LFD.1.10.0805172022180.14337@apollo.tec.linutronix.de \
--to=tglx@linutronix.de \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=torvalds@linux-foundation.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®