On Thu, 2020-04-23 at 11:42 -0700, PGNet Dev wrote:

Hi,

On 4/23/20 11:18 AM, James Mason wrote:

...

...

Trying to get ANY of the updated versions supported on SLE is an uphill battle, at best. While getting a new version in place would be a major challenge, because of the promise of compatiblity, getting problems fixed shouldn't be any more difficult than filing a bugzilla entry, on the SLE product, explaining the bug, and being willing to supply supporting information upon request.

Sure.

*Personally*, I absolutely agree with the *should* be. That hasn't been the experience -- for Base:System core issues, like this systemd 'challenge' as one example.

And, for me, it's NOT SLE *or* Leap. Here they're one, necessarily- intertwined ecosystem; chosen *because* of their similarities & shared stability & strengths, as well as the productive 'tension' due to their somewhat-independence.

Virtually ALL dev & sysdamin here -- where Suse* is involved -- has been on openSUSE/Leap. The 'promise' of the 'closeness' between the two projects has, in theory, been that, in large part, fixed for significant bugs'/brokenness filed against one find their way to the other.

Most frequently, thought not exclusively, here, bugs get filed against openSUSE -- as they're left in the open, engage many of the same persons, etc etc You might want to see annoucement regarding making SUSE Bugzilla Public on opensuse-project@

Do note that the aforementioned "... we can't afford to backport a feature each time an openSUSE user is missing one ..." non-response came from @suse *staff*.

(and, yes, this speaks to many of the same comments folks have been making in the recent/ongoing 'Jump' discussions about 'closeness' etc)

These "we don't wanna" issues re: Core have been going on for years, with increasing concern & effect, as evidenced for us by our large migrations to other platforms. The topics have been raised though $channels, at Summits & Conferences, ... and even by 'just me' on the foss channels.

The only thing that's changed currently from my perspective is that -- finally -- I've bumped into an issue (this systemd biz) that I can't (more or less) trivially OBS-build my way out of. AND, that 15.2/sp2 have, apparently, decided to stick with the old/decrepit version.

As a hobby, there's still runway left (?) for being stubborn.

But for business, it's a dealbreaker. The Nth time you're refused, ignored, etc & told to 'stop whining', 'use something else', 'do it yourself' etc ... you mitigate cost & risk, and just _do_.

-- Best regards Luboš Kocman Release Manager openSUSE Leap SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer

I am not a SLE's customer, but what is https://bugzilla.suse.com/index.cgi for? On 24.04.2020 00:03, Stefan Seyfried wrote:

Even as a big customer, there is no way you can file a bug for SLE.

-- With Best Regards, Andrey Abramov -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On Fri 2020-04-24, Stefan Seyfried wrote:

...

I am not a SLE's customer, but what is https://bugzilla.suse.com/index.cgi for? This is exactly the same bugzilla instance as bugzilla.opensuse.org.

Not exactly. bugzilla.suse.com (bsc) and bugzilla.opensuse.org (boo) share the same database (as you hint at), but feature different front ends instances. Or so I have been told recently. Gerald, who has spent more time on Bugzilla lately then he thought he would - I'll send an update here soon... -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On Thu 2020-04-23, Stefan Seyfried wrote:

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. As a customer with a single subscription you are entitled to file as many Service Requests (including bug reports) as you want, though. ;-) Different terminology, different tools, and a different group (support) fielding those requests which may turn into Bugzilla entries internally. As you point out the customer interaction does not happen via Bugzilla. Gerald PS: There is work in progress looking into opening Bugzilla where possible, and improving bug reporting in the context of Leap is a big focus, too. Stay tuned. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On 4/24/20 8:23 AM, James Mason wrote:

On Fri, 2020-04-24 at 00:01 +0200, Gerald Pfeifer wrote:

...

On Thu 2020-04-23, Stefan Seyfried wrote:

...

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.

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

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 4/24/20 4:07 PM, Axel Braun wrote:

Am 24. April 2020 08:08:55 MESZ schrieb Simon Lees

...

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.

I think we all agree on that

...

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 basically the distinction between bug and feature

Not really, I have never worked in our sales and support so I've never seen the contracts customers have but i'd take a guess that there are different levels of bugs and different levels of support some of which may or may not be included depending on the contract. But again I don't actually know here.

...

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.

To my understanding, this distinction should vanish in the future.

I don't think so, I expect customer bugs especially reported against released versions will continue to go through SUSE's support team. Hopefully the difference in the future is that the resulting bugs that make it into bugzilla are public to Leap users as much as possible (with any customer specific info hidden). There could still be some cases though where bugs don't really make sense without customer info and maybe they will stay private. -- 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 4/24/20 10:10 AM, Stefan Seyfried wrote: ...

"my" subscription count is orders of magnitude higher. ... and that's why I reproduce my bugs on Factory or Leap, file them (and often put a fix into) in bugzilla and then request a backport to SLE :-), a process that is much less exhausting and much more efficient.

out of idle curiosity ... wondering about the "reproduce my bugs on" step. what 'flavor' of box do you typically sit in front of ? SLED, Leap or TW ? you're clearly in a mixed environment ... -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

Am 24.04.20 um 19:20 schrieb PGNet Dev:

...

out of idle curiosity ... wondering about the "reproduce my bugs on" step.

what 'flavor' of box do you typically sit in front of ? SLED, Leap or TW ? you're clearly in a mixed environment

At home: Tumbleweed At work, workstation: Leap At work, servers: SLES1[0125]-SP[12345]{,-LTSS} -- Just one idea that I have in mind after re-reading the thread, I'd be really interested in feedback regarding community feature request and

On Sat, 2020-04-25 at 10:37 +0200, Stefan Seyfried wrote: public bugzilla product. You're in unique situation that you seem to be using the entire portfolio. I had today a discussion with our JIRA team (essentially the team who designs worklows and processes in SLE Department) about https://en.opensuse.org/Portal:Leap/SLEFeatureRequests I think we need and I am expected to give them some sort of a strawman on May 19th. Would you mind having a look once I have first draft? Of course I'll send it to project/factory as well, but I'd really like your particular feedback. I'd try to cover bugzilla part as well.

"For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman

-- Best regards Luboš Kocman Release Manager openSUSE Leap SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer

On Sat, Apr 25, 2020 at 22:56, AW wrote:

Am Donnerstag, 23. April 2020, 20:32:01 CEST schrieb Stasiek Michalski:

...

We do actually have companies using TW, and we could have more if we published patchinfo for it since we had some interested parties (that's pending, but it would be cool to figure out so TW is a viable option for more businesses).

Since January TW's kmail suffers from a bug regarding »umlaute«. If you receive E-Mails in German quite often you get »ÃŸ« and »Ã¶«. Since January!

That bug will land in Leap 15.2 soon too! Exciting times :D The difference between Leap and Tumbleweed isn't in how stable they are, but how fast you can get the bugs, and for how much shorter the bugs typically stay in the distros. Tumbleweed will land a fix as soon as it's out there, Leap users might need to wait until the next rebase of packages, which sometimes happens every year, sometimes every two years and sometimes not until the next major version which is 4 years. LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org

On Sun, 2020-04-26 at 02:12 +0200, Stasiek Michalski wrote:

On Sat, Apr 25, 2020 at 22:56, AW wrote:

...

Am Donnerstag, 23. April 2020, 20:32:01 CEST schrieb Stasiek Michalski:

...

We do actually have companies using TW, and we could have more if we published patchinfo for it since we had some interested parties (that's pending, but it would be cool to figure out so TW is a viable option for more businesses).

Since January TW's kmail suffers from a bug regarding »umlaute«. If you receive E-Mails in German quite often you get »ÃŸ« and »Ã¶«. Since January!

That bug will land in Leap 15.2 soon too! Exciting times :D

The difference between Leap and Tumbleweed isn't in how stable they are,

Really?

but how fast you can get the bugs, and for how much shorter the bugs typically stay in the distros.

Isn't that a definition of relative stability (rate of change) between TW and Leap?

Tumbleweed will land a fix as soon as it's out there,

Along with potential new regressions making TW less stable from an overall software behavior experience than Leap. All software has bugs, and dealing with consistent behavior (including bugs) over time can be better experience for the user than constantly adjusting to new surprises.

Leap users might need to wait until the next rebase of packages, which sometimes happens every year, sometimes every two years and sometimes not until the next major version which is 4 years.

So we no longer do bug fix patching against Leap releases? What are the update repos used for then? If you referring to stability in the sense of software not crashing. I hope we still fix those classes of bugs with Leap updates. -Scott

Am Samstag, 25. April 2020, 22:56:32 CEST schrieb AW:

Am Donnerstag, 23. April 2020, 20:32:01 CEST schrieb Stasiek Michalski:

...

We do actually have companies using TW, and we could have more if we published patchinfo for it since we had some interested parties (that's pending, but it would be cool to figure out so TW is a viable option for more businesses).

Since January TW's kmail suffers from a bug regarding »umlaute«. If you receive E-Mails in German quite often you get »ÃŸ« and »Ã¶«. Since January!

Yes, and a fix is already available (since 27.02., see https://bugs.kde.org/show_bug.cgi?id=416758#c4 ) . It will be in the KDE Applications 20.04, which will soon be shipped. If you are annoyed by that bug - patch the current source and submit the fix in OBS - switch off HTML-view - write/extent an openQA test to fetch issues on KMail earlier

Last week zypper dup brought an update for plymouth that made systems unbootable!

I cant share that observation.

TW for a company sounds ... demanding.

You have the option to roll back to an earlier snapshot....

I appreciate the testing of TW; I'm trying not to be ignorant to alle the work that keeps TW rolling. I'm watching all the folks struggling to keep everything together. Leaving Suse behind would feel like burning down the house where you have lived for decades.

I'd really be happy if I'd not had to chose between a stale system and distrowatch!

I doubt that you will get a system from distrowatch :-) From what I have heard from former Arch users, the situation in TW is much better than in any other rolling release. I'm happy with it.... My 2c Axel -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org