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? 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. 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" 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? If A wants to change something in xy for Leap, does he has to ask B (via a SLE feature request) first? 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)? 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. So, additionally to "Factory first", "Leap second" and "SLE third" might be an idea. [...]
Please get Richard drunk enough so he can come up with something as good as Leap again.
Tend to remember someone called Rainer (or similar) came up with "Leap". [...] cunix -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org