On Tue, 2022-08-02 at 18:45 +0930, Simon Lees wrote:
Hi,
Hopefully this time the mailing list software likes me more:
On 8/1/22 18:01, Lubos Kocman wrote:
All meeting minutes can be found here: https://etherpad.opensuse.org/p/ReleaseEngineering-meeting Meeting is hosted here https://meet.opensuse.org/ReleaseEngineeringMeeting
## Attendees lkocman, coolo, sbehlert
Topics: Simon Lees's email after the frist Lifecycle WG meeting: Some of the lifecycle changes being proposed here have some pretty significant impacts on the future of openSUSE's stable distro. The current plan being discussed seems to be only offering the "fasttrack" option for the community. Which would make it basically a copy of centos-stream which as we know didn't go down well in that community and I don't think it would go down well in ours.
Lubos to invite Stefan Kulow to the next regular Community WG meeting (done, let's see if he accepts). Stephan pointed me to PM Stefan B.
Understanding of ALP lifecycles
Stefan B.: No lifecycle is being pushed by SUSE on the community, and since ALP will be built in public, we're free to select what works for the community the best with available resources (specifically also maintenance team), etc.
Stefan B. : The mentioned FastTrack - when there is a new version, think about Leap as we have it nowadays. Stefan B.: think about the decoupling of the lifecycle per "component". Unlike in current Leap / SLES some of the components will be delivered as flatpaks and containers, and these can have various lifecycles.
lkocman: That also depends on where we consume individual blocks, e.g., the desktop. If it's flathub, then the lifecycle is given by whoever maintains the flathub application. On the other side, we would have a bit more flexibility if it's an OBS "flatpak" repo.
lkocman: In the context of base-os, we'd probably have to follow the "basic" lifecycle of SLES. Similar to Leap nowadays with small overlap (1/2 of the release cadence e.g., 12+6 months or 6+3 months as in SLE Micro, that's to be discussed.
lkocman: mentioned that original proposals were offering Leap
Thanks for looking at this it gives alot more clarity especially with regards to maintenance. One thing i'd like to look at doing is seeing if we can build a more "traditional" style distro from the artifacts ALP gives us.
Well that is always tied to resources. Not sure if we have resources to do something completely different than SUSE. I really feel crucial to wait until we have something to puts hands on.
Coming from the perspective of someone who spends alot of time looking at the smaller desktops that don't really have support for Microos atm if the container and flatpak deliverables are being built from packages on obs then to me it seems like less effort to bring these sources together into one repo and create a traditional RPM distro from those then to try and get the smaller / alternative desktops working with MicroOS and everything involved with that. Although if yast / zypper end up supporting flatpaks well then taking some parts of MicroOS like that might be worth while but people might also feel like putting in the work so they aren't needed.
So the big question here for me was access to maintenance because if we just had access to fasttrack I don't think the end result would be significantly different enough to tumbleweed to spend time on but if we have access to the maintenance sources to the point where we can do a 12+6 month release then this becomes interesting for me because I have some machines where tumbleweed / MicroOS's model becomes much more annoying to live with and what we have had with Leap is a better fit and i'm sure there are plenty of others in the community in a similar position.
But I don't think there is much that can practically be done in this area yet until alot of other things are sorted.
Keep in mind that some parts will be moving slower, some faster if desktop is mixed flatpaks and rpms. I'm mostly thinking of the base-os when talking about lifecycle. I somehow suspect that other bits might have like LTS and latest versions or similar, so user would be able to choose. From the lifecycle point of view, again we're driven by resources, mostly on the maintenance side as well as in openSUSE release team. I feel we'll pick one lifecycle that will seem to be the best fit for the setup whatever it will be or as you say "when things are sorted". Additionally I'm happy to say that PM told me that they see no problem in rebuilding ALP rpms by community (was mentioned on the call, but somehow slipped through minutes). I was under impression that SUSE would push a bit for model of re-using binaries (current Leap). That gives us some more flexibility (we could stick with x86_64-v2 I suppose factory discussion goes towards plan to adopt it) but also adds extra work to maintain it.