## Attendees: Max, Adrian, Wolfgang, Nathan, AdrianS Scott declined (NEXT MEETING ON FRIDAY IN CASE WE GET FEEDBACK FROM PM) Summary of previous meetings with Product Management (SLES and Micro) * We want Package HUB for SLES and SLES for SAP. SLES 4 SAP will not have fewer packages. Just like in SLES 15 PH We should not ship packages that are part of another product (including Micro). * No Package HUB for SL Micro 6.X, they'll simply keep on using Extras repos to deliver a stack to build of KMPs for Micro. lkocman: Given our situation with basically single base product, we should offer only installable content. Nathan: In SLES 15 this could be problematic based on the combination of modules that is enabled. lkocman: To my knowledge SLES 16 wants to get rid of the module concept as it was in SLES 15. Wolfgang: In 15 we're basing our filelists based on having all modules enabled. Question for PM: situation with extensions and modules for PM. In this sense we mean a repository which will not be enabled by default and costs extra money. Adrian: can we take this other way, we can define that we do not take care of anything above base SLES. lkocman: sounds good, we can simply ship only what can be installed on top of base SLES 16. Treat all missing packages as a new package addition request. I suspect we'd get most of these requests during the Beta testing phase. Adrian's simplified proposal for Package HUB My assumption is that Leap will continue consuming binaries from PackageHUB. So the following is for all packages which are not in SLES. We're not talking about the full git workflow, including reviews. The good thing is that we already have reviews from Factory. We could just add a submodule from Factory. And then we have to find out how to do stage testing. My assumption is that we would still use the rpmlint-check to generate the negative list (stuff which is in SUSE products). If you take a subpackage, then you need to take everything. Max: if we use PackageHUB/Backport projects ... those do not have product-builds or Agama. we have those substitutes in prjconf for Backports project # openSUSE -> SLE magic so many environments can work Substitute: desktop-data-openSUSE-extra desktop-data-SLE-extra Substitute: desktop-data-openSUSE desktop-data-SLE Substitute: openSUSE-release sles-release Substitute: wallpaper-branding-openSUSE wallpaper-branding-SLE to ensure SLE+PackageHub always use the right package Some stories behind from Max: If Leap consuming binary packages from PackageHub, current Leap 16.0 staging project setup need move to PackageHub, we used to only test package build in SLE15 Backports staging, Leap 16.0 now be able to *test* new changes in openqa before merge the change, eg. KDE, agama-installer, etc., in case to keep the same capability after moved the main testing to SLE16 PackageHub staging project, we need to build a ftp-tree + agama-installer for testing, therefore openSUSE meta package is needed, as well as to build a ftp-tree of PackageHub(by productcompose), the Substitute in prjconf can be the problem without a solution. Adrian: this should only affect build requires Max: It also affects requires Max: then we have to rebuild these packages in Leap again. Adrian: shouldn't this be doable with proper flavors? If we have two flavors of the package one for SLE and one of openSUSE then we should be fine. Max: if we implement different build flavors for SLE and openSUSE AND if we remove the Substitutes from Backports prjconf then this should work. But you'll also see uninstallable packages. Adrian: we can blacklist the binaries for SLE flavors This is in the context of reusing binaries from PH, there are many packages we have to rebuild, in case we don't have build flavors. Nathan: all of these packages would have to be modified to use multibuild flavors (SLES/Leap). Max: we also have to build Leap-release package to Backports to be able to build both flavors. Nathan: would have to have more repos than standard? Adrian: No, we would just have more packages. And we can filter packages prior to publishing. lkocman: There is no dedicated Desktop product in 16, desktop stack in SLES will be reduced compared to SLES/SLEWE/SLED 15. Do we really have to worry about Leap vs SLES branding on desktop? Question for PM: Could we offer a generic openSUSE branding on desktop for KDE and other non-SLES desktop packages, even if they are being offered for installation on SLE via PH? Is that a big problem at all? Maintaining separate SLE branding for desktop packages in PH adds a lot of burden on the build setup and maintenance of two themes etc. lkocman: I'd like to see the official request for KDE Plasma 6 in Package HUB for 16. Nathan: It's not an "official request", but more that customers open bugs complaining about not being able install KDE packages. For example: https://bugzilla.suse.com/show_bug.cgi?id=1229692 (LMU Muenchen). lkocman: Yes but that is for 15 SPX where we had a dedicated Desktop product etc (no longer case on 16). SLES will still have a desktop. Nathan: exactly, and all the SLES customers using the desktop will still want a million desktop packages in PH Max's idea: Add Leap 16.0 to src.o.o, inject the list to PackageHub. All reviews and the integration checks should be done via Leap's staging project check, Packagehub(Backports) rebuild package once for SLE/PackageHUb customer. lkocman: If it's easier for us ... I like this because openSUSE contributor has a more straightforward workflow (he always submits to Leap:16.X project, since there is currently no way to send SR to SLFO from the public).