> On May 15, 2017, at 12:38 PM, Sam Ruby <ru...@intertwingly.net> wrote: > > On Mon, May 15, 2017 at 11:54 AM, Craig Russell <apache....@gmail.com> wrote: >> 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. > > The part of the 5th field after a semicolon is, indeed, a key field. > Many of which reflect decisions that were made before the workbench > existed, or before I was secretary for that matter. :-) > >>> I'd like to suggest as an alternative, two fields: one identifying the >>> existing user, >> >> This is the full name ~== file name > > I was thinking of a field like the one present here: > https://whimsy.apache.org/roster/committer/ > > You will be able to enter a name, and id, or an email, and it will > find the correct entry. It could then display the full name value for > confirmation.
This would be excellent. I don't know though if the committer roster interaction is simple enough to copy for secmail tool. If so: (O) additional icla search: _______________ existing Full Name: <from iclas.txt> existing Public Name: <from iclas.txt> existing email: <from iclas.txt> proposed Public Name: ________<from email>______ proposed email: _____<from email>_________ (File) And then the fun of fitting the new icla into the documents/iclas/ directory begins. Craig > >>> 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. > > Seems reasonable. > >> 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 > > WFM. I would also guess that in many cases the email text will > indicate that this is a replacement ICLA, and you can skip a few > steps. > >> Craig >>> >>> - Sam Ruby >> >> Craig L Russell >> Secretary, Apache Software Foundation >> c...@apache.org http://db.apache.org/jdo > > - Sam Ruby Craig L Russell Architect craig.russ...@oracle.com P.S. A good JDO? O, Gasp!
