find-inactive-packagers/SOP.md

SOP for periodic inactive packagers removal

The inactive packagers removal policy is performed through the use of the find_inactive_packagers.py script.

Setting up the script

Download the git repo and make sure your system (or your virtualenv) has fasjson_client and bugzilla installed. You will also need to acquire a kerberos ticket to the Fedora infrastructure - the esiest way is to use fkinit command provided by fedora-packager-kerberos package.

Then, set up some settings provided at the start of the script file. You will need to provide a Bugzilla API key (mandatory) and a Pagure API key (optional, only needed to manage tickets, but the script can also be used "read-only" for testing purposes). Other settings should be fine with their defaults.

Step one: identify inactive packagers

The first step of the policy is to identify packagers that show no activity in the Fedora ecosystem in the last year. This is done by running:

python find_inactive_packagers.py step-one

or:

python find_inactive_packagers.py step-one --open-tickets

Both command will fetch the packagers list and look in several Fedora related systems for activity of each user. It may take a lot of time, depending on the number of packagers and their activity.

The --open-tickets option MUST only be used by the Fedora PGM when running the policy. If you want to test the opening tickets functionality, please change PAGURE_API_BASE_URL settings to a testing repository of your own and remove the @ from PING_INACTIVE_TEXT, otherwise users will be mentioned and notified about these testing tickets!

The command will provide a inactive_packagers.csv file, listing detected inactive packagers usernames, the opened ticket id (if --open-tickets) and the list of emails associated to the packager. An extensive log is also provided, if you plan to share the log for debugging purpose you may want to run the commands with the --privacy flag, so that emails are masked in the logs.

Managing tickets

The script will open one ticket for each packager detected as inactive. Those tickets are tagged inactive_packager to enable automatic ticket managing.

At this point a user can reply to a ticket in two ways:

• if the user replies that they want to maintain the packager status, the ticket must be closed as Keep packager status.
• if the user agrees to be removed from packagers, do not manually close the ticket, but add the asked_removal tag. The ticket will be closed automatically on step two.

Optional intermediate step: check packages going to be orphaned

Once tickets against inactive packagers are opened, you may want to check how many and what packages will be orphaned when the affected packagers will be removed from the packagers group. To make that run:

python find_inactive_packagers.py check-impact

This command will fetch the list of open tickets and provide a list of packages which are possibly going to be orphaned or which will surely be orphaned (for those tickets which were tagged asked_removal). Please note that this is based only on the opened tickets, there's no check about recent activity from the user.

Step two: provide the final list of inactive packagers

The step two of the policy will look for packagers which didn't reply to the inquiry ticket and, like the step one, can be run "read-only":

python find_inactive_packagers.py step-two

or not (reserved to the Fedora PGM):

python find_inactive_packagers.py step-two --close-tickets

The output file still_inactive.csv will be the final list of usernames to be removed from the packagers group. If the command is run with --close-tickets, it will automatically close tickets in the right way. That means that if a user didn't reply to the ticket, but the script detects recent activity of the same user, the ticket will be closed as Keep packager status and will not add the username to the list of users going to be removed.