Re: [patch 0/17] Series to introduce WARN()... a WARN_ON() variant that takes printk arguments

[Ingo Molnar <mingo@elte.hu>]

* Andrew Morton <akpm@linux-foundation.org> wrote:

> > Note that this situation is special: this is a patchset that has 
> > virtually no functionality side-effects, and hence can be done 100% 
> > correctly, i thought the atomic step was the right approach.
> > 
> > For anything semantically meaningful i too would do the spread-out 
> > gradual approach (and i'm presently doing that for a number of 
> > topics).
> > 
> > But if you'd like to do this the spread-out way then sure, and i 
> > will drop this tree. ( if you do that then please import the commits 
> > from tip/core/warn-API, i fixed a couple of of typos in the commit 
> > messages and did some merging and extensions as well. The tree also 
> > passed a fair amount of testing meanwhile as well. )
> > 
> > Anyway, your call.
> 
> Well I haven't got onto processing these patches in detail yet.  An 
> open questions is why the damn thing was resubmitted from scratch when 
> I've already merged it and fixed various rejects and had to fix 
> several bugs in it.  Do those rejects need to be re-fixed?  Were my 
> bugfixes folded back? I haven't looked yet.  I'll need to generate the 
> incremental diff and see what was done.
> 
> But if what you've merged was against mainline then it isn't terribly 
> useful.

i cross-ported it from the linux-next base to -git base and the conflict 
fallout was minimal, well below 5% or so. I.e. the patches change 
long-existent warnings that have not changed in linux-next either.

About 30% of the changes in this patchset affect subsystems that i 
co-maintain, still tip/core/warn-API did a pure, conflict-free git-merge 
when it was applied ontop of all these subsystem trees:

 commit 99eb83efbe2e3c12d26be22a032495ccddb36a2c
 Merge: de67579... c2e0195...
 Author: Ingo Molnar <mingo@elte.hu>
 Date:   Wed Jul 9 12:14:48 2008 +0200

     Merge branch 'core/warn-API'

Hence my suggestion that this should be maintained and forward ported to 
the end of the merge window, in a separate, standalone tree that is -git 
based.

Anyway, no strong feelings, it's your call.

	Ingo