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

On 8/2/22 19:15, Lubos Kocman wrote:

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:

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.

Yeah at the end of the day this all comes back to scope. I'm pretty confident ALP will have some level of rpm based distro whether it has a narrow scope just as a host OS or SUSE still ships an RPM based product that does more (The more the easier for me). If I was to take this repo add a kvm server a python stack, enlightenment and lxqt even using the flatpak repo for apps i'd have enough of a distro that works for me and is probably useful for some others as well. If I get that far we have a reasonably strong xfce team and I might be able to convince them to join. For just me and maybe a few others obviously the complete community package set we have for Leap wouldn't be manageable so my approach would be more anything we can provide above what SLE does is a benefit. Having said that one of the reasons for bringing this concept up at this point is that given this approach is much more similar to what we have in tumbleweed it might make it much easier for say the kde community to follow this style of approach rather then having to get all of kde integrated into the Microos style of workflow which I believe is still a bit of an issue. For me the biggest issue in terms of effort is whether SUSE's ALP will have X11 packages I can just use or if i'd need to become the X11 maintainer for this stream.

I really feel crucial to wait until we have something to puts hands on.

Agreed, for now I have enough info to think that with the scope of SUSE packages plus some select community packages where we have maintainers its probably possible to provide a Leap like experience atleast for a set of packages. Obviously starting to add things like gnome and kde here might be alot of work for someone but maybe less work then some other alternatives hence throwing the idea out now before we can really do much because atleast people can think about it.

...

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.

Yeah I imagine either for some things users could choose depending on the repo setup, or to reduce effort for each point release we could pick say the python stream that makes most sense as an example where as we might allow users to choose which flatpak repo they use. But we'd also have to define something that means whatever we have in backports doesn't break in the lifecycle we have for that.

From the lifecycle point of view, again we're driven by resources, mostly on the maintenance side as well as in openSUSE release team.

At the scope of SUSE packages plus a few from the community hopefully it wouldn't be too bad because it would just be a matter of having the right channel to build the updates if we can't use a SLE update repo's for whatever reason. If the community does like this concept and does start to contribute to it alot that could make it more work but ideally we can find ways to share this work with the other things we create as a part of alp. But as with most things we probably won't really know until later.

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

Yeah agreed.

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.

Atleast from the perspective of what i'm looking at if binary rpm's are available directly from SUSE then i'd probably rather use them (again to reduce scope) what I might be more interested in is if certain package was only available as say a flatpak from SUSE or maybe as part of a container image rebuilding that as an rpm. I guess the other reason to rebuild could be if the SLE repo layout really doesn't suite us. For now i'd consider separate complete rebuilds for arch's SUSE doesn't like 32bit arm/intel and x86_64v1/2 outside my scope mostly because I doubt i'd have the time. Obviously if someone else does then thats a completely different thing. -- 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

On 8/3/22 22:04, Dan Čermák wrote:

Simon Lees writes:

*snip*

...

For me the biggest issue in terms of effort is whether SUSE's ALP will have X11 packages I can just use or if i'd need to become the X11 maintainer for this stream.

Afaik the Desktop WG is planning to go with Wayland only and remove X11 from ALP entirely.

Yep i'm aware that's being discussed, although i'm not 100% sure we have established wayland meets all our customer needs yet. If SUSE does go Wayland only for its ALP Desktop there is nothing stopping the community continuing to maintain X11 as long as someone is willing to put in the effort to maintain it. Given I have several usecase's that still require X11 and I know many others in the community also do (many of the desktop environments we support in Leap don't support wayland for example). For atleast as long as X11 is being maintained in Tumbleweed id be willing to put in the effort to try and maintain it in the community version of ALP if SUSE or the current maintainers are not. At this point for me atleast doing this is far less effort then writing the large amount of code to get all my required use cases working under Wayland. -- 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