On 09/01/18 10:35 +0000, Adam Spiers wrote: > Andrei Borzenkov <arvidj...@gmail.com> wrote: >> On Tue, Jan 9, 2018 at 11:23 AM, Kristoffer Grönlund >> <deceive...@gmail.com> wrote: >>> Andrei Borzenkov <arvidj...@gmail.com> writes: >>> >>>> I wonder what is the policy here. >>>> >>>> commit 7b7521c95d635d8b4cf04f645a6badc1069c6b46 >>>> Author: liangxin1300 <xli...@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)
pgpjzCR_jeun_.pgp
Description: PGP signature
_______________________________________________ Developers mailing list Developers@clusterlabs.org http://lists.clusterlabs.org/mailman/listinfo/developers
