Andrei Borzenkov <[email protected]> wrote:
On Tue, Jan 9, 2018 at 11:23 AM, Kristoffer Grönlund
<[email protected]> wrote:
Andrei Borzenkov <[email protected]> writes:
I wonder what is the policy here.
commit 7b7521c95d635d8b4cf04f645a6badc1069c6b46
Author: liangxin1300 <[email protected]>
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?
_______________________________________________
Developers mailing list
[email protected]
http://lists.clusterlabs.org/mailman/listinfo/developers
