Date:	Mon, 11 Feb 2008 21:53:12 -0800
From:	Greg KH <greg@...ah.com>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	Stephen Rothwell <sfr@...b.auug.org.au>,
	LKML <linux-kernel@...r.kernel.org>, linux-next@...r.kernel.org,
	linux-arch@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus <torvalds@...ux-foundation.org>
Subject: Re: Announce: Linux-next (Or Andrew's dream  :-))

On Mon, Feb 11, 2008 at 09:17:51PM -0800, Arjan van de Ven wrote:
> On Mon, 11 Feb 2008 20:43:14 -0800
> Greg KH <greg@...ah.com> wrote:
> 
> > On Mon, Feb 11, 2008 at 08:31:46PM -0800, Arjan van de Ven wrote:
> > > On Mon, 11 Feb 2008 20:21:33 -0800
> > > Greg KH <greg@...ah.com> wrote:
> > > 
> > > 
> > > > > The maintainer will be notified.  I hope to provide some clue
> > > > > as to what the conflict is with, but probably not initially.
> > > > > 
> > > > > I will attempt to build the tree between each merge (and a
> > > > > failed build will again cause the offending tree to be dropped).
> > > > 
> > > > This is going to get really interesting, especially when (not if)
> > > > we do more global api changes.  Look at the last round of kobject
> > > > changes. That touched a lot of different places, and other trees
> > > > ended up not building because of it, because I changed apis and
> > > > they had added new code based on the old apis.
> > > > 
> > > > I think the only way to fix this is not going to just "drop the
> > > > tree" like you are suggesting, but to let both people know (the
> > > > person who caused the change, and the person who's tree broke
> > > > after the merge), and then either add a "fixup patch" for the
> > > > build like Andrew has been doing, or disabling something from the
> > > > build section.
> > > > 
> > > 
> > > in my experience, the only chance you have is doing API changes as
> > > first in the set of changes, and then hoping (making) all other
> > > trees use the new APIs. Any other order just turns into an
> > > impossible mismash.
> > 
> > I agree, and that's what I do.
> > 
> > The problem is, the API change is still in my tree.  So, if for
> > example, the IB tree goes and adds some new functionality before my
> > API changes have landed, they need to use the "old" API in order for
> > them to be able to test and build things on their own.  Then, when
> > the -next tree merges everything together, the IB tree breaks the
> > build, not my driver tree.
> > 
> > It's those "who goes first" type things that end up being the cause
> > of a lot of Andrew's headaches I think :)
> > 
> 
> this is why you need specific trees for just the API change, and these
> need to EXPLICITLY go first before EVERYTHING ELSE. Yes this needs a
> bit of coordination, but it's the only way.

Even then, it will not work.

Again, Roland isn't going to want to always pull in my driver tree just
to build his tree.  He wants to, and needs to do his own development
effort.

But when we merge them together, there would be problems.

So, you can't just "drop" the IB tree.
You can't just "drip" my tree.

Where do you "fix this up" at?  I can send a patch for the IB tree, but
Roland can't put it in his tree, and I can't put it in my tree, it needs
to go _after_ both of our trees.

That's what -mm has been able to handle so far, and that needs to also
work with -next.

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/

Powered by blists - more mailing lists