On Mon, 2020-08-17 at 14:07 +0200, Dan Čermák wrote:
Overall I think this will be an improvement over the current situation.
What I don't really see addressed here though is how packages are handled that are maintained by different people in openSUSE and in SLE, if the openSUSE maintainer does not work for SUSE. I have been told that such a state can be very frustrating for the maintainer in openSUSE (this is hearsay, I have not experienced this situation myself) as the SLE maintainer can effectively dictate a lot.
Are there any plans how this process could be made less painful so that contributors will not actively try prevent their packages landing in SLE?
+100! It's not only a frustrating situation for openSUSE maintainers who do not work for SUSE. I maintain some packages in Factory under my role at SUSE, but there is a whole other team with the formal responsibility for those packages in SUSE's commercial products (and therefore also Leap/Jump). I like to think I do a good job of avoiding the tensions you describe here, with openSUSE maintainers trying to prevent stuff landing in SLE. I'm never going to intentionally make changes to my packages to make things harder to include in SUSE Products and am ALWAYS open to collaboration with others to make things easier for my packages to be consumed wherever people want to consume them. But I am witness to a significant number of cases of the inverse; Some SUSE Commericial products actively try to prevent Factory packages landing in their product, despite SUSE's own policies stating otherwise. Such a practice doesn't help anyone, and I would very much like to see Jump help address such bad practice. I'd also like it if people didn't always assume I owned all the packages in all the codebases, as helpful as I like to be, keeping my stuff in a good condition in Tumbleweed/Kubic is enough for me ;) Regards, Rich -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org