Ray Lee wrote:
quoted text
> On Thu, Jul 17, 2008 at 12:49 PM, Andi Kleen <andi@firstfloor.org> 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.

quoted text
>>> 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.


quoted text
>>> and an untested merge.
>> So when I do a rebase versus Linus doing a merge (end result
>> the same code base) how is that more untested?
> 
> If you rebase, you're creating new patches that have less testing than
> the originals. You're also tossing away a history of the changesets,
> which means that any external testers can no longer point to a
> historical potion of a tree and say "I tested that".

They can't do that anyways because I maintain my patches in quilt.

So there's no canonical such tree. Besides I don't consider
it very likely that testers just test my tree (except me myself).

Normally testers either test individual patches (e.g. something that is posted
as a test patch in bugzilla) or completely merged trees like -mm
or linux-next. I am not aware of a significant test population
that just pulls ACPI trees only. It really wouldn't make much sense
either, testers should really test multiple subsystems in parallel,
otherwise testing wouldn't really scale.

quoted text
> Uhm, the history is the whole point of using source control and git.
> If all we cared about was the end result and not the history, there'd
> be little point to using source management other than to help speed
> merging.

Sorry, but that's not really how it works.

Normally the rule is (and Linus used to encourage that)
is that when something hits his tree it shouldn't have the complete development
history.

Because normally for non trivial changes you would end up with sequences
like

initial change
fix some problems
fix more problems found during testing
make it compile in configuration foo
fix a typo ...
etc.

[just take a look at some of the version numbers in larger patch series.
Often they easily hit double digits. Or sometimes the fix-fix-fix-fix-foo
patches in -mm. Of course Andrew tends to clean that up before more]


Needless to say such a conglomeration is not bisectable. If your
bisect ends in the middle it might not compile or crash in trivial
ways etc.

Or as a maintainer submitter sends patch version A
Then someone finds a problem.
Review finds problems.
Submitter sends patch version A v2
repeat a few times

Or again if you asked to keep the whole history the final merge would have

merge A
revert A
merge Av2
revert Av2
merge Av3
revert Av3
...

Now in a ideal world the person doing the change would get everything
right the first time, but we're not living in a ideal world.

But when something goes into the Linus tree it just supposed to be a single
patch that does this change cleanly without all these additional development steps.

Anyways I'm dropping out of this discussion now because I think I made
all my points already multiples times.

-Andi

--
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/