obsoletion corner cases handling idea

[nirik]

Right now there's a few corner cases for obsoleting updates:

• If the older update is locked/in a push
• If the older update has multiple packages attached to it
• If the older update is submitted to stable?

I'd like to suggest we handle these by a simple rule: If any of the above are the case, we simply reject the new update being created and tell the submittor that there is already an older update XYZ and it cannot be obsoleted, and please edit that update.

Thoughts?

[tyll]

IMHO it would be better to not block or waste the contributors work.

1. if the older update is locked/in a push (I guess to testing), then the new update could be put in a waiting state and once the push is completed, Bodhi could obsolete the old update
2. if the older update has multiple packages attached to it, bodhi should offer to update the older update and replace the builds and make it easy to add the other information that might be missing (new bugs, update notes)
3. if the older update is submitted to stable, Bodhi could allow the newer update to be submitted to testing, I do not see the issue here

[bowlofeggs]

@puiterwijk has been advocating to just have Bodhi be mean and refuse to create new updates when packages are found in other active updates. It would be less fancy, but it will also solve a few difficult-to-solve issues.

Even the request: stable state can be a problem, because it is possible for a packager to click "unpush" on it, which could get it back into a state of conflict.

[nirik]

Well, I think just denying it is the easy solution we might be able to deploy sooner rather than later.

Some of those other solutions could be things we implement down the road, but the problem is that it's hard to know what the submittor intends, and there's tons of weird corner cases because sometimes maintainer A submits something and maintainer B is doing something else. Rejecting the second one at least gives maintainer B incentive to talk to maintainer A, find out whats going on and hopefully do the right thing. :grin:

Some more corner cases: If you queue the new update when an older one is locked, what happens if you submit 10? Which one goes in? all of them? The last one? If the new update has 100 things in it (say a new kf5 version, or a rebuild of a bunch of packages with a fixed compiler) and there's 5 seperate updates already in existance, which should it let you replace builds on? all of them?

[tyll]

My opinion is that the machines should server the humans and not the other way around. If the maintainers intention is unknown, then they need to be kept in control. If automatically doing something with updates in the waiting state, they could just stay there and wait for the maintainer to submit them to testing. And if they are too old they could be garbage collected.

And if there are multiple new updates, you can ask the maintainer to merge/replace or queue the new update. But I guess usually merge or replace make sense here. And about the new update with 100 things in it, do you believe it will make the maintainer happier when they click this together on the web interface and then it will be rejected and there is no way to store this? They will probably use the CLI for this amount, but maybe not for 5-10 builds. And it is clear that denying the update is not want any maintainer wants, because they want the updates to get out somehow and Bodhi should support them to do the right thing.

[mohanboddu]

Another ticket filed with fedora releng https://pagure.io/releng/issue/10662