Hi Sam, > On May 13, 2017, at 7:41 PM, Sam Ruby <ru...@intertwingly.net> wrote: > > On Fri, May 12, 2017 at 6:51 PM, Craig Russell <apache....@gmail.com> wrote: >> >> I know up front that this is a second icla. So good idea for this to be a >> different action. >> (O) icla >> (O) additional icla >> (O) ccla >> >> Full Name: this is the key to find the entry in iclas.txt >> Public Name: this should replace the public name in the entry >> email: this should replace the email in the entry >> file name: this is generated from Full Name and is the directory for the >> iclas >> >> If a third icla comes in, I can handle this manually. Unless it's easy to >> put in now: >> >> if full-name/full-name.pdf (or full-name/icla.pdf and icla.pdf.asc) already >> exists: >> find the largest n in full-name/full-name<n>.pdf >> file the new icla under full-name/full-name<n+1>.pdf >> >> and replace Public Name and email in iclas.txt as for the second one. > > Handling the 'nth' case doesn't concern me. > > What does concern me is the ability to change the Full Name (and > therefore the filename). If you do that, this won't be a second ICLA, > and the code won't be able to identify an existing line in iclas.txt > to update.
Select (O) additional icla The Full Name is the key to the entry you want to change. I don't know if there are any cases where the Full Name does not exactly match the file name (modulo converting Non-US-ASCII letters to latin letters). That is, someone changed file name after filling full name. But that is not the usual case. For our purposes, we can disallow changing the file name and always take it from the full name. This might be a good thing to do for all iclas. Maybe an update to icla-lint would catch any cases where the full name and file name do not match. > > I'd like to suggest as an alternative, two fields: one identifying the > existing user, This is the full name ~== file name > and one identifying the new email address. This is the email address > This should > handle the bulk of the additional icla requests. Anything else can be > done manually? We also should allow updating the Public Name if it is different from what is in iclas.txt. Once the secretary enters the full name, the iclas.txt entry can be brought up and the existing public name and email (and file name) displayed read-only. The proposed new public name and email are taken from the incoming mail. Secretary can change public name and email depending on what the new icla says. The new workflow: Categorize (O) icla fill all fields File Warning: documents/iclas/craig-russell.pdf already exists Categorize (O) additional icla fill Full Name tool locates iclas.txt entry and displays read-only file name and two new fields Existing public name and Existing email tool fills public name and email from incoming mail secretary reviews and possibly changes public name and email File secretary reviews proposed changes continue Craig > > - Sam Ruby Craig L Russell Secretary, Apache Software Foundation c...@apache.org http://db.apache.org/jdo
