linux-kernel - Re: [GIT pull] x86 fixes for 2.6.26

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.1.10.0805172022180.14337@apollo.tec.linutronix.de>
Date:	Sat, 17 May 2008 22:37:16 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
cc:	Theodore Tso <tytso@....edu>, LKML <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>
Subject: Re: [GIT pull] x86 fixes for 2.6.26

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