Update fedretire to use PDC and pagure APIs.

ralph commented

2017-06-25 14:16:21 +00:00

Contributor

This repoints fedretire to query PDC and pagure for the retired/orphaned
status of packages.

Signed-off-by: Ralph Bean rbean@redhat.com

This repoints fedretire to query PDC and pagure for the retired/orphaned status of packages. See also https://fedoraproject.org/wiki/Changes/ArbitraryBranching Signed-off-by: Ralph Bean <rbean@redhat.com>

ralph commented

2017-08-04 21:25:25 +00:00

Author

Contributor

pkgdb has entered read-only mode. Any reviewers here?

ralph commented

2017-08-05 06:06:33 +00:00

Author

Contributor

1 new commit added

Fix url.

**1 new commit added** * Fix url.

till commented

2017-08-05 21:43:08 +00:00

Contributor

The branch is not considered to check if a package is orphaned.

till commented

2017-08-05 21:49:26 +00:00

Contributor

I usually only use this to retire packages when they are orphaned long enough. So I can try it the next time packages are going to be retired. I am not sure if other people use this script as well currently. However it seems that checking whether a package is orphaned is more complex nowadays. I am wondering if it makes sense to bundle the code to get a list of orphaned/retired packages and to check this status for an individual package into a small module since similar code is required for fedretire.py, find_unblocked_orphans.py and block_retired.py.

mprahl commented

2017-08-08 18:31:41 +00:00

Contributor

That is a good point but as I understand it, Pagure over dist-git has no concept of a specific branch being orphaned. It's basically all or nothing, since a project is marked as orphaned only when the "main admin" on the project is the "orphan" user. Specific branches can be retired, and those are marked in PDC.

mohanboddu commented

2017-08-10 17:48:10 +00:00

Contributor

This is bad, what if something is changed in newer branches and the maintainer doesn't want to maintain a package anymore in newer branches or vice versa. How can we handle these kind of situations?

mprahl commented

2017-08-10 18:44:01 +00:00

Contributor

Any branches that aren't maintained would be marked as inactive in PDC by having their SLs EOL to the day those branches are orphaned or retired.

Also, those branches would have dead.package files in them.

Any branches that aren't maintained would be marked as inactive in PDC by having their SLs EOL to the day those branches are orphaned or retired. Also, those branches would have dead.package files in them.

till commented

2017-08-10 21:20:28 +00:00

Contributor

The worklflow used to be that maintainers can decide to orphan or retire packages. If the package is ok in general but the maintainer does not want to maintain a package anymore or if the maintainer is nonresponsive, the package is orphaned. This only marks the packages as being in search of a new maintainer. If the package is not useful anymore, the maintainer should retire it (only possible in EPEL, Rawhide and Branched (before the final freeze)). Alternatively releng (usually me) retires packages that are orphaned for more than 6 weeks.

mprahl commented

2017-08-11 00:06:27 +00:00

Contributor

@till, thank you for bringing that up. I forgot about the orphan period in my last comment.

@ralph may have a better idea, but here's my suggestion. In the event that a package is orphaned, perhaps we change the "main admin" to orphan in Pagure, and keep the SLs on the current Fedora release branches (e.g. f26) the same. All other branches could be set to EOL in 6 weeks if no one picks it up.

That is more or less the same workflow but with the different tools. Thoughts?

@till, thank you for bringing that up. I forgot about the orphan period in my last comment. @ralph may have a better idea, but here's my suggestion. In the event that a package is orphaned, perhaps we change the "main admin" to orphan in Pagure, and keep the SLs on the current Fedora release branches (e.g. f26) the same. All other branches could be set to EOL in 6 weeks if no one picks it up. That is more or less the same workflow but with the different tools. Thoughts?

till commented

2017-08-11 06:24:38 +00:00

Contributor

@mprahl, the thing is, that it seems to me that if the EPEL branches and the Fedora branches are maintained by different people, i.e.there is a bugzilla override for EPEL in https://pagure.io/releng/fedora-scm-requests/tree/master, the EPEL branches should not be considered orphaned when the Fedora maintainer orphans the package. Therefore checking only the main admin would not be enough.

Btw. I guess also something needs to remove bugzilla overrides from the fedora-scm-requests repo when a package is retired to make sure the information is consistent. Not sure where this would belong to.

@mprahl, the thing is, that it seems to me that if the EPEL branches and the Fedora branches are maintained by different people, i.e.there is a bugzilla override for EPEL in https://pagure.io/releng/fedora-scm-requests/tree/master, the EPEL branches should not be considered orphaned when the Fedora maintainer orphans the package. Therefore checking only the main admin would not be enough. Btw. I guess also something needs to remove bugzilla overrides from the fedora-scm-requests repo when a package is retired to make sure the information is consistent. Not sure where this would belong to.

ralph commented

2017-08-11 17:29:05 +00:00

Author

Contributor

Shoot - I missed all the conversation here.

Note, here's a related PR for orphan management -> https://pagure.io/releng/pull-request/6949

Shoot - I missed all the conversation here. Note, here's a related PR for orphan management -> https://pagure.io/releng/pull-request/6949

kevin commented

2019-04-13 20:50:13 +00:00

Owner

I'm going to just merge this since it's better than what we have.

Additional PR's welcome to fix/adjust. Discussion about per branch ownership should probibly be at a higher level than this PR. 🏤

I'm going to just merge this since it's better than what we have. Additional PR's welcome to fix/adjust. Discussion about per branch ownership should probibly be at a higher level than this PR. :european_post_office:

kevin commented

2019-04-13 20:50:56 +00:00

Owner

Pull-Request has been merged by kevin

Rows
Columns

Update fedretire to use PDC and pagure APIs. #6860