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.

> (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?

2) who should the email go out to and what should be in the email?

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...

> Craig

- Sam Ruby

Reply via email to