Re: Please pull ACPI updates

[david]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/