Hi Marguerite, On Tue, 31 Jan 2017 03:17:46 +0800 "Marguerite Su" wrote:

3. People don't know which package is from SLE.

Currently there's no clear indicator that tells people which package is from SLE in official Leap repositories.

This information is obtainable from a 00Meta package in the Leap distributions. To get the origin of a package in Leap use: # osc cat openSUSE:Leap:42.1:Update/00Meta/lookup.yml|grep ^lua51: lua51: SUSE:SLE-12:GA # osc cat openSUSE:Leap:42.2:Update/00Meta/lookup.yml|grep ^lua52: lua52: openSUSE:Factory

Marguerite

-- Vita -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi Marguerite, I've struggled with the best way to order my reply so sorry if it jumps around a bit. On 01/31/2017 05:47 AM, Marguerite Su wrote:

Hi,

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.

Every package in Leap should have a maintainer, now you have seen how to look up where a package comes from you will see that it generally comes from one of 4 places. - SUSE:SLE* - The SUSE Maintainer is responsible for this package. - openSUSE:Factory - This package should have only been pushed to Leap with the permission of the factory maintainer. The factory maintainer is the maintainer here unless someone else asked for permission to push the package to leap as they were happy to maintain it themself. - openSUSE:Leap:42.1 - This is the same as openSUSE:Factory - except the maintainer decided not to upgrade the package between 42.1 and 42.2 - Directly from a devel repo - There are a few places where it doesn't make sense for a package to come from SLE or Factory and these packages were added directly from there devel repo (the kernel is an example)

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 (Because I'm not the target of SLE sales :-D)

So, no communication between us, at all.

This is potentially the fault of the SUSE Maintainer if there is one, I was told that for every package I maintain in SLE I should also keep close attention to the openSUSE:Factory counterpart as when SLE-13 is created it will come from the factory package. Unfortunately this may not always happen as some people maintain either a large number of packages or at the other end only maintain a couple as packaging isn't there main role.

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)

This is because you are marked in OBS as the "Bugowner" of the package. Normally for packages that are Core to SLE the "Bugowner" should be a SUSE employee or atleast marked as a "Maintainer" if they have spoken to the existing maintainer and have come to some other arrangement. Security bugs should only be created once, at least by the security team anyway, as mentioned before sometimes parts of the bugreport can be made private. In some instances a Customer/SUSE support person may raise a second report if a certain customer needs a certain fix. Or a openSUSE user may notice and add one but these shouldn't contain anything important.

I don't even know Leap version is none of my business, at all. (Because of #3) Even if I know, it should be my responsibility to fix it (1. I am the assignee 2. sometimes Factory fixes should go into Leap)

See above.

To me, it's a brand-new and fresh bug report. It means only one bug report entry, no previous discussions, no re-assign.

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.

This is probably a automated message from one of the checker bots but the process should defiantly be improved. Potentially we need an official way for non SUSE maintainers to look up the or ask if / who the SUSE maintainer is if they don't know. In the meantime if you ask on the list or in #opensuse-factory on freenode i'm sure someone can point you in the right direction.

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.

It just leaves there.

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.

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.

boo#988491 - According to my lookup SUSE doesn't have a maintainer/bugowner for nginx (Maybe I was doing something wrong), In leap 42.2 Nginx comes from "openSUSE:Leap:42.1:Update" which means the fix should be submitted to a Leap 42.1 maintenance update then it will automatically also go into 42.2, its possible that the SUSE person you reassigned it too doesn't work on nginx in this case. boo#1010089 - Unfortunately there's no easy way to remove packages after release this case should be a bit of a outlier and there is not much the maintainer can do. If you would like to be able to use lua 5.3 in Leap 42.3 you can create a lua53 package in the lua devel repo then submit it directly to Leap 42.3 bypassing openSUSE:Factory as it doesn't make sense there. Then although it won't be the default people who want to use Lua 5.3 still can easily.

Can you imagine that a security flaw is known by me for one month but just no way to fix it?

This is just the easiest case that I think every maintainer meets.

One more thing, things changed in large scale.

I have 300+ packages. I have to "beg" SLE maintainers 300+ times to fix something. It will become a great burden.

So, here, we eagerly need to develop a common sense/rule that let Factory/SLE maintainers continue to maintain the same package, just like the OBS development procedure that both can submit things. And it should be no email threads involved. That is, if maintenance request gets accepted, the other maintainer will automatically catch up. We don't have to know each other at all.

This is slightly harder often for SLE a project manager will decide whether and when a bugfix for a package should be taken, as such there needs to be communication between the community maintainer and the SLE maintainer, if you had a patch for a SLE package I was maintaining, I personally would happily add it and notify the right people so it gets pushed within a reasonable time (depending on the bug severity).

Maintenance team have to judge, based on whether it is a valid fix, instead of whether it comes from the right origin.

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

But today when you do so, most of the times you will be told "it is from SLE, don't do that".

But sometimes things do work. We don't know why.

There should be a clear rule for doing this.

For core packages such as say python, dbus, systemd etc the release manager is likely to choose to keep the SLE version for stability in the end its the release teams decision. For leaf packages then its up to the factory maintainer to decide if the package should be updated.

And both Factory and SLE maintainers should know if he's "still" responsible for that package. Or both sides will not take care of it until told to.

Personally I think to expect bug fix from SLE for Leap for leaf packages is kinda like to expect you become a millionaire tomorrow.

Plenty of reasons like:

* Leap is 2nd class citizen for SLE maintainers. I can say more. but it is true * Bug reports go to community maiintainers who can actually do nothing * SLE maintainers can't follow upstream that tight as 7x24x365 community maintainers because they do need time off work. * One of the dependencies in Leap may be from Factory, so the same problem doesn't get reproduced in SLE * Many others like he doesn't register on bugzilla.opensuse.org, or he left his job and those packages are unmaintained now even they are from SLE I believe a cleanup was done a while back, so there shouldn't be any SLE

This also works the other way though, any fix that goes into a SLE package that is also maintained in Leap will also go into Leap so if a SUSE customer reports a bug in a shared package you will also get that fix. packages with no maintainer at worst someone from the SUSE packaging team will be temporarily assigned it until a new maintainer is found.

Finally, I just want to say, SUSE is great. It let its maintainers do things for openSUSE Factory.

So why not let community maintainers help maintaining SLE to some extent, in Leap field that can easily/flawlessly go into SLE?

Greetings

Marguerite

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