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]

Date:	Mon, 11 Feb 2008 20:43:14 -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 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 :)

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/