On 11/07/2019 17:10, Wolfgang Rosenauer wrote:
Hi,
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 : wrosenauer
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 https://bugzilla.suse.com/show_bug.cgi?id=1123391
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 version. 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) 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 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org