Hi, On 4/10/20 1:39 PM, cunix wrote:
reply to Stasiek Michalski:
[...]
3. Build openSUSE Leap 15.3 with SLE binaries included by default (assuming community agreement).
The "pre-built binaries" and "SLE binaries" sound an awful lot like we will not have the full package build transparency we enjoy right now. Not particularly happy to hear that.
Might be nice if it can be done the other way around:
Those SUSE packagers can submit their SLE changes to openSUSE packages or start to maintain them, where no maintainer is in charge.
The binaries build for openSUSE on obs can be used for SLE afterwards.
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.
The FAQ say: "Currently, this is not feasible due to several external factors, including certification requirements and technology partner handling."
I have to admit to not understand this completely. It seems rather vague.
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.
Another (theoretical) question [not especially for Stasiek]:
Imagine person A maintains package xy, submits to factory and it gets included in Leap.
Now some (SUSE) person B starts to maintain xy for SLE.
Someone (who?) decides xy is a "core"
The use of "core" is a bit overloaded and in this case can lead to misunderstanding. The goal is every package that is in SLE and overlaps with Leap is imported in this way.
package and the SLE binaries should be used by Leap in the future.
What happens to A? Does he still has a say on xy?
Yes, absolutely. The SUSE maintainer becomes a co-maintainer just as if another person that doesn't happen to work for SUSE could be a co-maintainer.
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. 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.
If yes, this seems like community maintainers have to do more work while having less "power" compared to their SLE colleagues.
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. Granted for many packages we have no maintainers and devel project maintainers become the stewards of those packages. For many packages there exists only 1 maintainer and if that package becomes part of SLE than yes that 1 maintainer will get company. But two heads generally produce better results then 1, so that should be an advantage.
What B calls a mistake, A might consider to be a feature.
If B has by default the last say, we might loose community maintainers, at least for "core" packages.
There is still a hurdle, and that has been acknowledged, in that SLE processes are a stick in the mud and changes on that end are necessary. How this works out will be seen as jump gets implemented and develops. There is certainly the possibility that SLE processes continue to be a PITA and the model is not workable. But we'll never 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. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Distinguished Engineer LINUX Technical Team Lead Public Cloud rjschwei@suse.com IRC: robjo