On 4/19/23 01:19, Richard Brown wrote:
Hello everyone,
Therefore, the current working plan is as follows:
- All SUSE ALP Products will be built in SUSE's Internal Build Service, using sources that originated from openSUSE:Factory - All packages used to build SUSE ALP Products will be copied to openSUSE's Open Build Service without alteration - All SUSE ALP Products will be copied from SUSE's IBS to openSUSE's OBS with the only alterations being the obvious necessary rebranding - Any future changes to the SUSE's ALP development workflow (eg. the possible future introduction of a git-based workflow for submitting changes into IBS/OBS) would be also introduced for any openSUSE ALP Products
This should all sound very familiar because it's very similar in concept to what we already do with Leap Micro
I would like to make the following suggestion to openSUSE on the next steps it could take to extend the above.
Any new openSUSE distribution, such as the ones discussed as https://en.opensuse.org/Portal:16.0 or https://en.opensuse.org/openSUSE:ALP/Workgroups/GrassyKnoll should be built as seperate "Products" using the new ALP way of building things.
The ALP concept should be flexible enough that these openSUSE Products will be able to leverage all the stuff SUSE is doing for SUSE's ALP Products, but then we (community) can add anything we want. If we find it is not flexible enough, then we (SUSE) will work to adapt it to make it possible for the community to build what it wants.
So, if we the community want to build something like old Leap, that should be totally technically feasible. I can certanly imagine the community building something with a stable release cadence and that doesn't use transactional-updates and containers to run everything. If that's the direction we as a community want to go, we should be able to get started soon when the above is in place in OBS.
This is largely what I expected / anticipated / planned for with the Grassy Knoll prototypes, either that or one massive repo with everything and a new way to tell tooling what to look at and what to ignore. My thoughts were if following the "Grassy Knoll" prototype for a new stable release users would probably have the "bedrock" or whatever the main bare metal product repo ends up being called plus an additional openSUSE repo that link in packages from other ALP Products + or in a third repo community packages. So the interesting question then becomes which versions of products do we link to and when and how often do we change these. We probably need more info to make these decisions but we also don't need to right now.
The biggest challenge I forsee would be ensuring we have enough people to maintain all the packages in that 'old fashioned' way of doing things, especially with SUSE going in a different direction...but that has always been an aspect of openSUSE's way of doing things.
This is also my biggest concern, one way that we might be able to help with this is, presuming that ALP containers and flatpaks are built on obs from packages that still have there .spec file, it'd be possible to link them back into openSUSE products. The way they are being used might be different and there might be the occasional bug that doesn't apply to SUSE ALP because of the differences and would need to be community supported but given at the end of the day it shouldn't be much different to tumbleweed or other distros so hopefully those bugs are few and far between. I suspect it'd be the only sustainable way for the community to maintain a full Gnome stack.
SUSE:ALP:Products:
: [: ]:Update If a product will be maintained using a SLE/Leap-like maintenance process, then this would be the Update project for such a process.
Do you have any info about timeframes / how long support will be? Having access to updates is essential for doing stable distro's i'm guessing it will be different between each product but as a rule of thumb do we know if it will be similar to current SLE / Leap where openSUSE gets standard updates but probably fairly doesn't have access to anything deemed as LTSS? Thanks for all your work on the topic and for a clear detailed email, it makes life much easier to know where we are at. -- 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