[meta-intel] [fido][PATCH v2 2/2] meta-crystalforest: qat makefile patches

[Saul Wold]

On 07/08/2015 10:46 PM, Ong, Boon Leong wrote:
>> -----Original Message-----
>> From: Saul Wold [mailto:sgw at linux.intel.com]
>> Sent: Thursday, July 9, 2015 1:29 PM
>> To: Ong, Boon Leong
>> Cc: Mittal, AnujX; meta-intel at yoctoproject.org
>> Subject: Re: [meta-intel] [fido][PATCH v2 2/2] meta-crystalforest: qat makefile
>> patches
>>
>> On 07/08/2015 03:35 PM, Ong, Boon Leong wrote:
>>>>> I do think that 2/2 --> 1/2 and 1/2 -> 2/2 in this patch-series to
>>>>> avoid partially update the patchseries and have build issue.
>>>>>
>>>> That would have been one option, but since this was a new recipe and
>>>> the patches are required to start with I would prefer to see them as
>>>> one patch, future changes could such as improving or modifying a
>>>> given patch or part of the recipe should be individual patches as they they are
>> incremental changes to a given patch.
>>>
>>> Got it. If you find issue in the DPDK series, I will re-format the
>>> patch-series to follow the above principles for the first time
>>> submission of new recipe. Thanks for guidance above.
>>>
>>
>> I think I understand what you are trying to do with the dpdk series, I started
>> looking at it today and began wondering if it would not have been easier to have
>> them collapsed, but I understand that you cherry-picked and then updated, and
>> introduced the patches before the final recipes.
>
> I opined that a cherry-picked should be a clean pick with no content change unless conflict
> changes is required. Followed by another commit to fix the fido build issue to be explicitly.
>
>> So, when I saw and understood your intent there, having multiple smaller ones is
>> OK.  I honestly reviewed the finished product since that was easier than trying to
>> decipher the individual patches though!
> Ya, I understand the difficulty there because collapsing some patches may lost the
> evolution of the dpdk series. I may collapse them in the 2nd series (if required), just want
> to make sure that it is made easier for your review and merge. Sorry but thank you for your time
> and effort!
>
> On separate matter, Anuj just shared with me his zlib-qat patch that cherry-picked patch from dizzy into fido.
> He took the path of "in the same cherry-picked commit, he swapped a patch that is zlib-qat is not building
> on fido, i.e. doing a patch content changes on cherry-picked patch."
> I was not really in favor of such process because I like cherry-picked patch to be as in-tact as possible as the source of it.
> This gives assurance that there is additional hidden ingredients added mid-way that I am not aware of.
>

So your saying that the cherry-picked version is broken?

> What is your preference here? We will try to follow what suits your best.
> A) clean cherry-picked then a commit to fix build error
> B) a single commit that has both commits in (A).
>
I think that cherry-picking the patch and then having the minimal change 
to make it work should be 1 patch, this can be done with an interactive 
rebase and a squash, but ensure that the commit message reflects this 
change.

I think having working patches is important.

Sau!


> Thanks
>
>
>
>
>
>