Marguerite Su wrote:
Firstly, I know Leap is joint effect. That is, some packages are from SLE and some others are from Factory. Both sides are working great, "separately". Today I just want to talk about some leaf problems.
1. Some packages have different maintainers for the version in Factory and the version in Leap.
No explanation. It is the nature of Leap.
I wouldn't say it the nature of Leap nor is it a desirable state but it happens.
2. The maintainers from SLE for Leap is actually unknown from build.opensuse.org
eg. I am the maintainer for all the lua versions in openSUSE:Factory, and libplist/libimobiledevice stuff in hardware repository.
But I don't know who is the maintainer from SLE counterpart. No one tells me. No where to find. I don't even know SLE has those packages
The GNOME team is responsible for those packages. They most likely weren't pulled into the product due to customer demand but rather because the GNOME update in SP2 required them for building.
But when users report bug on bugzilla, everything is assigned to me because I am the only person they know. sometimes security leaks too (our security team is brilliant, they care both openSUSE and SLE, but in different bugzilla IDs)
If a package is from SLE nobody demands nor expects you to fix the package for SLE. The security team will assign such bug reports to the SLE maintainer. It could happen though that after evaluating a bug it may be decided to not actually release an update for SLE as the effort (paperwork, QA, etc) outweights the benefit. It may nevertheless be useful to fix the problem in Factory, e.g. via version update to the next upstream version. At that point a bug may end up on your desk. If you then decide to also backport the fix to Leap nevertheless, maintenance and security will not say no to that.
So I take cares of it, interact with the reporter, preparing fixes for Factory and Leap. I just following the standard procedure for bug fixes.
Bang! "Sorry, XXX is from SLE, MR rejected!"
This message annoys me because the fixes now look like a waste of my time.
We'd have to look at a concrete case. Mainenance may indeed reject requests for SLE inherited package. However, usually they would then mirror the update internally and push it through the process so it ends up in Leap nevertheless.
I don't know who to talk now. And the maintainer from SUSE doesn't know there's a bug here needed to be fixed by him either.
If related to security issues feel free to talk to security directly. They know and care for both worlds so will try find a good solution. If in doubt talk to me.
Let's say, even if it is from SLE, what about a bug fix backported from Factory? By nature, it should be taken care of by Factory maintainers.
But you can't touch it at all. Because it will break the "sync" between SLE and Factory. There's only one-way sync: SLE to Factory.
Depending on whether we are talking about a release in development or maintenance the process differs. As outlined above an update for SLE maintenance may get rejected if it's too minor. For a release in development you can submit updates of course. Prepare to have to answer questions in the submit request though. We may also pull the SLE maintainer into the discussion to check if we can e.g. update a package in SLE.
And many times, it just vanished after I reassigned it to SLE maintainer. (boo#1010089, boo#988491 and more) because Leap is not their 1st priority, leaving me the person on fire.
Well, in the case of lua Jan did prepare an update for SLE actually. It just takes time to pass through the process. The nginx case is different. It's actually not part of SLE but some ancient version was contained in some old add-on. So from Leap PoV it comes from Factory ie responsibility of the server:http/nginx maintainers.
Can you imagine that a security flaw is known by me for one month but just no way to fix it?
mailto:security@suse.de ASAP :-)
3. People don't know which package is from SLE.
Release team knows. We don't. Or we can't remember that much even was told.
As others have pointed out there is a lookup file that lists the mapping. See also https://en.opensuse.org/openSUSE:How_to_contribute_to_Leap There are also lookup files in the :Update projects as the mapping may change. For example in 42.2 we originally updated some packages compared to SLE but SLE catched up via maintenance update.
4. There is no clear rule to override packages by the one from different origin.
In 42.1, I know there's an email sent here, that people who want to override SLE packages can submit directly from openSUSE:Factory to openSUSE:Leap:42.1
That was the case for 42.2 and is the case for 42.3. Noone prevents anyone from submitting. Just the level of questions asked and extra reviews needed may change depending on origin and importance of the package :-) Staying in sync with SLE is just one criteria anyways. Independently of that we have to keep in mind that Leap is a stable release. So the default choice usually is to stay with whatever version we already have.
So why not let community maintainers help maintaining SLE to some extent, in Leap field that can easily/flawlessly go into SLE?
To the best of my knowledge you can help with that. It's just not as smooth due to the separate OBS instances. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org