[opensuse-factory] Better joint effect in Leap maintenance
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. 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. 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) 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) 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. 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. 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. Maintenance team have to judge, based on whether it is a valid fix, instead of whether it comes from the right origin. 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. And things just get update, eg in 42.1 some packages are from Factory, in 42.2 they are from SLE because no one from the community actually care it. Or, in 42.1 some packages are from SLE but in 42.2+ they are from Factory because there's a strong reason to switch origin. Currently there's no clear indicator that tells people which package is from SLE in official Leap repositories. You have to test yourself by wasting your time preparing maintenance request to be rejected for it. 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. 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 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 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Marguerite, On Tue, 31 Jan 2017 03:17:46 +0800 "Marguerite Su" <i@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
On 2017-01-30 19:17, Marguerite Su wrote:
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) at least you can see which packages come from the SLE side in https://build.opensuse.org/package/view_file/openSUSE:Leap:42.2/00Meta/looku... e.g. libplist is from SUSE:SLE-12-SP2:GA
then you could look at changes files like https://build.opensuse.org/package/view_file/SUSE:SLE-12-SP2:GA/apache2/apac... and if there are recent changes from @suse.com addrs you could try to put one or two of those into CC or even one as assignee in bugzilla and finally, you could ask SUSE people, who could then do iosc maintainer libplist to see that it says group:gnome-maintainers or iosc bugowner -e libplist that says you should assign bugs for that package to bnc-team-gnome at forge.provo.novell.com
So, no communication between us, at all.
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)
I think, most of the time we try to track it in one bug, so that we know we have all required fixes by comparing bug IDs between openSUSE and SLE package versions. But sometimes, SUSE people use private comments in public bugs and sometimes important information or questions are there, that non-SUSE people dont see - that should be improved.
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)
Finally, I just want to say, SUSE is great. It let its maintainers do things for openSUSE Factory.
https://build.opensuse.org/project/show/SUSE:SLE-12-SP2:GA lists packages of SLE, but there can be version updates in https://build.opensuse.org/project/show/SUSE:SLE-12-SP2:Update Sources are all public these days. thanks :-)
So why not let community maintainers help maintaining SLE to some extent, in Leap field that can easily/flawlessly go into SLE?
yes, would be nice, but the (internal) build service workflows were not (yet) designed for it. Would be something for thinkers like Adrian Schroeter to rethink. Thanks for your thoughtful mail and all the work on openSUSE packages. It is much appreciated. Bernhard M. -- 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
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
participants (5)
-
Bernhard M. Wiedemann -
Ludwig Nussel -
Marguerite Su -
Simon Lees -
Vitezslav Cizek