[ClusterLabs Developers] Reference to private bugzillas in commit messages

Ken Gaillot kgaillot at redhat.com
Tue Jan 9 15:56:36 UTC 2018


On Tue, 2018-01-09 at 15:59 +0100, Kristoffer Grönlund wrote:
> Jan Pokorný <jpokorny at redhat.com> writes:
> > Proper problem statement in the commit message accompanying the fix
> > would alleviate these sorts of redundancies, and would lead to
> > improvements on the non-code/soft-skills aspects of the
> > contributions,
> > IMHO.
> > 
> 
> I totally agree that linking to non-public information is somewhat
> problematic for an ostensibly open project. But practically speaking,
> it's very convenient to be able to include that kind of link ;)
> 
> So I'm a bit torn. I would say that we should definitely reject
> patches
> that reference a bug somewhere and does not fully describe the
> problem
> it is solving or the solution included.
> 
> But then on the other hand, once the commit message does contain all
> the
> relevant details, having a reference to aid some internal book-
> keeping
> doesn't seem like such a harmful thing either.

I don't think references to non-public information are inherently
problematic. They can provide essential context as to *why* a change
was made that often becomes relevant in future development. I'd love it
if all our past commits were tagged with bug reports; that would make
me much more confident when changing code. (That said, I usually tag my
own commits only with ClusterLabs BZs.)

As long as the commit message is sufficiently descriptive, the bug
report reference merely provides additional context.

Bug fixes are often accompanied by a regression test, which serves as
an open summary of the bug case.

In a perfect world, we'd all open ClusterLabs bug reports for each
downstream bug report to have an open reference, but in the real world,
that time is better spent on development than paperwork.

The acronyms, like any other, you just have to pick up over time with
experience. I'll add the ones I know to the Pacemaker Development
document, which are:

  LFBZ - old Linux Foundation bugzilla for the Linux-HA project - https
://developerbugs.linuxfoundation.org/buglist.cgi?product=Pacemaker

  CLBZ - ClusterLabs bugzilla - https://bugs.clusterlabs.org/

  RHBZ - Red Hat bugzilla - https://bugzilla.redhat.com/

  BSC - SuSE bugzilla - https://bugzilla.suse.com/index.cgi

Sometimes you'll see bz without anything more specific, which is
usually LFBZ or CLBZ depending on when it was written.
-- 
Ken Gaillot <kgaillot at redhat.com>




More information about the Developers mailing list