Mailinglist Archive: opensuse-factory (536 mails)

< Previous Next >
Re: [opensuse-factory] Opening private bugs
On 29 May 2018 at 05:43, Basil Chupin <blchupin@xxxxxxxxxxxx> wrote:
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

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

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

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@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

< Previous Next >