Re: [GIT PULL] isci: sas controller driver for 3.0

[Dan Williams <dan.j.williams@intel.com>]

On 07/02/2011 10:16 PM, James Bottomley wrote:
> On Sat, 2011-07-02 at 19:43 -0700, Dan Williams wrote:
>> 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.
>
> That's fine for a development tree.  When you submit a series of
> patches, whether directly or via a git tree, they have to be bisectable.
> This isn't negotiable because any old user has to be able to perform a
> bisection.
>
> This is why most submissions tend to be patches rather than git trees.
> To submit a git tree, you really have to prove that you knew the rules
> when you created and ran it (like no bisectability breaks etc.)

Yup, knew it, blew it.

>>> 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.
>
> Yes, it is.
>
>>    But I don't believe it is given occasions where two maintainers take
>> the same patch through their respective trees.
>
> These aren't the same patches applied by different maintainers; it's a
> cherry pick backport which shouldn't be there.

Ok, should have handled these with backmerges then, but these won't be 
there in the rebased tree.

[..]
> The internal intel history is completely irrelevant.  I can see value to
> maintaining the commit history after publication because several
> non-intel people worked on it and it's nice to credit them.
>

Ok, everything prior to the first publicly available driver will be 
squashed.

>>> 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.
>
> I just stopped at the first failure ... please ensure that there aren't
> any more ... as in test every bisection point in the tree, don't just
> squash the commit I've flagged as failing.
>
> The fact that there is a bisection failure tends to indicate you haven't
> been careful to check each commit in the tree ... which does make it
> suspect and will mean every commit in the reconstituted tree needs
> checking for bisectability.
>

Will verify each commit.

--
Dan