On Jun 10, 2017, at 6:28 PM, Sam Ruby <ru...@intertwingly.net> wrote: > > On Sat, Jun 10, 2017 at 8:13 PM, Craig Russell <apache....@gmail.com> wrote: >> Hi Sam, >> >> I totally missed this email in the forest. > > It happens :-) > >>> 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? > > There is no round-trip to the server as you make your data entry. > When you select additional icla, I download the entries in iclas.txt > that are NOT notinavail and all searching is done on the client. > >> The more I test this the more I want it as part of the Categorize menu, just >> above Links. > > Just so I'm clear, it is currently a part of the Categorize menu, > where you originally asked for it: > > https://github.com/apache/whimsy/blob/master/www/secretary/workbench/views/parts.js.rb#L104 > > You now want this moved down to about here: > > https://github.com/apache/whimsy/blob/master/www/secretary/workbench/views/parts.js.rb#L159 > > Easy enough.
It's a bit hard for me to tell whether it belongs at line 104 or 159. Right now, it's part of the Additional ICLA menu. I'd prefer it to be part of the Categorize menu so I can take a look before I have to choose whether it's an icla or additional icla. Just the Search field and the list of candidates below. Not the Current Values and Updated Values. Craig > >>> >>>> (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> > > It looks like the secretarial team (and therefore whimsy) can update > mail addresses: > > https://github.com/apache/infrastructure-puppet/blob/deployment/modules/ldapserver/templates/slapd.conf.erb#L159 > >> 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. > > OK, easy enough. > >> Craig >>> >>>> 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!
