On Sat, 2020-04-11 at 01:50 +0200, cunix wrote:
reply to Robert Schweikert:
Hi,
Thanks for the answer Robert! [...]
What is the problem with this approach?
Security certifications.
In order to make security certifications for SLE possible the binaries have to be built in the SUSE controlled instance of the build service. thus copying of binaries from the openSUSE Build Service to the SUSE internal build service is not an option.
That is easier to understand.
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? It guarantees that openSUSE Leap and SLE will be the platform, as no macro expansion or project config will change these binaries.
Next thing that big goal is also to offer seamless migrations, as rpm NVRA will be the same and you can just swap the branding packages. I've discussed some ideas such as replace signed rpm headers, use more efficient delta and so, but you'd still have different release etc. What we currently propose which we believe can be achieved in a reasonable timeframe. I'd love to see improvements over next two releases. Both process wise and build-setup wise. Big concern why people hesitate to look at it is really already mentioned certification. Migrated Leap -> SLE product with mixed binaries would be tricky in this regards, or you'd have to replace thousands of rpms. I suppose this effort would be for a way longer run.
[...]
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?
Of course I don't know how often such situation may occur.
[...]
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.
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.
[...]
know if we don't try. Maintainers that do not happen to work for SUSE should certainly NOT be considered as "junior" and in openSUSE have equal say to a maintainer that happens to work for SUSE.
That is good to hear.
Later, Robert
Thank you very much, 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