On 29/05/18 01:19, Bruno Friedmann wrote:
On lundi, 28 mai 2018 16.46:43 h CEST Simon Lees wrote:
Hi all,
As many people are aware the sharing of code between Leap and SLE combined with SUSE's "Factory First" policy has often lead to the need for openSUSE community members needing to read bugs that have been marked as private because they were originally created for SLE.
For some time SUSE has been happy for SUSE employee's to review and disclose the contents of private bugs as long as we don't share any customer information. We can either do this by making any such confidential info private in the bug should it exist then making the bug public or in other cases providing a summary of the bug and discussion, even if in some cases all we can say is "this is a private customer feature"
In order to make this process slightly easier and more formal during las weeks board discussion the board decided to the mailing list opensuse-bugshare@opensuse.org where community members can send an email then a volunteer SUSE employee can read the bug report then either open it or provide a summary.
Currently this is a short term solution, SUSE Engineering understands this problem and will be working toward a better solution longer term.
If you are a SUSE employee and you are happy to help with this process shoot me an email and i'll get you subscribed to the list.
Cheers
Hi Simon, nice to read that some improvements will be done on that subject.
Now if I read correctly your mail, it seems I will have to open a request on a mailing list for each bnc or bsc that is not public ?
I hope, there's a damn tool that will do that for each reference found in mail new TW snapshot.
A manual double input, is just killing our sparse contribution time no ?
Unfortunately currently opening up every bug listed going through tumbleweed and leap is not feasible as bugs need to be manually reviewed. In the future we would rather see a system / workflow where bugs only stay private if they need to or in many current cases the majority of bugs we are talking about were raised by SUSE engineers rather then customers and could likely just be public anyway if the systems / workflows in place within SUSE were modified. As I said in my original email SUSE Engineering is currently looking into how they can do this but at the same time stay within there various requirements that ensure customer information stays private. The use case for this list is less about opening everything and more about opening things were there is a real need, the highest priority of such cases are when packages are co maintained between SUSE employees and community members 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. Or the case that many members of the openSUSE review team which reviews all the packages going into factory are not SUSE employee's and sometimes when they are reviewing a package it can be useful to see why a change was made for a certain reason. Sometimes there are also bugs which contain alot of community interest that we can also make public but unfortunately doing everything so openSUSE users can see every part of every change is not yet feasible and even still in the future won't always be possible. Our aim with this change is primarily to make it easier for community contributors to work alongside SUSE employee's and as I said this is just a starting point in making life easier rather then the final solution. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B