Stephen Hahn wrote: >> The problem we have is that we have no reliable way of identifying Sun >> employees in the current OSO database. There is a employee_id column, >> but there's nothing to check it is filled in correctly, or even at all. >> Email addresses are no use either. And if we don't mandate that SWAN >> and OSO usernames are the same, the problem gets even harder still. > > I'm not sure what the problem is: ON (and other consolidations) > should not be granting commit rights to a user without either a > contributor agreement or a membership in an organization with a > contributor agreement. Has a consolidation done so?
I'm not suggesting that this has happened, but as far as I know there is currently no mandatory checking of SCAs prior to commit, either manual or automatic. because all commits are proxied by a sponsor, we have traceability and we are depending on the sponsor to do the checks, but as far as I know it is not enforced. Once the gate moves outside we will need such checks to be automated, otherwise the manual burden will become unreasonable. We also have the issue of who actually grants commit rights - is this going to be by a central body, or are the GCs and projects that make up ON going to manage their own committers? > (I am assuming that the employee_id is only editable by site > administrators, and is presumed valid.) It is a user-editable field in the current system. I'm not intending in replicating that in the new system, but when we migrate we will have to validate/insert the correct values for all migrated users, and we need a process to ensuring that the data stays in step with reality, e.g. when people leave/join. -- Alan Burlison --
