In case anyone's interested in YA-example,
I run openSUSE Leap 15.1 & SLE 15sp1. The former, here, is very definitely the feeder/driver of use & adoption of the latter.
TW is not at all an option for production.
For me, core tech'y that I care about being both stable & modern includes:
kernel, systemd (incl systemd-networkd), dracut, grub, Xen, GCC, git & python
Options for openSUSE Leap 15.1, from devel repos, are available & packaged for ALL of those -- except systemd.
systemd, OTOH, is shipped in Leap15.1/Leap15.2/SLE15sp1/SLE15sp2 as v234 -- lacking modern functionality, & simply broken in places.
afaict, ONLY *TW* packages v244/245 ...
Trying to get ANY of the updated versions supported on SLE is an uphill battle, at best.
OBS builds of v244/v245 for any of those^ platforms are ... challenged; unless I've missed it, I've seen no successful package builds for any of them.
There's little/no interest or response from #opensuse-*, inquiries about policy to opensuse-support list (https://lists.opensuse.org/opensuse-support/2020-04/msg00070.html) are, so far, uncommented.
Attempts to report brokenness, with links to known issues & fixes requiring updates, are dismissed as 'feature requests' with the bugs summarily/unilaterally CLOSED. e.g.,
https://bugzilla.opensuse.org/show_bug.cgi?id=1169476 "... we can't afford to backport a feature each time an openSUSE user is missing one ..."
I find that sort of response closeminded & myopic, but I get it -- not my distro, not my rules.
Here, a production OS without a modern/fully-functional systemd is of no interest/use to me; despite my personal preference ...
Unless/until an Enterprise-production-class Suse* packages/supports a modern systemd, it's no longer a option. Not Leap, not Jump, and not $SLE.
What's this mean just for me?
We used to be an all openSUSE/SLES shop; _quite_a_few_ hundreds of installs, a small king's-ransom in license/support costs. By end of this quarter, I'll have moved the _last_ bank of (8) *SUSE production servers, and the development desktops that serve them, to other OS.
Me, personally? I'll keep _my_ *personal* desktops & servers as franken-Leap instances as long as I can still hack them into submission; we'll see what systemd package's version stance does to my thinking ...
On Thu, 2020-04-23 at 10:47 -0700, PGNet Dev wrote:
systemd, OTOH, is shipped in Leap15.1/Leap15.2/SLE15sp1/SLE15sp2 as v234 -- lacking modern functionality, & simply broken in places.
Please remember that for SLE & Leap packages, the version number does not tell the whole story. Individual patches are applied in order to fix bugs, without introducing ABI incompatibilities.
afaict, ONLY *TW* packages v244/245 ...
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.
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
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_.
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_.
Am 23.04.20 um 20:18 schrieb James Mason:
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,
Even as a big customer, there is no way you can file a bug for SLE.
(Funny that one always has to explain this to SUSE people ;-))
I actually usually file my bugs (often complete with patches ;)) against Factory / Leap and then complain to our DSE that I wan that same fix also in SLES12-SP{12345} and SLES15+.
explaining the bug, and being willing to supply supporting information upon request.
No way for a SLES customer, no matter how big the contract. Only some partners may file SLE bugs.
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.
Am 23.04.20 um 23:36 schrieb Andrey Abramov:
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.
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...
On Fri, Apr 24, 2020 at 19:17, Gerald Pfeifer gp@suse.com wrote:
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...
That's a weird choice to make, considering the only difference for the user is the logo and the stylesheet, it seems like a job for a proxy to point to different contents depending on requested Host url instead.
At the same time, Christian recently discovered bugzilla.o.o's host was pointing at opensuse.org instead of the provo proxy ip, so I guess it's just a style of administration.
LCP [Stasiek] https://lcp.world
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.
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
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.
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.
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
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.
Viele Grüße Axel
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.
Am 24.04.20 um 00:01 schrieb Gerald Pfeifer:
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. ;-)
As you know, "my" subscription count is orders of magnitude higher. But that brings different problems...
Different terminology, different tools, and a different group (support)
If you, as a customer, are big enough, the tool is "write to your designated support engineer and all communication goes through him".
(Almost) never ever you get in contact with the person actually working at the bug, and communication is ... tenuous, to put it politely.
fielding those requests which may turn into Bugzilla entries internally. As you point out the customer interaction does not happen via Bugzilla.
...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.
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 ...
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}
On Sat, 2020-04-25 at 10:37 +0200, Stefan Seyfried wrote:
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 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
On 2020-04-23 T 23:03 +0200 Stefan Seyfried wrote:
Am 23.04.20 um 20:18 schrieb James Mason:
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,
Even as a big customer, there is no way you can file a bug for SLE.
Guess I need to clarify this: The way for customers is to file a service request ("SR") with SUSE's support organization. The support people help to sort service requests, pre-qualify them (e.g. differentiate between user error, packaging error, software bug), and then hand it over to bugzilla.
(Funny that one always has to explain this to SUSE people ;-))
I actually usually file my bugs (often complete with patches ;)) against Factory / Leap and then complain to our DSE that I wan that same fix also in SLES12-SP{12345} and SLES15+.
This is an unusual approach, but ok if your DSE agreed.
explaining the bug, and being willing to supply supporting information upon request.
No way for a SLES customer, no matter how big the contract. Only some partners may file SLE bugs.
Also those partners have their specific SUSE internal proxy for help pre-qualifying issues.
However, as said already: in parallel to the proposal to "Close the Leap Gap" we are also reviewing how we can optimize and open up or bug handling and processes, and make things easier.
Hope this helps.
So long - MgE
On Thu, Apr 23, 2020 at 10:47, PGNet Dev pgnet.dev@gmail.com wrote:
In case anyone's interested in YA-example,
I run openSUSE Leap 15.1 & SLE 15sp1. The former, here, is very definitely the feeder/driver of use & adoption of the latter.
TW is not at all an option for production.
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).
For me, core tech'y that I care about being both stable & modern includes:
kernel, systemd (incl systemd-networkd), dracut, grub, Xen, GCC, git & python
Options for openSUSE Leap 15.1, from devel repos, are available & packaged for ALL of those -- except systemd.
Out of goodness of the hearts of the openSUSE maintainers mind you, not an officially supported thing in any capacity. Also kind of missing the point of distros since that's not openQA tested in that configuration.
systemd, OTOH, is shipped in Leap15.1/Leap15.2/SLE15sp1/SLE15sp2 as v234 -- lacking modern functionality, & simply broken in places.
afaict, ONLY *TW* packages v244/245 ...
Trying to get ANY of the updated versions supported on SLE is an uphill battle, at best.
OBS builds of v244/v245 for any of those^ platforms are ... challenged; unless I've missed it, I've seen no successful package builds for any of them.
There's little/no interest or response from #opensuse-*, inquiries about policy to opensuse-support list (https://lists.opensuse.org/opensuse-support/2020-04/msg00070.html) are, so far, uncommented.
Attempts to report brokenness, with links to known issues & fixes requiring updates, are dismissed as 'feature requests' with the bugs summarily/unilaterally CLOSED. e.g.,
https://bugzilla.opensuse.org/show_bug.cgi?id=1169476 "... we can't afford to backport a feature each time an openSUSE user is missing one ..."
I find that sort of response closeminded & myopic, but I get it -- not my distro, not my rules.
Well, yeah, SUSE is a business, surprise, they are doing things that make financial sense. You can pay them for this work though, buy SLE subscription and request the thing, it will benefit Leap ;)
Here, a production OS without a modern/fully-functional systemd is of no interest/use to me; despite my personal preference ...
Unless/until an Enterprise-production-class Suse* packages/supports a modern systemd, it's no longer a option. Not Leap, not Jump, and not $SLE.
What's this mean just for me?
We used to be an all openSUSE/SLES shop; _quite_a_few_ hundreds of installs, a small king's-ransom in license/support costs. By end of this quarter, I'll have moved the _last_ bank of (8) *SUSE production servers, and the development desktops that serve them, to other OS.
Me, personally? I'll keep _my_ *personal* desktops & servers as franken-Leap instances as long as I can still hack them into submission; we'll see what systemd package's version stance does to my thinking ...
There are two ways to get anything done in the openSUSE Project in my experience, put the work in, or inspire other people so they want to help you out. This is neither, this sounds more like a threat of the "if you don't do it, I'm going" kind, which is childish.
LCP [Stasiek] https://lcp.world
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!
Last week zypper dup brought an update for plymouth that made systems unbootable!
TW for a company sounds ... demanding.
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!
Just my two cents.
Regards,
Alexander
On Sat, Apr 25, 2020 at 22:56, AW alexander.willand@t-online.de 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
Am Sonntag, 26. April 2020, 02:12:59 CEST schrieb Stasiek Michalski:
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.
...which is pretty much the biggest reason why I have over twenty different OBS repos active, KDE:Qt5, KDE:Frameworks5, KDE:Applications and KDE:Extra among others...
Guess you could call it "FrankenLeap 15.1" what I'm running here.
cheers MH
On Sun, 2020-04-26 at 02:12 +0200, Stasiek Michalski wrote:
On Sat, Apr 25, 2020 at 22:56, AW alexander.willand@t-online.de 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
On 5/8/20 6:00 PM, Scott Bahling wrote:
On Sun, 2020-04-26 at 02:12 +0200, Stasiek Michalski wrote:
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.
Yes as a starting point Leap gets any such fixes from SLE and openSUSE maintainers can use a maintenance process similar to SLE's to submit fixes into Leap which does happen regularly. Given that generally this just involves backporting the fixes and not adding new features you could argue it normally makes everything more stable, although occasionally a backport misses something which can cause bugs, but from experience this tends to be less then in new features or you get a fairly obvious break.
Cheers
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
-
Andrey Abramov -
AW -
Axel Braun -
Gerald Pfeifer -
James Mason -
Lubos Kocman -
Mathias Homann -
Matthias G. Eckermann -
PGNet Dev -
Scott Bahling -
Simon Lees -
Stasiek Michalski -
Stefan Seyfried