23 Apr
2020
23 Apr
'20
7:47 p.m.
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 ...
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
23 Apr
23 Apr
8:18 p.m.
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.
--
James Mason
Technical Architect, Public Cloud
openSUSE Member
SUSE
2219 Rimland Dr Ste 301
Bellingham, WA 98226
USA
(P)+1 360.752.6707
james.mason(a)suse.com
8:42 p.m.
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_.
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
1 May
1 May
11:05 a.m.
On Thu, 2020-04-23 at 11:42 -0700, PGNet Dev wrote:
Hi,
On 4/23/20 11:18 AM, James Mason wrote:
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@
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.
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
23 Apr
23 Apr
11:03 p.m.
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.
--
Stefan Seyfried
"For a successful technology, reality must take precedence over
public relations, for nature cannot be fooled." -- Richard Feynman
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
11:36 p.m.
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(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
24 Apr
24 Apr
7:03 p.m.
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.
--
Stefan Seyfried
"For a successful technology, reality must take precedence over
public relations, for nature cannot be fooled." -- Richard Feynman
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
7:17 p.m.
On Fri 2020-04-24, Stefan Seyfried wrote:
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(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
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. 
8:29 p.m.
On Fri, Apr 24, 2020 at 19:17, Gerald Pfeifer <gp(a)suse.com> wrote:
On Fri 2020-04-24, Stefan Seyfried wrote:
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
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
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.
12:01 a.m.
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(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
12:53 a.m.
On Fri, 2020-04-24 at 00:01 +0200, Gerald Pfeifer wrote:
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.
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.
8: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. 
8:37 a.m.
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
--
Diese Nachricht wurde von meinem Android-Tablet mit K-9 Mail gesendet.
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
12:15 p.m.
On 4/24/20 4:07 PM, Axel Braun wrote:
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
Am 24. April 2020 08:08:55 MESZ schrieb Simon Lees
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.
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.
7:10 p.m.
Am 24.04.20 um 00:01 schrieb Gerald Pfeifer:
On Thu 2020-04-23, Stefan Seyfried wrote:
As you know,
"my" subscription count is orders of magnitude higher. But
that brings different problems...
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)
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.
--
Stefan Seyfried
"For a successful technology, reality must take precedence over
public relations, for nature cannot be fooled." -- Richard Feynman
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
7:20 p.m.
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(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
25 Apr
25 Apr
10:37 a.m.
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}
--
Stefan Seyfried
"For a successful technology, reality must take precedence over
public relations, for nature cannot be fooled." -- Richard Feynman
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
5 May
5 May
1:09 p.m.
On Sat, 2020-04-25 at 10:37 +0200, Stefan Seyfried wrote:
Am 24.04.20 um 19:20 schrieb PGNet Dev:
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.
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}
--
"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
25 Apr
25 Apr
11:57 a.m.
On 2020-04-23 T 23:03 +0200 Stefan Seyfried wrote:
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
--
Matthias G. Eckermann, Director Product Management Linux Platforms
SUSE Software Solutions Germany GmbH - Maxfeldstr. 5 - 90409 Nürnberg
(HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
Am 23.04.20 um 20:18 schrieb James Mason:
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.
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+.
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.
23 Apr
23 Apr
8:32 p.m.
On Thu, Apr 23, 2020 at 10:47, PGNet Dev <pgnet.dev(a)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
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
25 Apr
25 Apr
10:56 p.m.
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
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
26 Apr
26 Apr
2:12 a.m.
On Sat, Apr 25, 2020 at 22:56, AW <alexander.willand(a)t-online.de> wrote:
Am Donnerstag, 23. April 2020, 20:32:01 CEST schrieb
Stasiek
Michalski:
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(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
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! 
7:54 a.m.
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
--
Mathias Homann
Mathias.Homann(a)openSUSE.org
Jabber (XMPP): lemmy(a)tuxonline.tech
IRC: [Lemmy] on freenode and ircnet (bouncer active)
telegram: https://telegram.me/lemmy98
keybase: https://keybase.io/lemmy
gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
8 May
8 May
10:30 a.m.
On Sun, 2020-04-26 at 02:12 +0200, Stasiek Michalski wrote:
On Sat, Apr 25, 2020 at 22:56, AW
<alexander.willand(a)t-online.de> wrote:
Really?
Am Donnerstag, 23. April 2020, 20:32:01 CEST
schrieb Stasiek
Michalski:
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, 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! 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
10:45 a.m.
On 5/8/20 6:00 PM, Scott Bahling wrote:
On Sun, 2020-04-26 at 02:12 +0200, Stasiek Michalski
wrote:
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
--
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
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.
26 Apr
26 Apr
8:36 a.m.
Am Samstag, 25. April 2020, 22:56:32 CEST schrieb AW:
Am Donnerstag, 23. April 2020, 20:32:01 CEST schrieb
Stasiek Michalski:
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
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!
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(a)opensuse.org
To contact the owner, email: opensuse-project+owner(a)opensuse.org
263
days inactive
278
days old
25 comments
13 participants
participants (13)
-
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