Mailinglist Archive: opensuse-factory (536 mails)

< Previous Next >
Re: [opensuse-factory] Opening private bugs


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

< Previous Next >