= phenomenon =
We're switching from the present CLA to a new text, the FPCA:
We want to achieve this switchover by F15 which means that we need to do a bit of coding work and a whole lot of record keeping and nag mails.
All the contributors who have signed the CLA will need to sign the new FPCA. The desire is to give people about a month's window to log into FAS and click to sign the FPCA before we would have to show that they are no longer in cla_done and therefore no longer able to be in most other groups (packager, sysadmin, etc.)
= implementation recommendation =
== Decisions to make ==
== Initial Steps ==
=== Information gathering ===
* Look for all files owned by any user on any of our actual systems so that we can chase those people down to get them signed EARLY so there is no risk of files suddenly lacking an owner if they lapse on cla_done.
* test file paths on fedorapeople.org so there's no risk there of people's files (or repos.fp.o paths) evaporating in odd ways
* check cron jobs for the above, too
* grep through puppet for occurrences of cla_fedora. These will need to be replaced with cla_fpca when we upgrade fas
* grep through puppet for occurrences of cla_done. These will need to be checked for potential problems when we start moving people out of cla_done.
=== Coding ===
==== FAS ====
1. Change FAS code to register people for cla_fpca (the naming isn't great but I bet we have places where the wildcard cla_* is assumed) instead of cla_fedora
2. Change fas to display the text of the fpca instead of the cla
3. Roll this changed fas out to staging and test that:
1. New signups get the fpca text and get added to both cla_fpca and cla_done
2. Existing users with cla_fedora get prompted to sign the fpca when they login
3. Existing users with cla_fedora are able to sign the fpca and get added to cla_fpca
4. Make sure that changes to enable this make it into puppet
5. write an sql query to remove people from cla_done if they are in cla_fedora and nothing else.
==== Other scripts ====
Chances are if there's other scripts that use cla_fedora they should either be ported to cla_fpca or cla_done and it should be pretty easy to tell which.
== Pulling the trigger ==
Note that removal from cla_done will trigger some cascading effects -- removing people from packager, for instance. So this final step will likely cause a certain amount of chaos. I'm certain that it will leave koji, pkgdb, fedorapeople.org, etc with contributors who are no longer eligible to be there and we'll need to go through and fix those.
We'll need to decide how much information from these we want to keep (backed up or otherwise made easy to restore) and how much we just want to get rid of. Backing up things that are in the databases won't be easy but may be necessary.
Other scripts: scripts to remove people from pkgdb, koji, etc who no longer have cla_done.
Here's the text of the fpca: http://fedoraproject.org/wiki/Legal:Fedora_Project_Contributor_Agreement
Few more todos:
=== FAS changes ===
* Try to figure out method to not strip group memberships
* fedorapeople: test that when they're taken out of cla_done, the home directory is just moved (and can be restored)
=== Puling the trigger ===
* Run packager and ambassador metrics to determine if we need to extend the transition period
I've created a hacky little script in ~kevin/fpca-check on fedorapeople to show the number of users who are in cla_fpca and number that would be removed if cla_fedora was removed.
Looks like we had about 350 new folks in cla_fpca in the last day or so.
I've been running fpca-metric.py on bapp01 and uploading the results to http://toshio.fedorapeople.org/fpca
We're currently down to 999 non-signers, 89 of which are package owners leaving 450 packages orphaned if we pull the trigger today. There are numerous people who would be dropped from cla requiring groups but none of them are admins of groups. Here's my proposal for what to do:
This week's infra meeting (the June 17th deadline), we'll look at:
If non-zero, we'll decide what the numbers should be and I'll send an email to tell people what packages are soon to be orphaned/help people pick them up manually. If we haven't hit our target number of non-signers, we'll push the deadline back a few weeks and continue weekly spamming. If we have, we'll give people a week to pre-pickup to-be-orphaned packages and then pull the trigger next week.
If anyone wants to propose metrics/additional metrics/notices specific packages on http://toshio.fedorapeople.org/fpca/packages_losing_owner.txt that they want to make sure are taken care of, please let me know.
The group admins are tougher. However, a large number of the groups are for hosted groups. One option is to set all of the hosted groups to not require cla_done since this isn't strictly necessary -- I don't know if we want to get permission from the groups to do that, though -- which would put us in the same position of getting feedback from group admins that may have already proved unresponsive to signing the FPCA :-( Any ideas here?
Plan for doing the FAS part of this:
Back up the person_roles table.
CREATE TABLE person_roles_fpca AS SELECT * FROM person_roles;
Delete all memberships that depended on CLA (toshio has this query)
Once somebody has signed the FPCA, they can contact us to have their group membership restored. We should make it clear in the emails that they should do this instead of reapplying to groups (otherwise, this query might fail due to duplicate rows, which will then have to be deleted manually).
INSERT INTO person_roles SELECT * FROM person_roles_fpca WHERE person_id=(SELECT id FROM people WHERE username='$USERNAME') AND (SELECT prerequisite_id FROM groups WHERE id=group_id)=100002;
Hosted groups which had members that had not signed the FPCA have had the requirement for cla_done removed (since that was likely only there for historical reasons, not intentional or policy driven).
An email was sent to the administrators of those groups telling them of the change, reason for it, and if they wanted to change the value back, to contact us (via trac ticket) so that we could remove the people who had not signed the FPCA when we set it to require cla_done (current FAS web UI code would set the pre-req but not check the people who are currently in the group so we have to do this manually.)
This leaves us with the following groups/admins:
magazine acapur [only admin]
sysadmin-spin kanarip [only admin]
fedora-emea-board kanarip [only admin]
I'l send each admin an email to see if they will sign the FPCA but if not it looks like there's a backup admin for everything that counts (unless emea-board is still active).
Statistics updated at http://toshio.fedorapeople.org/toshio/fpca/
Okay, following steps were taken today:
I'll attach some logs of the actions taken to see who lost what rights and then close this ticket.
Packages orphaned because the owner was being removed from cla_done
List of people losing commit or approveacls on specific package branches
Members being removed from groups that required the cla
Needed to coordinate with transifex.net as well. They have FPCA re-signing as part of their webUI and db. Composed an email for them to send out to translators who haven't signed the FPCA in transifex and they're going to remove non-FPCA signers on Friday.
to comment on this ticket.
Copyright © 2014-2016 Red Hat