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.
Andi,
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-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
