#30 Overview of maintenance updates for Leap
Opened 2 years ago by lkocman. Modified a year ago

As a openSUSE Contributor I'm many times stuck with progress on my package because of a SLE maintenance update for which I have close to zero progress insight.

Having some portal where I could watch highlevel overview of progress on each openSUSE Leap update (be it both updates for SLE+Leap and Leap) would make my contributor's life significantly easier.


Lubos to involve @deneb_alpha and Marcus M.

Agreement is to discuss this issue on the next openSUSE Release Engineering call.

A visual overview of the status (on the SLE side) is currently available via the internal tool called SMELT (SUSE Maintenance Extensible Lightweight Toolset).

One idea could be to have a SMELT instance covering the openSUSE side. In any case, this option can't be done out of the box and it will require also some internal approvals.

I think this would be a nice way. Where should I start with the approval?

The maintenance team has an existing effort to opensource their tools. This is slightly disconnected from our request, which is to publish status of updates that are relevant to openSUSE Leap.

It's not an easy task, I personally am not sure if it can be achieved in 15.4 timeframe. But we can continuously work on having this done for future releases.

Based on existing communication with maintenance team we'd require a partial export of data outside of SUSE. Which will require quite some approvals.

@deneb_alpha are you willing to own the task?

Metadata Update from @lkocman:
- Issue assigned to deneb_alpha

2 years ago

From Simon:

From the release engineering notes, we have http://ostrich.suse.de/emergency.html for tracking the progress of updates we care about, the source code is here https://gitlab.suse.de/emu/reporting/-/tree/master/dashboard maybe it would work as a starting point, currently we only track updates we explicitly care about

Updating the history with some more details:

lkocman: Light touch on the topic to display status of SLES updates to community. We can try to find the way to export the data.
Marcus: Generally could be possible, but we need to explicitly avoid exposing embargoed security issues to the outside. Also review IP/NDA updates where the schedule is not public.
Lubos still needs to talk to Stephan B. I received links to an existing gitlab.suse.de project that simon lees seem to use for tracking important updates for openSUSE.
Display status of SLES updates to community (https://code.opensuse.org/leap/features/issue/30). 
Marina: apart from remarks for embargoed and other info that can't be shared (AKA related to customers) it's important to define the info that we would like to expose.
Clear requirements will help to plan the needed work and resources.
lkocman: Our usecase is: Maintainer is waiting for certain update (perhaps originally submitted by him) to get released in SLE. Anything that can help him understand remaining ~eta for releasing of the package would be in scope.
  • call between Lubos and Marina for discussing the initial details.

    • clarification of needed info/requirements
    • showcase of the internal maintenance tool (SMELT) for understanding what could be helpful and which information can't be published
  • from: ReleaseEngineering-20210915

Display status of SLES updates to community (https://code.opensuse.org/leap/features/issue/30). 
Marina: had a first call with Lubos for clarifying the use case and what is needed from the existing SUSE Maintenance tools (SMELT)
 - embargoed and customer info can't be shared
 - limit some user info from logs due to GDPR concerns
 - the search function in SMELT can be one entry point for searching for the status of an update
 - for the detailed view of a maintenance incident the Planned Release Date and the Release Date are helpful info to provide. Some more investigations/refinements are needed.
lkocman: Our usecase is: Maintainer is waiting for certain update (perhaps originally submitted by him) to get released in SLE. Anything that can help him understand remaining ~eta for releasing of the package would be in scope.
lkocman: Neal was raising his concern about Public (after embargo was lifted) CVEs for packages where he might be involved in as a community maintainer. As in our initial discussion security updates were out of scope.
Marcus: non-embargoed security updates could be displayed

I will have to check with maitenance system but this sounds 16.0+ topic to me.

Metadata Update from @lkocman:
- Issue set to the milestone: 16.0

a year ago

@lkocman: I think it's better to check with maintenance automation what they want to do.

In any case, I'm unassigning myself because I'm not at maintenance anymore and I can't contribute to this issue.

Metadata Update from @deneb_alpha:
- Assignee reset

a year ago

Login to comment on this ticket.

Metadata