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, 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.
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. 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.
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.
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?
IMHO the board is no technical steering commitee. At least it was it was not elected as such. Maybe we should have one though ... But so far these decisions (and also to fork or not fork a package for openSUSE) is done by the release manager (Lubos) in this case. happy easter! adrian -- Adrian Schroeter email: adrian@suse.de SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org