these are notes from yesterday's meeting with the Autobuild team. We
were discussing what direction to take with submit requests in the
recently proposed Jump model.
Adrian is taking a longer vacation and did a handoff of Jump project as
it is to the openSUSE Release team.
I'm really happy that we found an agreement about having just a single
target for all Submit requests in the new jump model which will consist
of Backports, packages with SLE origin, Leap specific packages).
We've also agreed on possible replication of submit requests within
individual OBS instances, which will nicely go hand in hand with the
new SLE Community Feature request model, and generally will ease the
situation we already have with submissions which involve a change of
package origin from SLE. This will still require some more research and
discussions with stakeholders (maintenance, security ...).
Notes from Ad-hoc meeting to discuss submit request model for JUMP
This content is also available here:
Attendees: adrianS, maxlin, lkocman, scott bahling, ismail
Adrian: This seems to be a transition point to openSUSE Release team,
since Adrian will be one extended vacation (3w).
Some "facts". We do rely on reviews from openSUSE Factory, submits to
backports are following Factory First. Ismail confirms that Backports
currently copy packages from openSUSE Leap.
* Confirmation: submissions will be always open just against one
project. Tracked as https://jira.suse.com/browse/OBS-59
It should be
relatively easy for OBS, reality will show.
* The earliest release date for Jump or Leap based on Jump is 29th of
October. So if we'd agree that Jump quality is sufficient, this would
be the release day for openSUSE Leap 15.2.1 . Otherwise if it's still
in a prototype mode then the release day itself could be released even
earlier. This is also tied to the SLE Community Feature Requests.
Adrian Submission for Jump gets forwarded to openSUSE:Backports.
Origin doesn't matter, for existing packages: if it's an SLE package it
will happen a maintenance request in SLE.
Adrian: We have to figure out how to get an external request as an
internal. Some concerns external people should not be able to create an
external request just like that.
Ismail: This needs more discussion. There needs to be a policy.
Rudi: duplicating request might be a way to go
Lubos: if we duplicate requests, then we need to make sure that the
original request is not just rejected.
Rudi: both requests need to be updated
Ismail: This may need some sync bot.
Ismail: We need to copy openSUSE Backports somewhere, as it's going to
be released before openSUSE Leap. Ismail is a bit worried that
openSUSE:Backports could be broken before 15 SP2 GA.
Scott: Backports still have Factory source check (Leaper bot).
Ismail: Leaper bot and others do have a config so they are not
hardcoded to the current openSUSE Leap setup.
Max: Is surprised that Leaper bot is still alive :-)
Diagram of the Submit request workflow for the new openSUSE Leap model.
Adrian: do a matrix of diagrams (maintenance/GA). And multiplex by SLE,
Backports, and Jump.
Lubos: Perhaps Early Features vs Late features
Todo: Lubos will place diagrams here
Adrian: proposes to cover any changes to the workflow as part of the
So any content-workflow changes for SLE/Leap would be simply part of
The proposal from Adrian: since it takes some time until project gets
accepted in SLE. Perhaps we could create an intermediate request for
and pending submit requests before they get to SLE.
Lubos: I'm a bit concerned about having an easy way to workaround
"workflow slowness" so we don't have a need to speed it up.
Adrian: has currently something like 20 packages which are needed to
Max: is trying to find a time to fix the package generator. It's not
going to be this week.
Lubos: I'd like to focus on testing incoming sync requests from SLE.
Adrian: an SR for Jump will end up being an SLE maintenance request.
The problem will be with internal requests which will not be
recognizable in Jump/Leap.
Rudi: Since I'm the one updating the sources and transferring them from
IBS/OBS. We could call
Todo for Lubos: Give Rudi a URL that can be called from bs_hilbertsync
after the sync event. This could trigger any sort of tests that need to
be executed (install-check, or xcdchk tests).
Todo for Lubos, schedule a meeting with the Maintenance team in 2 weeks
from now. Invite Max, Rudi if needed, and opensuse-maintenance@.