[Freeipa-devel] Linking tickets in the commit messages

[Alexander Bokovoy]

On Thu, 17 Sep 2015, Rob Crittenden wrote:
>Alexander Bokovoy wrote:
>> On Thu, 17 Sep 2015, Jakub Hrozek wrote:
>>> On Thu, Sep 17, 2015 at 03:55:35PM +0300, Alexander Bokovoy wrote:
>>>> >Speaking as IPA package maitainer in RHEL, I would like to have ticket
>>>> >link in every commit in maintenance branches. If a commit goes to the
>>>> >master branch only, I'm OK with it not having a ticket link. So that's
>>>> >where I would draw the line - if a commit goes into a maintenance
>>>> branch,
>>>> >it is a reasonable piece of work.
>>>> Good suggestion, thanks. We actually have the same with Samba -- *any*
>>>> backport to released branches requires a new bug to be opened and
>>>> mentioned in the commit message.
>>>
>>> Seems reasonable for SSSD as well..
>>>
>>> Two questions:
>>>    1) If you backport from a non-maintenance branch to a maintenance
>>>       branch, do you also move the ticket? IOW, do you also expect the
>>>       list of changes to be visible in track, or do you only care about
>>>       'auditing' of each commit?
>> Samba clones the bug. FreeIPA does add a comment with the hashes
>> referencing the commits.
>>
>>
>>>    2) If another commit (which can be totally unrelated in
>>>       functionality, just touching the same area of code) needs to be
>>>       applied before the one you backport, do you add the ticket URL
>>>       to the prerequisite as well or create a new one?
>> If you have something else applying to a maintenance branch, just do a
>> bug for it. If it is a patch for making the backport more manageable for
>> applying, just have it part of the backport.
>>
>
>I can't quite figure out what problem you're trying to solve here. Why
>not just reference the original ticket in the backported commit? What
>value, except perhaps in ticket reports, does this bring?
It may, perhaps, be irrelevant to current FreeIPA state of integration
with different distributions and products, but in Samba case a version
often lives beyond what is supported by upstream, so a good trail of how
backports landed in a released branch is often reused by various ISVs to
track their own long term product branches. Samba code did undergo large
changes in last ten years to the point that sometimes these backports
are completely separate patchsets on their own, with own life and
original bugs fixes/design decisions might not apply anymore exactly.
Having a bug to record decisions made some time ago specifically to the
branch helps in future when another person comes with a bug due to the
backport -- not so rare, unfortunately, as sometimes an obscure side
effect might change what others are caring about.

I guess it also a sign of a Trac's and bugzilla's failure to allow
attaching a single bug/ticket to multiple releases in a clear way so
that people have to clone bugs to different streams to represent the
same story in different contexts.
-- 
/ Alexander Bokovoy