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 21:56:48 -0800
From:	Greg KH <greg@...ah.com>
To:	Stephen Rothwell <sfr@...b.auug.org.au>
Cc:	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 Tue, Feb 12, 2008 at 04:07:04PM +1100, Stephen Rothwell wrote:
> On Mon, 11 Feb 2008 20:21:33 -0800 Greg KH <greg@...ah.com> wrote:
> > 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.
> 
> Right. Except that "drop the tree" will probably only mean for a day or
> so i.e. it will be taken out of the current round but will reappear
> automatically when the conflict/dependency is sorted out.

See my response to Arjan for how this is going to be very difficult to
do, unless you are willing to have patches in -next that are not in any
other tree.

> > As I know I'm going to be changing more driver core apis[1] this week,
> > I'm sure we will get a very good set of examples of this for you to see
> > in action :)
> 
> Excellent!
> 
> However, I am hoping that these global api changes may be introduced in a
> more orderly fashion (some of which is happening already) by creating new
> api's and then switching to them (and them maybe changing the names back
> if necessary).  And, yes, I realise that this is sometimes not possible
> (or at least not worth the extra effort).

It's possible to do in a series of patches, yes, but again, development
happens in parallel, with no one stopping for anyone else, and that's
fine, we work it out when we send stuff to Linus at merge time.

So with that parallel development effort, there are problems like this,
I just want you to be aware of it and plan properly for it, as it is
going to happen...

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/