On 07/02/2011 03:45 PM, James Bottomley wrote:
Look, this tree is unacceptable because A. It's not bisectable. This is what happens when I try a bisection:
[..]
make[1]: *** [drivers/scsi/isci/init.o] Error 1
This was inadvertent, but breakage is breakage.
And B. It's got contaminated history like this:
This was on purpose. We were in the position of stabilizing / validating the driver while carrying out the cleanups. To minimize back merges I duplicated upstream fixes/enabling in these instances. If this is de-facto unacceptable I will adjust my tree management going forward. But I don't believe it is given occasions where two maintainers take the same patch through their respective trees.
I need clean history and a bisectable tree ... By Sunday, since this has to be in linux-next before the next kernel release, which will likely be Monday.
I certainly can rebase this to address the compile breakage. Although this does throw away old commit ids which have seen validation both inside and outside of Intel, but that's unavoidable at this point.
The value I see in maintaining the history (even with some re-written ids) is:
1/ The history is available in mainline and not a side tree. Care went into the commit changelogs. They provide driver documentation and contain notes about future cleanups and improvements.
2/ Code reviewers are credited with Reported-by tags for the commits they generated.
3/ The history is instructive of the dangers of OS abstraction drivers.
Since the tree is huge, I don't think this is fixable in the timescale, so just a single patch will do ... I can construct that, but I need the change log from you, please.
I can go either way, but my preference is a rebase to clean up the bisection.
-- Dan -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
