Hi Sam, I totally missed this email in the forest.
> On May 20, 2017, at 7:56 AM, Sam Ruby <ru...@intertwingly.net> wrote: > > On Mon, May 15, 2017 at 5:31 PM, Craig Russell <craig.russ...@oracle.com> > wrote: >> >>> 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>_________ > > Client side logic is roughed in. Looks great! The search field is really responsive. Did you cache the entire iclas.txt file? The more I test this the more I want it as part of the Categorize menu, just above Links. > >> (File) >> >> And then the fun of fitting the new icla into the documents/iclas/ directory >> begins. > > Looking at the server logic, if I were to submit a new icla (not that > I have any need to), > > Step 1 would be to mkdir sam-ruby and move sam-ruby.pdf to sam-ruby/icla.pdf > > Step 2 would be create sam-ruby/icla2.pdf > > Step 3 would be to update iclas.txt with new email (and possibly new > public name) > > Step 4 would be to send out an email. > > Notes: > > 1) Step 1 wouldn't be done if iclas/sam-ruby already existed > > 2) Step 2 would use icla3 or icla4 or whatever until a unique number is found > > Questions: > > 1) would it be icla.pdf or icla1.pdf in step 1? icla.pdf > > 2) who should the email go out to and what should be in the email? To: the sender, <root@ if infra needs to do something> cc: everyone on the bcc: and cc: lists, the email in the iclas.txt file, the apache...@apache.org, and secretary. Dear <public name>, This message acknowledges receipt of your additional ICLA, which has been filed in the Apache Software Foundation records. <one of the paragraphs below> Warm regards, -- standard footer If infra needs to update the forwarding email address, add something like this to the email above: With this email, our administrators are requested to update the forwarding email in our records for <apache-id> to <new email address> so you can change your password using https://id.apache.org . If whimsy can update the forwarding email address to enable id.apache.org password change, add: You can change your password using https://id.apache.org . > > 3) is it worth trying to send an email to the old email address so > that they know of the change? Yes, it would normally bounce, but if > it didn't... Yes. Any time something like this happens I try to notify all known addresses. We have a similar situation right not with someone who wants a new identity and I have included all known addresses in the recent dialog. Craig > >> Craig > > - Sam Ruby Craig L Russell Secretary, Apache Software Foundation c...@apache.org http://db.apache.org/jdo
