linux-kernel - Re: Announce: Linux-next (Or Andrew's dream :-))

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: <20080212145739.GB19059@kroah.com>
Date:	Tue, 12 Feb 2008 06:57:39 -0800
From:	Greg KH <greg@...ah.com>
To:	Stephen Rothwell <sfr@...b.auug.org.au>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Theodore Tso <tytso@....edu>,
	Trond Myklebust <trond.myklebust@....uio.no>,
	Arjan van de Ven <arjan@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>, linux-next@...r.kernel.org,
	linux-arch@...r.kernel.org, Linus <torvalds@...ux-foundation.org>
Subject: Re: Announce: Linux-next (Or Andrew's dream  :-))

On Tue, Feb 12, 2008 at 10:57:16PM +1100, Stephen Rothwell wrote:
> On Mon, 11 Feb 2008 22:15:35 -0800 Andrew Morton <akpm@...ux-foundation.org> wrote:
> >
> > Another thing we could do when these things happen is all gang up on Linus
> > and ask him to merge the API change into mainline.  Because often the
> > change can be done in two stages: 1) change the interface then 2) add the code
> > in the callee which _uses_ that changed interface.  Part 1 is an obviously-safe
> > do-nothing change and fixes the merge problems.  Part 2 is at a single site
> > and can be merged in 2.6.x+1.
> 
> I have an alternative (with help from Paul Mackerras).
> 
> We have a branch in linux-next that is stable and only progresses forward
> i.e. is never rebased.  Global API changes/introductions that are of type
> 1 above go into this branch (after appropriate etc).  Fixes to them go in
> as well.  People can base development on this branch.
> 
> But ... they can only really do that *if* we can guarantee that part of
> linux-next will be in Linus' tree very early in the next merge window.
> So here is the had part ...
> 
> We need to ask Linus to promise that he will pull the stable branch from
> linux-next first in the merge window.  For that to happen, I would expect
> that Linus would also review and sign off (or ack) these commits to the
> linux-next tree.
> 
> The rest of linux-next would always be based on the stable part plus
> Linus' current tree.
> 
> Will this fly?

I doubt it.  See David's previous post about constantly rebasing his
tree over the lifetime of development during a -rc series.  I do the
same thing, dropping things in the middle, re-arranging stuff, handling
merge issues that came into Linus's tree, etc.

I wouldn't want to change our current development flow to force such a
thing on Linus, or us right now.

My main point in all of this was just that you are going to have to help
with some of these merges by hand, adding patches to get things to
build, and not just blindly dropping trees when things go wrong, as you
originally stated.  After that, we can continue doing what we have been
doing in the merges with Linus, as that is working very well (see our
rate of change metrics for proof of that.)

thanks,

greg k-h
--
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/