linux-kernel - Re: [PATCH 0/90] Post 2.6.21 OMAP update

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] [day] [month] [year] [list]

Date:	Mon, 9 Apr 2007 17:49:57 -0400
From:	Tony Lindgren <tony@...mide.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Roland Dreier <rdreier@...co.com>,
	Randy Dunlap <randy.dunlap@...cle.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/90] Post 2.6.21 OMAP update

Hi,

* Russell King <rmk+lkml@....linux.org.uk> [070406 03:19]:
> On Thu, Apr 05, 2007 at 09:27:13PM +0100, Alan Cox wrote:
> > > Hmm, yeah I'll see if I could group them a bit. The problem there
> > > is that the patch series contains multiple rounds of "add and fix"
> > > cycles. Pretty much all the non-dependant fixes have already been
> > > applied, BTW.
> > 
> > Bear in mind that it doesn't work now, so merging some stuff and being in
> > a "more merged but still not yet a tree to build OMAP from" is not a
> > regression or a problem.
> > 
> > Going back some time the PA-RISC merge occurred over several months until
> > one day it was all there.
> 
> I think Tony's problem is the volume of changes though - I think it is
> fair to say that in 2.6.18 it was fully merged and working.
> 
> Since then, for one reason or another the merge windows got missed (ISTR
> it was triggered due to me not being able to devote the full 14 days to
> kernel work during the 2.6.19 merge window due to going on holiday) which
> has resulted in subsequent merge windows being missed, and therefore the
> number of changes increasing and the problem Tony's now in.
> 
> In that respect, if it no longer "work"s now, it's technically a
> regression.

Yeah, it works, but the current omap code in the mainline kernel is still
mostly at 2.6.18 level like you mentioned.

> Clearly the real solution is for rmk never to go on holiday during a
> merge window, but I don't personally find that acceptable.  Or maybe
> human cloning, but I'm sure there's people here who think that one rmk
> is enough. ;)

Or maybe there should be a two week common code and interface merge
window, then another two weeks for merging board and driver specific
stuff?

That would make it easier to update the board and driver specific
patches to the common code and interface changes first before they
are submitted.

Regards,

Tony
-
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/