Mailinglist Archive: opensuse-factory (443 mails)

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

On 11/07/2019 17:10, Wolfgang Rosenauer wrote:

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).

Thanks, specific examples are good (especially this one), the bug should be public but its not because someone wrongly locked it to partners.

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).

Here is the first issue, if a package is in SLE one of the bugowners must be a SUSE employee, they should be co maintaining the package with you and you should be able to have this discussion with them and life should be smoother. Maybe its not the case here because we were trying to drop it from SLE, but i'll follow that up with the right people inside SUSE.

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

Here I agree it does seem reasonable.

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.

This is where it gets interesting. Mercurial is apparently used for building other packages, what should have happened is we should have checked how this works in more detail, if something is just calls the "hg" command to extract some meta data and that output hasn't changed updating it should be fine. However if it uses hg for something more in depth and an update to Mercurial in Leap would cause other packages using it for there build to generate different rpm's in some way then that would be a good reason to keep it the same. But this is much more likely for a tool like cmake or meson.

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.

One of the reasons you should have a SLE employee as a co maintainer is because you can't actually fix something in that old package version it needs to go through SLE's maintenance process because the package currently comes from SLE.

Thanks for bringing up this example, its a case where the process we should have still isn't working right, if you or anyone else knows of any other examples where this isn't working properly let me know and we will try and sort those out as well. Especially cases where anyone who doesn't work for SUSE is maintaining a package in tumbleweed that is also in SLE and hasn't had contact with the person who should be maintaining it in SLE.


Simon Lees (Simotek)

Emergency Update Team
SUSE Linux Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

< Previous Next >