Learn more about these different git repos.
Other Git URLs
See https://pagure.io/fedora-infrastructure/issue/10181
When unretiring a package a script which sets the package owner to the new user is run. As pointed in the infrastructure ticket linked above, the unretire script should also take care of removing any entry in the orphan_reason table of pagure-dist-git.
orphan_reason
Either the script should be adjusted to take care of that, or the take_orphan endpoint of pagure-dist-git can be adjusted to take a 'user' parameter as input, so that the script can just use that endpoint.
take_orphan
ASAP
When is this no longer needed or useful? (YYYY/MM/DD)
If we cannot complete your request, what is the impact?
If a spurious entry remains in the orphan_reason table, users could (will) experience issues when trying to orphan the package again.
Metadata Update from @mohanboddu: - Issue tagged with: low-gain, low-trouble, ops
@mattia Can you explain it a bit more, I think I am confused.
Thanks.
For the stand up meeting today
[14:16:59] <nirik> if you orphan a package via the button on src.fedoraproject.org... [14:17:05] <nirik> then someone takes it [14:17:28] <nirik> or then it gets retired rather [14:17:36] <nirik> then someone unretires it. [14:17:41] <nirik> and tries to orphan it [14:17:52] <nirik> it fails because there's still the old orphan reason
Is that what you meant?
Metadata Update from @mohanboddu: - Issue untagged with: low-gain, low-trouble - Issue tagged with: medium-gain, medium-trouble
@mohanboddu basically, when a package is orphaned, pagure-dist-git plugin adds an entry to the orphan_reason table.
Then, if a user un-orphan the package by the "take" button in web UI, the entry point takes care of assigning the package AND removing the entry in the orphan table.
From the infra ticket I linked above, it seemed that there were a lot of unretired packages which still had an entry in the orphan table. In that case, a user trying to orphan the package was unable to do so because pagure tries to add a new entry in the orphan table, but it found that there's already an entry for that project, thus it fails the unique key check. I think this happens because the releng script used to un-retire and assign packages do not remove the entry in the orphan table. I may be wrong, but it seems reasonable. Recently un-retired packages by releng showed that spurious entry in the orphan table.
Thanks @mattia for the explanation, now I understood it properly.
Pinging @pingou to understand how to remove the orphan_reason so that we can implement it in unretiring process.
So looking at the pagure-distgit plugin I think updating take_orphan_endpoint with optional user parameter and updating our scripts to use it is the preferred way by me.
Login to comment on this ticket.