Closing the Leap Gap - Weekly Update All meeting minutes can be found here: https://etherpad.opensuse.org/p/ClosingTheLeapGap-meeting Attendees (please add yourself): gp, vmoutoussamy, lpechacek, mawerner, lkocman, mmeissner, sbehlert, jsrain =================================== 1.0 Project plan: https://confluence.suse.com/display/leap/Project+plan =================================== 2.0 Schedule: https://en.opensuse.org/openSUSE:Roadmap openSUSE Leap 15.2 FCS July 2nd 2020 =================================== 3.0 Priority items and blockers List of features marked as "DeveloperProgram" https://jira.suse.com/secure/Dashboard.jspa?selectPageId=34230 JUMP related work is tracked here https://progress.opensuse.org/projects/jump_152/issues Simplified Feature request for openSUSE Leap contributors https://jira.suse.com/browse/JIRA-722 No blockers as of today. =================================== 4.0 Updates from individual teams =================================== 4.1 Product Management Owner: Stefan Behlert Next round of Feature reviews set-up for Wednesday next week. We are progressing nicely on the features, as far as PM can see, but there are still some hills before us. Matthias: Features are ongoing, Stefan and Michal are constantly reviewing project related features. It's quite a lot of requests. Handing of External communication in progress. =================================== 4.2 openSUSE Leap Release Management Owner: Lubos Kocman Friday meeting with QA Maintenance resulted in the following action items: * Have a statistics about tracked SLE Community requests as part of openSUSE Leap 15.2 retrospective. * Add a weekly update about SLE Community requests to openSUSE Release Engineering meeting A CtLG guidance for where to submit request: https://confluence.suse.com/pages/viewpage.action?pageId=476709080 =================================== 4.3. openSUSE Leap Release Engineering Owner: Max Lin Not available =================================== 4.4 SLE Release Management Owner: Alex Herzig, Stefan Weiberg Yast - Issues with 32 bit kernel, this is already clarified (there will be no i586 kernel). These packages will be accepted on staging later today. =================================== 4.5 Autobuild Owner: Lars Vogdt, Adrian Schroeter No udate on Jump project itself. We had a meeting regarding handling of Source submissions with focus on backports project. We've agreed that we'll have a build service extension, and any submission against Jump will be redirected to backports. We will need to discuss with SLE people and autobuild team on how to handle submissions for core packages. We need to take care of handling of submissions against maintenance project (e.g. in case that package origin is SUSE:SLE-15- SP0*) A full ftp tree build is now finished. =================================== 4.6 Maintenance Owner: Stephan Barth Stephan: Same like last week: no news, waiting for workable items. =================================== 4.7 Security Owner: Marcus Meissner No upate, Marcus is involved in current CtLG features. Clarification of ECO and CtLG. This will be covered in FAQ https://confluence.suse.com/pages/viewpage.action?pageId=476709080 =================================== 4.8 Packagehub Owner: Wolfgang Engel Not available. Ismail and Wolfgang were available on the previous meeting regarding Jump Sources (see notes bellow). 4.9 Beta Program Owner: Vincent Moutoussamy We've started a draft of communication regarding recent changes towards improved transparency with the community. Communication will not happen until Monday. Gerald offered help to review the document. Thanks Gerald for community teasers. How would be the go/nogo for the CtLG handled? Lubos: Distribution build wise: I'd like to have a installable image build as part of the Jump:15.2 OBS project. Then we'd like have a period of testing for the community, consume fedback and have a Go-Nogo session on the openSUSE Release Engineering meeting. Gerald: There is multiple related efforts, such opening Bugzilla, improving the feature process, merging changes in Leap to SLE, Jump,.... Many of these should quite non-controversial. Unless there is clear pushback, openSUSE tends to follow a "those who do decide". Lubos: the CtLG effort has multiple building blocks. Each block has probably different set of stakeholders or approvers. Let's make sure that we get them all right. Action item for Lubos is to map efforts on https://en.opensuse.org/Portal:Leap - Discuss, Define and be Transparent with the openSUSE Community: Communication sent to openSUSE but also internal SUSE ML (linux@) and Public SLE Beta ML (sle-beta@lists.suse.com): https://lists.opensuse.org/opensuse-project/2020-04/msg00145.html - Upcoming news-o-o -> https://github.com/openSUSE/news-o-o/pull/36 I hope to review some to give an initial inputs on the opening bugzilla initiative next week. Gerald: I've read the email thread and there was just one response. Was it just an update or are there any next steps from the email. Vincent: It was intended to be a status update on all of the efforts and initiatives which are currently. Action item: keep opensuse-project@ updated with perhaps changes. This could be first set of incomming bugs and so on. Way for community to engage or see the value. Vincent: the initiative for bugzilla is a longer term effort, so please expect this to take some time. Gerald: Release early, Release often. =================================== 4.10 Engineering / Product Migration Owner: Jiri Srain No update. Discussion regarding yast dependency on kernel. kernel does not exist for i586. No conclusion yet. Current migration scenarion is being tested by QA (roughly for a month already). Have a look into Fedora single click migration. 3 step migration, in principal everything is in. Necessary packages need to be part of opensuse (migration plugin etc.) SCC will have to be configured properly. We'll have to deal with packaging issues regarding branding packages. Everything should be ideally solved on the packaging side. Some hacks can be done but it's not prefered. Current approach is handling all on the packaging side (Effort by Ludwig). Registration schema (for AutoYaST) is currently in the queue for Public RC milestone of SLES. Todo: Migration path from Leap to Jump. =================================== 4.11 Engineering - Kernel Owner: Libor Pechacek Yast package dependency on kernel on i586 has been resolved. Libor does not see any compelling reason, other than support for "old" hardware, for building 32bit kernel so the 32bit topic is closed for the moment on his side. Maybe we should keep Jump with aligned with SLE as much as possibe, to make the migration path to SLE as easy as possible. We don't have 32bit kernel in SLE therefore it shouldn't be in Jump or Leap as well. This topic was raised because of the yast2 buildrequires on kernel. See SLE RM section. Libor is open to hear any other reasoning to have 32bit in Leap. There are two features about RT, what should QA do about them? The highest RT level, does not come for free and development have invested quite a lot of time to get this working. It's a PM decision. lkocman: sync of kernel-rt was approved, but nothing to do for QA yet on any RT features. stefan: We do not expect Leap to ship the full RT product as of now. Libor: Current Leap kernel has bettert RT behavior than SLE, so the fact that we would not include in in Leap seems awkward. Adrian: Jump would get kernel-rt as soon as it's exported, so would have to blacklist it from ftp tree in Leap. Let's postpone pending RT features (lttng, ...) to the next release. =================================== 4.12 Engineering - Desktop Owner: Stefan Weiberg Not available =================================== 4.13 Quality Assurance Owner: Marita Werner Nothing to do for RT in SP2. Team is looking to all features, and checking whether there is some work for them or not. Vincent: Is there a dedicated team on openSUSE, just like in SLE? Lubos: There is an agreement to have a one person a week dedicated to openSUSE Leap. Marita: Outside of regular work there are some people who are involved more into community effort and people who are less. =================================== 4.14 SLE Architect Owner: Thorsten Kukuk Not present, therefore no update. =================================== 4.15 Marketing and Community management Owner: Douglas DeMaio Not available =================================== 4.16 Marketing Customers & Partners Owner: Sarah Whitlock No update this week. =================================== 4.17 Gerald Owner: Gerald ;-) Gerald and Matthias an interview with Swapnil Bhartiya, an online journalist, on CtLG. Will share link when available. =================================== ## Notes from today's (Apr 30) Jump Sources meeting Attendees: Adrian, Dominique, Ismail, Lubos, Max, Wolfgang If package build fails: backports disables the build and wipes out binaries Leap sources feed the backports project. Adrian would do the sync in a way that sources are not part of the Jump project, and are synced to backports instead. Jump would have only "temporarily forked packages". This would be the case only for packages where functionality is different. Dimstar: This approach makes sense, submissions would be sent to openSUSE:Backports project. How do we handle submissions to SUSE: namespace? Currently subject to Community SLE Feature Requests https://jira.suse.com/browse/JIRA-722 Dimstar: openSUSE:Backports will be the dominant part of the openSUSE Leap. How do we help Backports to manage the incoming work? openSUSE Leap resources would be there to help Backports. We're certainly not reducing the number of resources working on openSUSE. Ismail: Joined resources should improve quality for both Leap and SLE. Adrian: All Submissions would happen against Jump:15.2 (later openSUSE:Leap) and would be automatically redirected to openSUSE:Backports. Backports would still inherit sources from SLE, so we'd not be losing any submissions. This would not be a problem as Backports would remove conflicting packages at GA. Adrian is tracking work in https://jira.suse.com/browse/OBS-59 Max: can you submit parallel requests against Backports? Adrian: The build service part is done in this way, it's the tooling that might not support it yet. openSUSE Leap Staging currently supports only single submit requests against a single package. Will Backports support multiple requests per package? Adrian: think it's a good idea but staging tooling is currently the only part that is missing the support. Ismail doesn't see why we shouldn't support this. Backports currently does not have Staging in place. Adrian: I don't know what to do if we have an SR against Jump and if we redirect it. Won't it be "transformed" into a maintenance request? We've agreed not to allow submissions to Jump from others until 15.2 is released. This will then change after the GA. We would track the pending work on pre-integration testing (install- check on synced packages) that will be tracked in openSUSE Release tools. N�����r��y隊Z)z{.���r�+�맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.���r�+��0�����Ǩ�