Hello everyone, I wanted to write this mail to let everyone know the current status of SUSE's ALP (Adaptable Linux Platform) efforts and hopefully get the ball rolling with openSUSE making use of these efforts. This is a long mail, but I've done my best to be brief and shift the more esoteric technical detail as an appendix for those most interested in contributing. First, I want to clear up "What is SUSE ALP?" SUSE ALP is not a single new product by SUSE, in the same way that SLE isn't a single product. Just like now where SUSE has SLES, SLED, SLE Micro, SLE for SAP and more, SUSE ALP is a 'platform' that is going to produce whole families of products. The key defining difference between SLE and ALP though is that SUSE is building ALP with "Adaptability" being an absolute core aspect. This should reduce or eliminate the situation we often see with SLE, where products are 'stuck' using the same versions of core components like glibc and python for the whole lifespan of a codebase. With ALP, SUSE will be building things in a way where different ALP products can have different versions of core components, be supported for different lengths of times, and with old versions of those components be removed when they're no longer needed. This is also why you do not hear about a singular ALP 'codebase', because the way ALP Products are built they potentially could draw from multiple codebases, potentially with very different lifecycles; eg. One ALP Product may be what most would call a very 'stable' distribution, another could be 'rolling', and a third could be a hybrid between the two. I feel this is the most exciting thing about ALP, and it's the most interesting engineering aspect of ALP as it dramatically changes HOW we build these products in OBS. See the appendix for details. So, if ALP is not a single product, what is SUSE building? SUSE's current efforts are focused on two SUSE ALP products, which you can currently see in OBS as SUSE:ALP:Products:Bedrock and :Micro. These names are unlikely to be final, but they are expected to be server-focused products, heavily leaning on transactional-updates and containerisation to even further push the core "Adaptability" goals of ALP; It's far easier to shift and swap what versions of libaries are in play when (almost) everything using them is containerised and the OS is being thought of as a cohesive unit that is updated in atomic operations These will not be the only two products SUSE builds from ALP, but it's a starting point. Going forward, just like for the SLE family of products, the primary build environment for these products is going to have to be SUSE's internal build service. This is so SUSE can have these commercial ALP offerings certified the way they are required to be. However, we want ALP, both the code AND the different way of building things, to be available to openSUSE and ideally reused/adapted for openSUSE's own offerings. We still want to build ALP in the _open_ in addition to what we need to do for SUSE's commercial offerings. 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. 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. I could also see a future where we take this opportunity to try something like an ALP-based take on the MicroOS Desktop, more polished, opinionated and less 'tinkering friendly' than old Leap. I'd imagine that would certainly be possible; also, maybe in parallel, if people want to build it. This approach would also tie in nicely with all the awesome work the Agama (formerly known as 'D-Installer') team have been doing, as we should be able to offer a single installation ISO that offers all the combined "openSUSE ALP" offerings, including the 1:1 openSUSE copies of SUSE's Products as well as any additional ones built purely by openSUSE. This would potentially cut out a lot of the work needed for the openSUSE-only Products as (speaking from experience), creating and maintaining installation media is often the biggest pain. What does everyone think? --- Richard Brown Distributions Architect @ SUSE --- APPENDIX Below --- Brief technical details about how ALP is currently built. If the above proposal is widely accepted then openSUSE would mimic the below, just obviously replacing SUSE: with openSUSE: SUSE:ALP:Workbench:<workbench_version> This project effectively does the same job as Factory Rings 0 and 1, being a frozen copy of packages needed to bootstrap everything else. These packages are frozen from openSUSE:Factory SUSE:ALP:Source The main project for OBS prjconfig SUSE:ALP:Source:Standard ALP supports the concept of multiple codebase velocities. "Standard" is the default that SUSE is currently building, but there may be faster or slower velocities going forward. openSUSE may also have it's own in addition. I can totally imagine Tumbleweed evolving to become something like SUSE:ALP:Source:Fast someday. This project includes sources but is not built. SUSE:ALP:Source:Standard:Core:<core_version> Core system packages (linked from SUSE:ALP:Source:Standard) and generic containers to be used across multiple ALP products are built here SUSE:ALP:Products:<product_name>:<product_version>[:<product_minor_version>] This is where the product definitions and patterns live. Each product builds against a SUSE:ALP:Source:<velocity>:Core:<core_version> project Additional packages specific to a product are allowed Ideally packages should be submitted to and linked from :Core: by default (to allow package sharing between products) but exceptions can be made. For openSUSE-only products, such exceptions might be the norm. Containers, VM images, etc specific to a Product are all defined and built here. SUSE:ALP:Products:<product_name>:<product_version>[:<product_minor_version>]: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.