Hello team, I'd like to share with you meeting notes from today's short discussion that I had with a maintenance team. We were talking about the direction that we'd like to take with submit requests for the new development model https://en.opensuse.org/Portal:Leap:Jump, which will eventually become the development model for the next openSUSE Leap. Short summary: The goal is easy, make contributions easier and more transparent compared to what we have today. So far we've all agreed on the direction, which is to mirror OBS requests in IBS and keep them both synchronized (updates, comments, states ....). We'll have to figure out how to not flood the maintenance team with requests by defining maintenance update acceptance criteria on how should an openSUSE Leap maintenance request for a package with SLE origin look like (e.g. no rebuild of several packages across maintenance projects, or change of ABI/API). These would be typically requests for next releases. We kept in mind that the update of a package in the openSUSE Leap Beta phase can be in fact also SLE Maintenance request if the package is inherited from the maintenance project. Updates of Leap specific packages would stay more relaxed, just like nowadays. We'll have yet another meeting on June 18th. Please reach out to me if you'd like to be part of it. Lubos Meeting minutes for an ad-hoc meeting with the maintenance team Attendees: lkocman, deneb_alpha, snbarth, gustavo boiko Topics to discuss: Submit requests in the Jump development model. Diagram of proposed workflow as discussed with Autobuild in by lkocman: https://github.com/openSUSE/CommunitySLEFeatureRequests/blob/master/images/s... Future openSUSE Leap would be built on top of several projects, openSUSE Backports (8k packages, the diff in between SLE and Final openSUSE Leap), SUSE Linux Enterprise (4k packages) and Jump or Future openSUSE Leap (~ 50 "branding" packages including 000product ...). The vision is that contributor submits a Submit Request against a single project and feature gets redirected to a correct origin ( https://jira.suse.com/browse/OBS-59). If the origin is SLE then submission gets mirrored to OBS (https://jira.suse.com/browse/OBS-63) and updates in the original SR and cloned SR are synchronized. This might be unwanted in case that package comes from an SLE maintenance project, or in the Late SLE development cycle. What would be a preferred direction by the maintenance team for this? Gustavo Boiko: We need to reference an approved ECO, otherwise we do not accept the change. lkocman: Marcus: if we offer this to community and we'd have "more active" version updates. This can flood the team by bureaucracy. We're pretty relaxed about version updates for Leap packages that are not coming from SLE, but for SLE packages, every change needs to go through ECO. Lubos: what would be the workflow, for next release service pack, which in fact is a SLE-15:Update request. Essentially 4 options. 1) Update package in SLE-15:Update, fork it for new SLE SP if it's a desired change, fork it in Leap or drop the change if it's unwanted. Marcus: rebuilds of multiple packages in update streams is something we simply not do. We have a commitment to keep ABI/API compatible across SP and related update streams. Exceptions would be defined by ECO. Generally unwanted as it could break also 3rd party packages. We have to keep independent software vendors which build on top of SLE. Notes: a regular bugfix does not need an ECO, we need that for version updates and so on. The ideal deadline for the maintenance workflow prototype would be the end of July. So we have time until potential October release. Post meeting: Chat with Marina: could we auto-reject requests update request touching ABI/API with a message to open feature -> ECO? Is there ABI/API checker bot? Marina: List of tools/bots