[Freeipa-devel] Proposal to have spec changes as a separate patch

[Martin Kosek]

On 07/18/2013 02:01 PM, Alexander Bokovoy wrote:
> On Thu, 18 Jul 2013, Petr Viktorin wrote:
>> On 07/18/2013 10:10 AM, Alexander Bokovoy wrote:
>>> On Thu, 18 Jul 2013, Alexander Bokovoy wrote:
>>>> On Mon, 15 Jul 2013, Ana Krivokapic wrote:
>>>>> Hello,
>>>>>
>>>>> This patch addresses ticket
>>>>> https://fedorahosted.org/freeipa/ticket/3652.
>>>> Could you please rebase it on top of git master?
>>> BTW, I was thinking on it and given that majority of rebases like this
>>> one come due to spec changes, may be we could establishe a practice to
>>> send spec-related changes as a separate patch in a patchset?
>>>
>>> This would allow easily testing the actual code changes since you don't
>>> really need spec changes at that point or could handle it clearer with
>>> pre-installed build dependencies.
>>>
>>>
>>
>> Or you could just set the union merge strategy on the spec file.
>> This is potentially dangerous so only do it if for pushing to master you
>> apply patches in a separate "clean" repository without this setting.
>>
>> Add the following line to .git/info/gitattributes:
>> freeipa.spec.in  merge=union
>>
>> Docs & caveats:
>> https://www.kernel.org/pub/software/scm/git/docs/gitattributes.html#_built_in_merge_drivers
>>
> I would still prefer to have the changes in separate patches in a
> patchset simply because it makes clearer and easier to handle in active
> development.

Hmm, I am personally not convinced - when I just update one Requires, splitting
it to 2 patches seems as an overkill to me...

> 
> When we push commits to the main git tree, we anyway push whole patchset
> as one push operation. As result, anyone who pulls that tree, will get
> consistent patchset -- be it another developer or continuous integration
> machinery. For developers who touch spec files reduced context of the
> changes in a pulled tree will also be helpful.
> 
> Besides that, you anyway will need to do manual adoption after
> merge=union in order to get changelog entries in proper chronological
> order and release numbering.

I am still not sure about the gain of this - unless people provide special
patch with comment for all affected branches, I will have to merge the doc
change manually (+ give higher maintenance effort by splitting the patches again).

To sum it up, I would not personally make this a strict rule unless we find
that current patches with spec comment included are unbearable (so far, they
were not unbearable for me...).

Martin