On Thu, 1 May 2008, Rafael J. Wysocki wrote:

quoted text
> On Thursday, 1 of May 2008, David Miller wrote:
>> From: Ingo Molnar <mingo@elte.hu>
>> Date: Thu, 1 May 2008 00:19:36 +0200
>>
>>> The same goes in the other direction as well - you were just hit by
>>> scheduler tree related regressions that were only triggered on your
>>> 128-way sparc64, but not on our 64way x86 and smaller boxes.
>>
>> You keep saying this over and over again, but the powerpc folks hit
>> this stuff too.
>
> Well, I think that some changes need some wider testing anyway.
>
> They may be correct from the author's point of view and even from the knowledge
> and point of view of the maintainer who takes them into his tree.  That's
> because no one knows everything and it'll always be like this.

I think this is a very important point to keep in mind

quoted text
> Still, with the current process such "suspicious" changes go in as parts of
> large series of commits and need to be "rediscovered" by the affected testers
> with the help of bisection.  Moreover, many changes of this kind may go in from
> many different sources at the same time and that's really problematic.

git makes it easy to have many branches that get merged upstream, would it 
really help much if these changes were initially done as seperate branches 
and then merged in?

if so there are two ways to do this

have Ingo (and others) create a small forest of branches that get merged 
into linux-next

have Ingo (and others) create a small forest of branches that get merged 
into one 'please pull' branch that gets merged into linux-next

the second has the advantage that merge conflicts between the different 
branches will be resolved before they go upstream, and there's less work 
to be done upstream (as the upstream doesn't need to keep adding branches 
to pull)

the first may have an advantage in terms of making the different branches 
more visable.

quoted text
> In fact, so many changes go in at a time during a merge window, that we often
> can't really say which of them causes the breakage observed by testers and
> bisection, that IMO should really be a last-resort tool, is used on the main
> debugging techinque.

there are always going to be cases where the problem can only be found by 
bisecting it, but I agree that there seems to be a little too much 
reliance on bisecting (but that was a heated topic a few weeks ago, let's 
not re-hash it now)

David Lang
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/