On 29 May 2018 at 05:43, Basil Chupin
On 29/05/18 06:40, Carlos E. R. wrote:
On 2018-05-28 19:31, Anton Aylward wrote:
On 28/05/18 12:12 PM, Simon Lees wrote:
.... or if a community member would like to make changes to a certain package and are wondering why a change was made in a certain way.
That doesn't sound a like "bug report' to me but the sort of question that might be asked on the factory-, application specific or even main lists.
He refers to reading in the changelist, for instance, that "we changed this because of bug #YYYYY", then finding he can not read #YYYYY because it is private, and thus not knowing what to do with the package on the openSUSE side.
Yes, it could be asked on the factory mail list, and in fact it has been done, but with a separate mail list the limited number of volunteers can see the request easily.
I have read what Simon said (no pun intended) and what others wrote in this thread.
I am confused.
There is the facility for openSuSE (oS) users to report/submit bugs using Bugzilla (whatever). And from what I have read so far, there are cases where the oS user finds out that the bug has either already been submitted or even possibly solved because it concerned the commercial product SUSE/SLE and, therefore, the oS user is unable to see the discussion which occurred or is occurring re the solution to this bug because of customer confidentiality concerns.
So what is now proposed is that after the oS user has gone to Bugzilla and tried to submit a bug report and came across the confidentiality hurdle s/he now will have to write a bug report in this new proposed mail list, opensuse-bugshare@opensuse.org, at which time some SUSE employee with the appropriate security clearance will read the post, analyse it, look for a similar report in the Bugzilla where it is flagged as confidential, read thru that Bugzilla report and try, if it is deemed appropriate, to condense that report into a msg which is to be the response to the oS user who posted his/her bug report in this new mail list.
I have a feeling that I may have misrepresented the actual process of what is being proposed with this new mail list, but the only information I have is what I read so far in this thread.
Now, another aspect of this is that the Linux distro we are using is supposed to be FOSS but this new mail list is based on the confidentiality of customer/SUSE/SLE relationship so the element of "proprietary" is introduced; however, once the bug has been resolved the "fix" is, I am assuming, released for the whole world to see and to apply because SUSE/SLE is FOSS.
The "spanner in the works", if I may call it that, is the confidentiality aspect of bugs concerning SUSE/SLE and because of this it is deemed necessary to have this new mail list.
So why not fix the problem at its 'core'? Why do the bugs reported reported re SUSE/SLE have to be "confidential"? Of course I have no idea what such reports contain but if they contain identifying info. about the organisation which submitted the bug then why not encode the name, for example. If one looks at the mail list archives, the e-mail addresses of posters is replaced with 'XXXXX' so why not do same/similar with bug reports re SUSE/SLE?
What I am suggesting is to 'nip' the problem at the 'bud' stage by having the "bug fixer" (sorry for this crude wording, no offence meant :-)) who first gets to solve the bug do the sanitising of the report so that even oS users can follow the way the bug was/is being solved rather than have another, additional, SUSE employee possibly have to wade thru screenfulls of words to be able to summarise that original report and then write that summary as a response to the oS user in opensuse-bugshare@opensuse.org.
But wait! This cannot be right because the oS user cannot subscribe to this new list -- s/he can only post there. So, how...?
I think it might help to explain a common difference between most SLE bugs and most openSUSE bugs Most openSUSE bugs are filed by openSUSE users and contributors, and typically contain 2 bits of information - "What happened", and "what was expected to happen". A good bug report will also include logs from the system in question. If we're lucky, an exceptionally good openSUSE bug report might also include some kind of description of the "Impact" the bug has on the user in question ie. "How this makes my life harder" The user/contributor is therefore in control and wholly responsible for the public release of any and all information provided. A SLE bug is typically filed by a member of SUSE's support organisation, not filed by SUSE's customers. It will almost always include logs sent to SUSE in confidence. SUSE always recommend that the customer sanitise any logs before sending them but there is always the chance for personal or security sensitive information to be lurking in there. A SLE bug report going through SUSE's support organisation _WILL_ always include a details of the customer, and an assessment of the impact the bug is having on the customer. This may even go so far to attempt to quantify the financial impact the bug could be having on the customer. This is all very important to help SUSE prioritise and professionally address such bugs, but also not the sort of information that SUSE have any right what so ever in releasing to the public. There are also the cases where SUSE partners are often working on new features and functionality under a non-disclosure agreement before the source is made available. Bugs related to such partnering are obviously also not suitable for public consumption, and may even be more heavily restricted within SUSE. And then there are security incidents under embargo, which obviously are private and have to remain so until the embargo is lifted. These are so private that most SUSE employees can't even see them. There are cases where this is not the case - During SLE 15 development, before SLE 15 release, there are obviously less customer bugs (but more of the partner examples). There is even one (VERY EMBARRASSING) example where yours truly reported a bug against SLE, therefore it was private, but as the bug was further investigated the solution and the largest impact was seen in Tumbleweed first. This led to someone emailing me asking for info about what I was changing (because I didn't exactly write the most descriptive changelog entry to one of my submissions), and it really brought home to me the negative side effects of the status quo. In that case I copied the bug to Tumbleweed and although that might be argued to be somewhat redundant (as the bug was already fixed and it was in essence a DUPLICATE from day 1), it does mean the information as to why I changed what I did is now clearly available. SUSE is committed to helping find a solution to these problems, but given the highly sensitive nature of the data involved, this isn't something anyone can expect SUSE to change overnight. SUSE will not play fast and loose with sensitive customer and partner data. I think this is to be respected and praised, even though it is obviously a problem for collaboration with openSUSE. But, SUSE employees who also contribute to openSUSE have been told we can selectively open and/or share details of private SLE bugs as long as we take great care to ensure the sensitive data like described above is not made public. By having this new "send-only" mailinglist, monitored by SUSE-employeed volunteers, we now have one, easy to remember, place for openSUSE contributors to go when they are impacted by the lack of information about a bug. It is not a mailinglist for discussion, just a simple way of reaching out for help to a whole team at once. This should be far more efficient than the previous approach of "just find the nearest SUSE-employeed volunteer and ask them nicely". It also means we should be able to start drawing a more comprehensive picture of just how much of a problem these SLE private bugs are for openSUSE really. Maybe we will find common trends of the sort of bugs who's private state really get in openSUSE's way, and maybe that will help find an easier solution. This is only meant to be a stop gap - a short term solution to help make it easier for the community immediately and help us figure out the best long term solution going forward -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org