On Sat, 2020-04-11 at 19:48 +0200, cunix wrote:
reply to Simon Lees:
On 4/11/20 9:20 AM, cunix wrote:
Thanks for the answer, Simon!
[...]
Isn't it likely that B has only little room to compromise at this point in time and won't A find himself in a weaker position because of less/later knowledge?
Consequently, to not risk such conflicts, wouldn't B (or her manager) prefer to have B as the only maintainer in charge?
This would be seen as a conflict between two maintainers and could be escalated to the openSUSE Board who would then work to resolve the conflict as per openSUSE's conflict resolution process. (This is one of the board's key roles).
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.
[...]
Well if A wants to make a change that change should go through a review process via SR such that interested parties can discuss the changes.Nothing should change here since the SR process is/should be common practice.
Aha. My first understanding was, the (openSUSE) maintainers shouldn't submit their changes directly to Leap anymore, but have to first convince (by SR or feature request) the SLE maintainer to accept the change/update for SLE and than this guy has to push the new SLE package version to Leap.
Your understanding is correct, changes going into SLE need to be agreed to by the SLE maintainer. If you can make a copy of the proposed changes in your home directory it generally makes it much easier for the SLE maintainer to review and incorporate.
Then my doubts still apply because there might be an unbalance of power between co-maintainers where one is community only while the other is additionally the SLE maintainer.
Fortunately this is not my recent experience with Leap feature request mainly to udpate packages. All of them were approved. One had to be deferred to the next relase as it would require rebuild of lot of packages in SP2:GA and inherited :Update streams.
Doesn't the later have a "double" vote in discussions with her co-maintainer, because she can additionally "veto" any decision by declining the SR to SLE?
Does conflict resolution by board help here, because I don't expect the openSUSE board to have "official" influence on SLE maintainers?
[...]
Again see above, although SUSE maintainers do have to follow SUSE's rules for what submissions can be made as part of the SLE maintenance process for updates. In some very certain cases if there are reasons why the change can't go into SLE but the change is very beneficial to openSUSE users we will still have the ability to ship a different package for openSUSE with those changes but we are trying really hard to avoid that.
Hopefully this will work out in practice. My fear was, (SLE) B has more interest in keeping package versions in SLE and Leap at the same level, while (community) maintainer A might want to get closer to the Factory version.
To not have to discuss this issue further, both might strive to become the only maintainer.
cunix
-- Best regards Luboš Kocman Release Manager openSUSE Leap SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer N�����r��y隊Z)z{.��k�7��맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.��k�7���0�����Ǩ�