[ClusterLabs Developers] Reference to private bugzillas in commit messages

[Adam Spiers]

Andrei Borzenkov <arvidjaar at gmail.com> wrote:
>On Tue, Jan 9, 2018 at 11:23 AM, Kristoffer Grönlund
><deceiver.g at gmail.com> wrote:
>> Andrei Borzenkov <arvidjaar at gmail.com> writes:
>>
>>> I wonder what is the policy here.
>>>
>>> commit 7b7521c95d635d8b4cf04f645a6badc1069c6b46
>>> Author: liangxin1300 <XLiang at suse.com>
>>> Date:   Fri Dec 29 15:27:40 2017 +0800
>>>
>>>     fix: ui_resource: Using crm_failcount instead of
>>> crm_attribute(bsc#1074127)
>>>
>>>
>>> Apart from the obvious - how would contributor know what "bsc" is in the
>>> first place and how to check it - attempt to access
>>> https://bugzilla.suse.com/show_bug.cgi?id=1074127 gives
>>>
>>> You are not authorized to access bug #1074127
>>>
>>> Randomly checking other bsc# references gives the same "permissions
>>> denied" result.
>>
>> Hi Andrei,
>>
>> We include those bugzilla references to make it easier for ourselves to
>> connect fixes to bugs in the rpm changelogs (for example). I can
>> honestly say that I don't know if there is a policy or what it is in
>> that case, it was "established practice" when I joined the project. I
>> think Red Hat does the same?
>>
>> You should be able to just create an account in the SUSE bugzilla and
>> then have access to the bug.
>>
>
>I have private account on (open)SUSE bugzilla and I'm denied access to
>these bugs.

Some commercial products in the (open)SUSE bugzilla, presumably
including SUSE Linux Enterprise High Availability, are configured such
that newly submitted bugs default to being private to SUSE employees
only, in order to protect potentially confidential information
submitted by our customers.  My best guess is that the bug referenced
above is one of these bugs which defaulted to private.

However, there is a solution!  Assuming there is no confidential
information in a bug such as log files or other info provided by one
of our customers, any SUSE employee can set any of these bugs as being
visible externally.  And indeed this should be done as much as
possible.

If there *is* confidential information, but it is desired for the fix
to be public (e.g. referenced within a commit message in, say, the
Pacemaker repository), then I would recommend my colleagues to ensure
that there are two bugs: a private one containing the confidential
information, which links to a public one which contains all the
information which can be shared with the upstream FL/OSS project.

Kristoffer, does that approach work for you and your team?