Mailinglist Archive: opensuse-factory (443 mails)

< Previous Next >
Re: [opensuse-factory] adverse effects in SLE and openSUSE relationship

Am 11.07.19 um 04:11 schrieb Simon Lees:

On 10/07/2019 15:37, Wolfgang Rosenauer wrote:
Am 10.07.19 um 02:27 schrieb Simon Lees:

What we have at the moment is close to 3, if you substitute
"community/maintainer" with "community maintainer", ie if there is
someone in the community who is willing to maintain it then they can
have the discussion with the SUSE maintainer as they will be working
together co maintaining the package anyway, for build system and core
libraries or other packages that end up affecting other packages the
answer is still more likely to be no, but for some packages that effect
less other things or some groups of packages it is possible. However the
community wanting something updated and not doing it themselves is less
likely to happen, that would probably be asking the SUSE maintainer to
do additional work in there spare time, and one of the core principles
of openSUSE is that we don't ask people to do additional work, they do
it if they feel like it.

Yes, we are somewhere inbetween in general with some trend in one or the
other direction.
I was pretty satisfied with Leap 42 and more or less still with 15.0.
With 15.1 it already felt more towards the first.
In any case you are spending half of your mail talking about updates. If
that refers to an earlier mail from me in that thread then I need to add
that I never asked anyone to do an update for a package for me. In most
cases I am the maintainer (or at least co-maintainer or major
contributor) of those packages I'm asking for anyway and I wanted to
have them updated (typically) to Factory level. And exactly that process
felt quite weird.

Yeah in this term I meant updates from what the previous version had
rather then specifically maintenance updates. Whenever we do such an
update in SLE, it also leads to more work for SUSE maintainers because
then whenever we need to fix a security issue we need to fix it for the
new and older versions, Packages in SLE service packs also have a much
longer lifetime then Leap especially if they are core packages with LTSS
support, so for packages that we do decide need frequent updates its not
uncommon to need to do 5-6 maintenance updates for different versions to
fix one security update.

ok, you are describing yet another specific situation.
When I want a package updated in Leap as part of a new minor release I
sometimes do not care what happens in SLE. (Obviously this depends a bit
how deep that package lives in the system.)
I'm caring about the package anyway and I want Leap users to get that
for certain reasons. I'm willing to do the maintenance in those cases as
well. But there seems to be resistance of having forks.

Let's use a specific example to illustrate one (not sure if the
bugreport is visibile for everyone but at least for SUSE people it is).
This example will be a bit longer though:

So talking about Mercurial:
wolfi@Hygiea:~> osc maintainer mercurial
Defined in package: devel:tools:scm/mercurial
bugowner of mercurial :

maintainer of mercurial :
wrosenauer, develop7

So both people listed here do not work for SUSE.
The package is inherited from SLE15 (mercurial: SUSE:SLE-15:GA).

I thought mercurial is a good example which should get an update within
a minor release and so I requested that in

This is kind of weird discussion and I do not even fully understand it.
Especially I still understand that mercurial is required to be in SLE15.
What I do not understand though is why SLE15 and Leap MUST have the same
If that is the case and for some reason a technical hard requirement
then fine for me and that is why I didn't bother that much.

But this situation leads to the fact that I personally (most likely)
will not care if something needs to be fixed in that old package version.

To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups