I just talked with Ken Reilly, one of RH's engineering managers. We are trying to solve the CLA problem, where legal surprised us by allowing Red Hat contributors to Fedora under Red Hat's CLA instead of Fedora's CLA. We both realize there are potential problems in this, but there is urgency to allow Red Hat CLA very soon because this blocks many Red Hat engineers from creating Fedora Accounts as we approach the merge.
Below is an initial simple implementation to enable this very quickly. Luckily however, the groups shouldn't get in our way to further improve this process later.
One Time Changes ================ 1) Existing cla_done is cloned to fedora_cla. 2) dell_cla group is created, Matt adds whoever he wants. Remove dell_cla members from fedora_cla. 3) redhat_cla group is created, populated through various means. 4) Modify existing Fedora CLA signing process to join fedora_cla instead of cla_done.
Automatic Changes Thereafter ============================ fedora_cla auto adds to cla_done redhat_cla autoadds to cla_done dell_cla autoadds to cla_done Toshio's cvsextras -> fedorabugs code should work in these cases too?
redhat_cla Management ===================== 1) (one time) Dump dist-fc7 package owners, match e-mail addresses with FAS accounts, add all those to redhat_cla. 2) (one time) Add everyone else that we know about who currently doesn't match e-mail addresses. 3) Give kreilly admin access to the redhat_cla group, so he can add/remove members in an interim. 4) Later give RH GIS access, so they can make it part of their standard "new employee" or "remove employee" process.
See any problems in this? Please comment.
We need this implemented REAL SOON, hopefully by tomorrow.
Warren Togami wtogami@redhat.com
On Thu, Mar 29, 2007 at 03:55:15PM -0400, Warren Togami wrote:
I just talked with Ken Reilly, one of RH's engineering managers. We are trying to solve the CLA problem, where legal surprised us by allowing Red Hat contributors to Fedora under Red Hat's CLA instead of Fedora's CLA. We both realize there are potential problems in this, but there is urgency to allow Red Hat CLA very soon because this blocks many Red Hat engineers from creating Fedora Accounts as we approach the merge.
Below is an initial simple implementation to enable this very quickly. Luckily however, the groups shouldn't get in our way to further improve this process later.
One Time Changes
- Existing cla_done is cloned to fedora_cla.
- dell_cla group is created, Matt adds whoever he wants. Remove
dell_cla members from fedora_cla.
Per the Corporate CLA, anyone in dell_cla needs to be an admin for dell_cla, so they can add/remove people. Is that doable too?
- redhat_cla group is created, populated through various means.
- Modify existing Fedora CLA signing process to join fedora_cla instead
of cla_done.
Automatic Changes Thereafter
fedora_cla auto adds to cla_done redhat_cla autoadds to cla_done dell_cla autoadds to cla_done Toshio's cvsextras -> fedorabugs code should work in these cases too?
redhat_cla Management
- (one time) Dump dist-fc7 package owners, match e-mail addresses with
FAS accounts, add all those to redhat_cla. 2) (one time) Add everyone else that we know about who currently doesn't match e-mail addresses. 3) Give kreilly admin access to the redhat_cla group, so he can add/remove members in an interim. 4) Later give RH GIS access, so they can make it part of their standard "new employee" or "remove employee" process.
See any problems in this? Please comment.
+1.
On Thu, Mar 29, 2007 at 05:48:51PM -0400, Warren Togami wrote:
Matt Domsch wrote:
Per the Corporate CLA, anyone in dell_cla needs to be an admin for dell_cla, so they can add/remove people. Is that doable too?
As long as Dell is responsible for decisions made by granted members, I suppose this is fine.
Yes. I wanted to avoid me personally being the only party who could edit the list, and without getting lawyers involved on a per-person basis, which is why the language is what it is.
Thanks, Matt
On Thu, 2007-03-29 at 15:55 -0400, Warren Togami wrote:
One Time Changes
- Existing cla_done is cloned to fedora_cla.
- dell_cla group is created, Matt adds whoever he wants. Remove
dell_cla members from fedora_cla. 3) redhat_cla group is created, populated through various means. 4) Modify existing Fedora CLA signing process to join fedora_cla instead of cla_done.
So without ever having looked at the FAS schema before today, and never having tested this code, I think that this will clone the cla_done to fedora_cla and create the dell_cla and redhat_cla groups...
insert into project_group (name, owner_id, group_type) values ('fedora_cla', (SELECT id FROM person WHERE username = 'admin'), 'tracker');
insert into project_group (name, owner_id, group_type) values ('redhat_cla', (SELECT id FROM person WHERE username = 'wtogami'), 'tracker');
insert into project_group (name, owner_id, group_type) values ('dell_cla', (SELECT id FROM person WHERE username = 'admin'), 'tracker');
insert into role (person_id, project_group_id, role_type, role_domain, role_status, internal_comments, sponsor_id, creation, approval) values (select a.person_id, b.id, a.role_type, a.role_domain, a.role_status, a.internal_comments, a.sponsor_id, a.creation, a.approval) from role a, project_group b where a.project_group_id is (select id from project_group where name = 'cla_done') and b.id is (select id from project_group where name = 'fedora_cla');
On Thu, 2007-03-29 at 16:41 -0500, Jeffrey C. Ollie wrote:
On Thu, 2007-03-29 at 15:55 -0400, Warren Togami wrote:
One Time Changes
- Existing cla_done is cloned to fedora_cla.
- dell_cla group is created, Matt adds whoever he wants. Remove
dell_cla members from fedora_cla. 3) redhat_cla group is created, populated through various means. 4) Modify existing Fedora CLA signing process to join fedora_cla instead of cla_done.
So without ever having looked at the FAS schema before today, and never having tested this code, I think that this will clone the cla_done to fedora_cla and create the dell_cla and redhat_cla groups...
insert into project_group (name, owner_id, group_type) values ('fedora_cla', (SELECT id FROM person WHERE username = 'admin'), 'tracker');
insert into project_group (name, owner_id, group_type) values ('redhat_cla', (SELECT id FROM person WHERE username = 'wtogami'), 'tracker');
insert into project_group (name, owner_id, group_type) values ('dell_cla', (SELECT id FROM person WHERE username = 'admin'), 'tracker');
insert into role (person_id, project_group_id, role_type, role_domain, role_status, internal_comments, sponsor_id, creation, approval) values (select a.person_id, b.id, a.role_type, a.role_domain, a.role_status, a.internal_comments, a.sponsor_id, a.creation, a.approval) from role a, project_group b where a.project_group_id is (select id from project_group where name = 'cla_done') and b.id is (select id from project_group where name = 'fedora_cla');
Tested this on an extremely small subset of the fas db. It just needed a few minor changes to the syntax of copying the role::
insert into project_group (name, owner_id, group_type) values ('fedora_cla', (SELECT id FROM person WHERE username = 'admin'), 'tracker');
insert into project_group (name, owner_id, group_type) values ('redhat_cla', (SELECT id FROM person WHERE username = 'wtogami'), 'tracker');
insert into project_group (name, owner_id, group_type) values ('dell_cla', (SELECT id FROM person WHERE username = 'admin'), 'tracker');
insert into role (person_id, project_group_id, role_type, role_domain, role_status, internal_comments, sponsor_id, creation, approval) select a.person_id, b.id, a.role_type, a.role_domain, a.role_status, a.internal_comments, a.sponsor_id, a.creation, a.approval from role a, project_group b where a.project_group_id in (select id from project_group where name = 'cla_done') and b.id in (select id from project_group where name = 'fedora_cla');
On Thursday 29 March 2007 15:55:15 Warren Togami wrote:
- Later give RH GIS access, so they can make it part of their standard
"new employee" or "remove employee" process.
See any problems in this? Please comment.
Surely being hired by Red Hat doesn't grant an immediate Fedora account? Is GIS going to be pre-creating Fedora accounts for every new RH hire? Removing I can see sure, but adding I'm leery of.
Once upon a time Thursday 29 March 2007, Jesse Keating wrote:
On Thursday 29 March 2007 15:55:15 Warren Togami wrote:
- Later give RH GIS access, so they can make it part of their standard
"new employee" or "remove employee" process.
See any problems in this? Please comment.
Surely being hired by Red Hat doesn't grant an immediate Fedora account? Is GIS going to be pre-creating Fedora accounts for every new RH hire? Removing I can see sure, but adding I'm leery of.
I told warren he needs to run this whole idea by the board. As it is something that effects the entry path into Fedora. It has to have approval from them. This can have far reaching implications.
So until the borad ok's it nothing can be implemented. everything can be developed just not implemented.
Dennis
On Fri, 2007-03-30 at 00:00 -0500, Dennis Gilmore wrote:
Once upon a time Thursday 29 March 2007, Jesse Keating wrote:
On Thursday 29 March 2007 15:55:15 Warren Togami wrote:
- Later give RH GIS access, so they can make it part of their standard
"new employee" or "remove employee" process.
See any problems in this? Please comment.
Surely being hired by Red Hat doesn't grant an immediate Fedora account? Is GIS going to be pre-creating Fedora accounts for every new RH hire? Removing I can see sure, but adding I'm leery of.
I told warren he needs to run this whole idea by the board. As it is something that effects the entry path into Fedora. It has to have approval from them. This can have far reaching implications.
So until the borad ok's it nothing can be implemented. everything can be developed just not implemented.
FYI -- the board okayed this at today's meeting.
Jeremy
Jesse Keating wrote:
On Thursday 29 March 2007 15:55:15 Warren Togami wrote:
- Later give RH GIS access, so they can make it part of their standard
"new employee" or "remove employee" process.
See any problems in this? Please comment.
Surely being hired by Red Hat doesn't grant an immediate Fedora account? Is GIS going to be pre-creating Fedora accounts for every new RH hire? Removing I can see sure, but adding I'm leery of.
Oops, I didn't mean GIS handle the adding part, only removal.
Warren
On Fri, 2007-03-30 at 12:16 -0400, Warren Togami wrote:
Jesse Keating wrote:
On Thursday 29 March 2007 15:55:15 Warren Togami wrote:
- Later give RH GIS access, so they can make it part of their standard
"new employee" or "remove employee" process.
See any problems in this? Please comment.
Surely being hired by Red Hat doesn't grant an immediate Fedora account? Is GIS going to be pre-creating Fedora accounts for every new RH hire? Removing I can see sure, but adding I'm leery of.
Oops, I didn't mean GIS handle the adding part, only removal.
And the account is being added as a member of cla_done rather than cvsextras, cvsdocs, etc. So it's really stating that you've cleared the legal hurdles to be a contributor, not that you're actually a member of any of the groups that will take your work.
Of course, there are some things that have been discussed in the past hinging on cla_done (voting for the Fedora Board, for instance) that will need to depend on something else if this is implemented. I'm not aware of anything that's actually in production, however.
-Toshio
On Thu, 2007-03-29 at 15:55 -0400, Warren Togami wrote:
One Time Changes
[...]
- Modify existing Fedora CLA signing process to join fedora_cla instead
of cla_done.
Automatic Changes Thereafter
fedora_cla auto adds to cla_done redhat_cla autoadds to cla_done dell_cla autoadds to cla_done Toshio's cvsextras -> fedorabugs code should work in these cases too?
Patch attached to handle these two things. Notes:
1) This is untested code and could contain bugs. Please test that it does what it's supposed to when applying for a new Fedora Individual CLA and being approved for cvsextras.
2) This obsoletes my previous patch to auto-add fedorabugs when a person is approved for cvsextras.
-Toshio
infrastructure@lists.fedoraproject.org
-
Dennis Gilmore -
Jeffrey Ollie -
Jeremy Katz -
Jesse Keating -
Matt Domsch -
Toshio Kuratomi -
Warren Togami