Hi, On 4/12/20 11:39 AM, cunix wrote:
reply to Adrian Schröter:
On Samstag, 11. April 2020, 19:48:46 CEST wrote cunix:
reply to Simon Lees:
On 4/11/20 9:20 AM, cunix wrote:
Thanks for the answer Adrian!
[...]
Yes, but my argument was: To not get into a situation, where conflict resolution by board might be needed, there might be an incentive for B (or her manager) to not accept someone (A) from the community as co-maintainer in the first place.
If A was already maintainer when B joins because she is the SLE maintainer, she might have an interest in A stepping down to not risk disagreement in the future.
I understand your concerns here, but I see no difference between Leap and Jump concept here. IMHO we should seperate this discussion therefore from the Jump concept discussion.
O.K. The difference is in my opinion: The more packages are shared between SLE and Leap, the more likely such a situation might evolve, where a conflict might occur or is prevented beforehand by reducing shared maintenance done by people coming from different backgrounds. As I understand Jump, its goal is to increase the number of packages shared.
And keep in mind we keep the option to fork packages from SLE in openSUSE. It is just a declared goal to minimize these packages.
Although the option is there, me feared the desire of community co-maintainers to introduce a feature update of a package in Leap becomes harder to realize, if it is not wanted by policy, the (SLE) co-maintainers have to be convinced - who has an interest in keeping version of SLE and Leap in sync - and they have now to jump more often over the "fork" hurdle.
I can only speak for the Public Cloud team, we'd love to have more co-maintainers for packages we maintain. I understand your concern but I do not think there is a general statement that can be made. It is going to be very dependent on the package, where in SLES it is released, for example glibc and such things are harder to change than a package that is part of the Public Cloud module. Again, we have to see how it works out. Having lots of theoretical constructs is not necessarily going to help us. There are so many factors that come into play, personality of the co-maintainers, where the package is released in SLES and others. Certainly there will be hiccups and we'll have to cross that bridge when we get there. A long time ago we created [1] which outlines some of the concerns you are raising. As far as I am concerned this is till perfectly valid and we have mechanisms in place to handle various situations. Later, Robert [1] https://en.opensuse.org/openSUSE:Freight_Train -- Robert Schweikert MAY THE SOURCE BE WITH YOU Distinguished Engineer LINUX Technical Team Lead Public Cloud rjschwei@suse.com IRC: robjo