linux-kernel - Re: Linux 2.6.25-rc8

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]

Date:	Tue, 1 Apr 2008 20:03:45 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Stephen Rothwell <sfr@...b.auug.org.au>
cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Linux 2.6.25-rc8

On Wed, 2 Apr 2008, Stephen Rothwell wrote:
> 
> The downside is that at least some of these were already pending in
> maintainers trees for 2.6.26 (among other changes) and so have now caused
> (unnecessary) merge conflicts.  Is there some reason that these fixes
> can't go through the subsystem trees (especially once we get past rc1 (or
> 2) and people are gearing up for the next merge window)?

I don't think it's necessarily a bad idea to go through subsystem trees, 
but on the other hand I also don't think it should necessarily be a goal 
in itself.

For example, we had a patch-series from Roland McGrath that was apparently 
almost entirely based on the fact that going through (and getting 
sign-off) from all the architecture maintainers for his ptrace changes was 
just painful as hell for him.

At that point, when there is somebody like Roland who knows the rare and 
odd ptrace interfaces, having him jump through hoops just to go through 
"proper channels" is in my opinion just anti-productive (especially since 
I also think the "political" aspect of the problem causes the actual 
technical side of the patches to suffer - because they are more about 
the politics than about the technology).

So at some point, subsystem mainteinance should also be about picking up 
and handling the changes that come the other way. The kernel development 
isn't a strict hierarchy, and shouldn't be - it's more of a network of 
trust.

In other words, there are people I think are generally trusted across most 
maintenance borders. Al, as far as I'm concerned, is one of them.  
Especially sicne he is also one of the few people who clearly not only 
does run sparse but also looks at the code and actually fixes real bugs 
with byte order etc - regardless of where it is (ie he works across 
drivers, filesystems, an arch-specific code)

In other words, I don't think the borders are so tightly drawn, and the 
same way I trust the individual developers who send me patches (and git 
trees) rather than whatever _companies_ they happen to work, I also tend 
to trust individual developers rather than the _subsystem_ that they 
happen to maintain.

Of course, there's often a rather direct mapping between the two, where 
people naturally have the area they work in. But some people cross across 
any particular area, and while that tends to be unusual, that very much 
includes people like Andrew and Al.

In other words, at least to me it's not about "person X maintains file Y". 
It's much more about "I trust person X (perhaps within parameters Z)". And 
I don't think that's even unusual or even really unexpected.

And I think that's how we all work (and how we _should_ work), but 
sometimes people get so used to the fact that some people are fairly 
tightly associated with certain code that they think it's about the 
subsystem, not about the person.

			Linus
--
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/