Re: Please pull ACPI updates

From: david
Date: Fri Jul 18 2008 - 02:39:26 EST

On Thu, 17 Jul 2008, Andi Kleen wrote:

Ray Lee wrote:
On Thu, Jul 17, 2008 at 12:49 PM, Andi Kleen <andi@xxxxxxxxxxxxxx> wrote:
Why would you care about the merge and not about the individual patches?
Note that these quilt merges don't have conflicts.

Because sometimes merges are non-trivial. If you roll that merge
conflict resolution back into the original patch, then the patch is
now different. And in all these rebasings, who's to say there won't be
a typo that accidentally changes the original patch that has had more
testing? We'er all human, y'know?

You only focus only on the merges, but I focus on all the other changes too.
The reason I maintain patches in quilt is that it's quite easy to
fix them up.

Besides as a subsystem maintainer the actual conflict points are
very rare because normally people don't change drivers/acpi without
going through me.

It's the difference between having tested patches and an untested
merge, or untested new patches
The patches are as tested individually as they were before. I don't see
how you can call something that was in linux-next for some time and also
in my test tree "untested".

Surely you agree that more testing is better? A rebased patch has had
less testing than the original patch, by definition.

What I don't agree on is that a rebased patch had less testing than
a patch that got merged by someone else (in this case Linus) into
their tree when my tree wasn't at exactly the same point. In both
cases it's a merge and yes it is untested initially, but not less
so in both of the cases.


say you create patch P1 against tree version T1 creating tree T2

you then rebase patch P1 against tree version T5 creating tree T6

people tested tree T2, they didn't test tree T6. while the changes made by patch P1 are still the same, there may be other changes that interact with things (and not nessasarily by chnaging the same area of the code, they may change memory layouts, timing, etc)

when someone is trying to track things down they can no longer recreate the state of tree T2, you've wiped the record of that from history. all they can do is to test version T5 and T6.

the other approach is that you create patch P1 against tree version T1 creating tree T2, this then gets merged with tree version T5 upstream creating tree T6.

now when someone goes to track down a problem they can see all four tree versions, T1, T2, T5, and T6. they can not only test that T5 works but T6 doesn't, but they can test that T2 works as well. They then can immediatly start looking for other interactions that are the result of the merge (and what's different between T1 and T5) rather then focusing just on 'what did patch P1 change'

now, it's also not good to have large areas of non-bisectable trees and bugs with their fixes a lot later, but with distributed testing and development you will never completely eliminate this.

there are things that you can do to minimize that, and using some number of topic branches seems to be one of the big ones (and I'll point you at the other explinations from this thread that have focused on what those are)

David Lang
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at