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
>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

Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to