linux-kernel - Re: Please pull ACPI updates

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 17 Jul 2008 13:11:59 -0700
From:	"Ray Lee" <ray-lk@...rabbit.org>
To:	"Andi Kleen" <andi@...stfloor.org>
Cc:	"Linus Torvalds" <torvalds@...ux-foundation.org>,
	"Jesse Barnes" <jbarnes@...tuousgeek.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>, torvalds@...uxfoundation.org,
	linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org
Subject: Re: Please pull ACPI updates

On Thu, Jul 17, 2008 at 12:49 PM, Andi Kleen <andi@...stfloor.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?

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

> The completely merged tree is not tested
> well [1] in both cases (unless after some time of course) as far as I can see,
> no difference.
>
> [1] I do some basic testing as in building and test booting on a few
> machines on each merge, so calling it completely untested is not
> true.

Andi, no offense was intended here. I'm just asking you to walk
through a thought experiment with me, okay?

>> 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".

Maybe the merging is trivial in all the cases you've hit so far,
great. What happens when it isn't? That's the larger point here.

>> Your point is
>> the end result is untested either way. The other way to look at it is
>> *how much* untested history ends up in the tree. In Linus' version,
>> just the point from the merge onward is untested. In your version,
>> everything is new.
>
> Sorry I still don't see the difference. AFAIK the only difference
> is that I do the merge vs Linus doing it and that it looks slightly
> different in the history, but apart from that (as in what
> actually ends up in the source tree) it's all the same.

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/