Rough, incomplete, WIP, just to get a discussion going
-
Work in a Git branch for the desired released product, e.g. SLE-15-SP42
-
Create a pull request from that, get it reviewed and merge it
-
Upon merge, a GitHub action will trigger an (internal) Jenkins job:
- Build the package
- If it builds, check the package in to IBS Devel:YaST:SLE-15-SP42
- Create a submit request from there to IBS SUSE:SLE-15-SP42:Update which IBS will automatically convert into a maintenance request for already released products
-
The maintenance request enters the maintenance queue in IBS:
- It is automatically built for different architectures
- Bots check various things (license-digger, maintenance-bot)
- A human reviews it
- It goes to the staging projects, e.g. SUSE:SLE-15-SP42:GA:Staging:A etc.
- ... ?
- From merging the PR to submitting the MR, everything on the YaST side is automated
- From that point on, it takes quite some time (days or weeks) inside the maintenance queue
- From our (the YaST) perspective, we have done our work once it enters IBS
- If it is declined (which may take some days or even some weeks), we won't notice
- Somebody would have to monitor every MR to check on a regular basis if it was accepted, if it was released to the customers, or if it was declined
- Unless the individual developer who initiated the MR checks it again and again until it finally is accepted or, better yet, released, a failure might not be noticed for a long time
- In the case of an L3, the L3 team watches the progress closely because they have one specific customer who is waiting for a fix. How do they do that?
- At what point in the process do we hand off responsibility to the maintenance team?
- Is the expectation what that point is the same for us as for the maintenance team? Or is there a gap that neither feels responsible for?
- Since we have so many packages and so many maintained product versions, can we realistically monitor the MRs manually?
- Tools:
- What tools are already available for such a task?
- What tools could we think of to do that?
- Who would be in charge to create such tools?
- How do other teams do it? E.g. SUSEManager? Or is this not a problem for them because they have only a much smaller number of packages to maintain?
- How do our many package maintainers (all around SUSE R&D, outside the YaST team) do it?
I created the YaST Dashboard to avoid the unnoticed declined SRs, that was exactly my goal. Recently I fixed missing checks for SLE15-SPx... 🙄
I already mentioned several times that the y2maintainer should additionally also check the dashboard and ping the respective people when a problem occurs, just like with normal bugs 🐞 ...