24 Apr
2020
24 Apr
'20
1:08 a.m.
On 4/24/20 8:23 AM, James Mason wrote:
On Fri, 2020-04-24 at 00:01 +0200, Gerald Pfeifer
wrote:
Well generally that is already the case, we normally wont create a
difference between SLE and Leap just to fix a bug we will just fix it in
SLE.
I think the big difference here between SLE and JUMP is the level of
support. JUMP/Leap are provided as is with no warranty, support and
bugfixes are provided on a best effort basis by volunteers whether that
is people in there spare time or companies volunteering there employees
time. Where as SLE customers enter a contract defining that certain
should be fixed within a certain timeframe etc, obviously there needs to
be a way of tracking whether a bug falls in the scope of the contract or
if maybe its expected behavior in some cases etc. Then the time taken to
fix the issue etc and I guess generate reports on how many issues etc.
So obviously the process needs to be somewhat different to handle the
extra info. There are probably also some corner cases where things
aren't SLE bugs but are JUMP bugs due to SLE having some JUMP code paths
that aren't officially supported or could be a bug in a library that
only shows using something from packagehub.
--
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
On Thu 2020-04-23, Stefan Seyfried wrote:
My bad, sorry.
That being said, what would be the difference between a bug on Jump and
a bug on SLE? The SLE package would have to be modified to fix the
binary for Jump.
> - James Even as a big customer, there is no way you can
file a bug for SLE.
Here I was sitting in front of my notebook, genuinely scratching my
head, wondering "What is he talking about?" - until it dawned on
me:
Yes, SUSE customers do not generally have access to Bugzilla for
SUSE
products, betas of SLES being a bit of an exception these days.