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