linux-kernel - Re: -mm merge plans for 2.6.21

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:	Fri, 9 Feb 2007 11:55:40 +1100
From:	Paul Mackerras <paulus@...ba.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Kyle McMartin <kyle@...artin.ca>, linux-kernel@...r.kernel.org
Subject: Re: -mm merge plans for 2.6.21

Andrew Morton writes:

> Once a subsystem has a subsystem tree (git or quilt) I basically never
> merge anything which belongs to that tree.  It's always
> 
> 	originator->mm->subsystemtree->Linus
> 
> If the subsystem tree maintainer wants to tell me "I can't be bothered
> setting up a git pull for that, please merge it for me" then that's fine.
> 
> But unless I'm told that, or unless the maintainer is vacationing or totally
> asleep or unless the fix has some sufficiently high obviousness*importance product,
> I'll just keep buffering it up.  

What about the sort of thing that crosses all archs?  For example, the
local_t changes?  Particularly in the case where the change has to be
made in generic code and in all archs at the same time, it makes sense
to me for you to send the whole batch to Linus at the same time,
rather than individual arch maintainers all sending their bit at
varying times.

Paul.
-
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/