[ClusterLabs Developers] Reference to private bugzillas in commit messages

[Ken Gaillot]

On Tue, 2018-01-09 at 17:00 +0100, Kai Dupke wrote:
> Hi,
> 
> unfortunately we are not in an ideal world.
> 
> We are all working in an open source environment and on a common
> target
> with making HA reliant, easy to use and better than yesterday. But we
> are not working on a single bench.
> 
> I wonder if the real issue is about missing context for a
> changelog/commit entry, the link to an external information resource,
> or
> the link to a hidden information source?
> 
> > (e.g., I don't understand why the explanation did not go into
> >      the commit itself in case of
> 
> For me this sounds like the issue is missing context in the
> commit/change log and the need to pull another source to understand
> what
> something is about.
> 
> (of course, it is annoying the other source isn't available for
> whatever
> reason).
> 
> I don't see an issue by having a tracking tag (which by my
> non-engineering view it is). But by missing context.
> 
> Bottom line, for me it sounds like demand for more verbal notes to
> commits, so there is no need to access information outside of the
> commit
> itself.
> 
> As said, I'm not a developer anymore, so if it does not fit
> development
> standards, please let me know (privately, so I can learn from it).

I 100% agree with these comments -- referencing non-public information
as additional context, and not providing sufficient detail in commit
messages, are two separate issues. As Adam mentioned, the detail is
important even if the referenced bug report is public.

As a practical matter, it's a lot easier for me to be picky about
commit messages with people who are being paid to contribute to the
project, than with community volunteers who may have very limited time
to spend on it. Usually I'll give first contributions more slack, and
give people pointers for how to do it better in the future, depending
on their apparent skill level / time availability. I'd rather have a
poorly explained bug fix than discourage casual contributors.
-- 
Ken Gaillot <kgaillot at redhat.com>