[ClusterLabs Developers] Reference to private bugzillas in commit messages

[Jan Pokorný]

On 09/01/18 10:35 +0000, Adam Spiers wrote:
> 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.
>>> 
>>> 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.

Well, in fact there is no such official policy around this, but
I tried to change that in past:

  https://github.com/ClusterLabs/pacemaker/pull/1119

as this no-open-access hubris (seconded by related
no-change-selfcontainment) disturbs me _a lot_ in the context
of _free_ (as in freedom) software.  Just think about it.

>>> I think Red Hat does the same?

The above reference gives you an answer that this camp is also not
guilt-free here (https://github.com/ClusterLabs/pacemaker/pull/887).

>>> You should be able to just create an account in the SUSE bugzilla and
>>> then have access to the bug.

What's the point of requiring the audience to be registered, then?

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

AFAIK, the privacy can be set on particular comment/attachment basis
in Bugzilla instances (ok, with the associated risk added that something
will leak unintentionally)...

> any SUSE employee can set any of these bugs as being visible
> externally.  And indeed this should be done as much as possible.

... however, this is a moot discussion we would be better off avoiding
in the first place as:

1. the changes tracked in the repo would preferably be self-contained
   as mentioned

   - on random commit access, the change should be comprehensible just
     by the means of code + in-code comments + commit message, without
     any reliance on external tracker or on out-of-repo PR comments
     (e.g., I don't understand why the explanation did not go into
     the commit itself in case of
     https://github.com/ClusterLabs/pacemaker/pull/1402) -- come on
     people, when the code base is to stand the test of time, is it
     more likely that the context survives in the proprietary
     free-of-charge service without massive replication, or in the
     bits being indivisible part of the distributed repo?

2. if the bug identifier is absolutely necessary for some reason,
   ClusterLabs host the Bugzilla instance at
   https://bugs.clusterlabs.org/

   - items in other trackers could be cross-linked from there

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

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.

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

-- 
Jan (Poki)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/developers/attachments/20180109/8ed73f09/attachment-0004.sig>