On 4/11/20 9:20 AM, cunix wrote:
If openSUSE users should use binaries from a build instance they can't control or look into, there really needs to be a way they can trust it the same way as obs - Adrian Schroeter already said so previously. Otherwise various package "forks" on obs may arise.
What is the problem with rebuilding the SLE binaries on obs for openSUSE? Saving build power?
Packages built on openSUSE's build server are signed with openSUSE certificates where as packages built on SUSE's build server are signed with SUSE certificates which would mean the packages would still be different. Another thing SUSE is considering here is there has already been significant work toward making a significant percentage of packages build reproducably and one thing SUSE is considering is to make sure all there packages build reproducably so that the community can verify this. All of the packages should still be exported into obs as sources which would again make this process easier.
The partner aspect is that we work on features that are under NDA, thus cannot be developed in OBS, until partners make announcements. But we still have to have packages that have these features. Therefore submissions happen in the SUSE internal build service so we have packages for testing. Once the partner announces the features the packages go to the SLE repos and migrate to OBS.
In my example with the openSUSE co-maintainers A and B for package xy, B (she is additionally the SLE maintainer) will probably be the one who prepares the package in the SUSE build service and make it "obs ready" but she is not allowed to talk to A until obs migration.
What happens if A (only openSUSE maintainer) has (technical) reasons to prefer another solution?
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).
[...]
If A wants to change something in xy for Leap, does he has to ask B (via a SLE feature request) first?
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. If you can't contact the maintainer then creating a SR against leap is fine and the release managers will hopefully be able to follow it up.
When there is more than 1 maintainer of a package the none of the maintainers should just make changes without having another set of eyes on the changes.
Agree.
[...]
Doesn't this introduce the potential of conflicts (between A and B)?
This potential is no larger than it is today, for every package that has at least 2 maintainers.
O.K. Probably I don't have enough experience here.
While it is most of the time really beneficial to have multiple maintainers, my fear was that disagreement is more likely if one maintainer is openSUSE only while the other's main focus is SLE.
In case of conflict the later may argue only her proposal is acceptable for SLE and if the former does not accept, she will go forward and change (her) SLE package and submit this version to Leap.
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. -- 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