[Freeipa-devel] Linking tickets in the commit messages

[Petr Spacek]

On 17.9.2015 17:42, Alexander Bokovoy wrote:
> 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.

Well, I would say that it is our failure to use Trac :-)

Nothing prevents us from using a separate field for tracking branches in which
the patch landed, or something even more precise.

E.g. bind-dyndb-ldap Trac has field 'fixedby' which contains hashes of commits
fixing given ticket. Nothing prevents me from putting multiple hashes from
multiple branches to that field, and I do that.

Then, git describe --contains <hash> nicely shows which released version (tag)
contains which commit etc.


The main question is if it worth the effort because bookkeeping may easily
consume more resources than the benefit, especially for small fixes.

Should we create tickets for typo fix or other non-essential change just
because it is applicable to all branches? I do not think so.

I very much agree with Jan Pazdiora's note from other part of the thread:
> But if the issue is so small that noone really thought about filing
> it before, what's the purpose of creating one? We don't seem to
> suffer from the lack of tickets.

-- 
Petr^2 Spacek