Last week we had some more discussions on how to proceed with the staging workflow. We took some decisions for our next steps and you're invited to give feedback and pull requests wherever you see a problem. We did not talk about any long term planning, we will do research - implementing changes as we see problems.
One thing we want to start with is replacing build service groups with staging project reviews, so let me explain this a bit as most won't even be aware of the problem ;)
As requests come to Factory, we have to be very careful not to accept A before its dependencies are in and not to accept B before all the packages fixed for the update are in.
My current solution for that are request groups - implemented in a hackweek project. This makes sure that we can't accept the delete request of a rename couple before the new package name is through legal review. But it's pretty intransparent to the reporter, so we would like to replace it with a more visible approach: grouping requests in staging projects.
If you read my previous mails about the staging projects, they already group requests that are tested together. So the request groups and the requests that end up together in a staging project have overlaps that make the whole thing even more inscrutable.
So the idea is as follows: if 2 requests need to go into factory together, they need to go into the same staging project and both requests get a review "by project openSUSE:Factory:Staging:F". So the reporter sees the project he has to check - and we can use the comments of that project to track the status of the reviews.
This is a bigger task than it appears to be - as we need to adapt quite some tools, the repo checker needs basically to merge with the staging checker and both need to implement e.g. some logic for delete requests. This is all part of the factory-auto repo