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. 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. -- 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