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

[Ong, Boon Leong]

>-----Original Message-----
>From: Saul Wold [mailto:sgw at linux.intel.com]
>Sent: Thursday, July 9, 2015 11:00 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 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?
Ya. It is broken when Anuj pick from dizzy to fido.


>
>> 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.
>
Thanks for the advice. Much appreciated. I will pay attention on this.