On 27 July 2018 at 00:33, Craig Russell <[email protected]> wrote:
> I stand corrected.
>
>> On Jul 25, 2018, at 3:04 AM, sebb <[email protected]> wrote:
>>
>> On 23 July 2018 at 18:50, Craig Russell <[email protected]> wrote:
>>> Looks like there are a couple of issues here.
>>>
>>> The entries in new-account-reqs.txt that have not been processed are
>>> incorrect. It looks like the Public Name was put into the Full Name field.
>>
>> Are you sure?
>>
>> I thought the Full Name field was only used in iclas.txt.
>>
>> AFAIK there is no LDAP attribute for the Legal Name (it would need to
>> be private)
>
> Right. So we have to deal with new account requests with a single name in the
> second field.
>>
>>> This is probably just a bug in the code that creates the new account
>>> request. Is the same code used in whimsy.new account creation and in
>>> workbench.new account creation? Can anyone confirm?
>>
>> I suspect the format of new-account-reqs.txt assumes that the second
>> field is the 'cn' attribute and can be space-split to produce
>> givenName and sn.
>>
>> This only works consistently if the Public Name consists of exactly two
>> words.
>>
>> I suspect the new-account-reqs.txt layout needs to be adjusted to
>> include the 3 fields:
>> cn
>> sn
>> givenName
>
> How about this:
>
> cn = name with no changes
> sn = name.split(' ').last
Does not work well for Spanish surnames.
> givenName = name.split(' ').first
In all the above I think name needs to be the Public Name otherwise
there is no point in asking for it.
> Or as Sebb suggests, split name into three fields in the account request so
> we don't need to go back and fix e.g. William J. Rowe Jr.
>
> Then both new account request and workbench whimsy programs would need to be
> amended to include all three fields (my favorite choice).
If the split is done by Whimsy, the fields can be pre-populated as
above and the Secretary can make any adjustments as needed.
The new account processing then just does what it is told; it does not
need to do any name massaging.
If we log instances where manual changes have to be made, that might
allow better algorithms to be developed.
> Craig
>>
>>
>>
>>> Craig
>>>
>>>> Begin forwarded message:
>>>>
>>>> From: Chris Thistlethwaite <[email protected]>
>>>> Subject: Re: New Account doesn't have full name
>>>> Date: July 23, 2018 at 8:43:38 AM PDT
>>>> To: Craig Russell <[email protected]>
>>>> Cc: Secretary <[email protected]>, [email protected]
>>>>
>>>> Agreed, single named committers exist, I'm not sure how they were
>>>> created (like in the FJ instance, manually edited, then later cleaned
>>>> up in LDAP).
>>>>
>>>> The problem is that Gerben has a full name that didn't get into new-
>>>> account-reqs.txt, instead it was just Public Name
>>>>
>>>> From iclas.txt
>>>> notinavail:Gerben van den Broeke:Gerben:[email protected]:Signed
>>>> CLA;gerben-van-den-broeke
>>>>
>>>> but in new accounts it's:
>>>> gerben;Gerben;[email protected];incubator;incubator;07-14-
>>>> 2018;yes;yes;no
>>>>
>>>> It's two problems, Public Name is being confused with something else so
>>>> when people fill out the ICLA, the just put whatever in there.
>>>> Secondly, some script/workflow/process is using Public Name over Full
>>>> Name. I just don't know enough of the flow of signed ICLA being
>>>> submitted to it getting into new-account-reqs.txt for us to create the
>>>> account.
>>>>
>>>> -Chris T.
>>>>
>>>> On Mon, 2018-07-23 at 07:45 -0700, Craig Russell wrote:
>>>>> Hi Chris,
>>>>>
>>>>> I'm very confused.
>>>>>
>>>>> We have committers with a single name. They are rare but they exist.
>>>>>
>>>>> If there is an issue where some scripts insist on two names in either
>>>>> Public Name or Full Name then the scripts need to be fixed.
>>>>>
>>>>> I looked just now at the account request form and tried Gerben and
>>>>> everything looks fine there.
>>>>>
>>>>> Where is the problem exactly?
>>>>>
>>>>> We recently changed LDAP and now have some extra fields. Maybe we
>>>>> need to discuss mapping ICLA form to LDAP entries?
>>>>>
>>>>> Craig
>>>>>
>>>>>> On Jul 23, 2018, at 4:04 AM, Chris Thistlethwaite <[email protected]
>>>>>> g> wrote:
>>>>>>
>>>>>> So we have two more new account submissions that are missing "Full
>>>>>> Name". While the script is in need of updating, there seems to be
>>>>>> something missing upstream. Perhaps the wording around "Public
>>>>>> Name" on
>>>>>> the ICLA needs to be clarified (as per INFRA-16752). I don't know
>>>>>> which
>>>>>> tool/process creates the new-account-req.txt file, but that should
>>>>>> always take first/last name instead of Public Name.
>>>>>>
>>>>>> I understand that not everyone/all cultures use First/Last name,
>>>>>> but in
>>>>>> order for us to automate this process in the future (hopefully)
>>>>>> this
>>>>>> manual check of the ICLA wouldn't work.
>>>>>>
>>>>>> -Chris T.
>>>>>>
>>>>>>
>>>>>> On Mon, 2018-07-09 at 22:45 +0100, sebb wrote:
>>>>>>> I see you editted the file to change the field to FJ FJ.
>>>>>>>
>>>>>>> It would be better to fix the script to handle the original entry
>>>>>>> as
>>>>>>> the result is not correct.
>>>>>>>
>>>>>>> The cn should be FJ, not FJ FJ.
>>>>>>>
>>>>>>> On 9 July 2018 at 19:03, Chris Thistlethwaite <[email protected]>
>>>>>>> wrote:
>>>>>>>> That's fine with me, I wanted to make sure there wasn't some
>>>>>>>> upstream
>>>>>>>> error before creating the account.
>>>>>>>>
>>>>>>>> -Chris T.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, 2018-07-09 at 16:02 +0100, sebb wrote:
>>>>>>>>> On 9 July 2018 at 15:21, Chris Thistlethwaite <christ@apache.
>>>>>>>>> org>
>>>>>>>>> wrote:
>>>>>>>>>> Just hit an error where a new account doesn't have a full
>>>>>>>>>> first/last
>>>>>>>>>> name.
>>>>>>>>>>
>>>>>>>>>> fjy;FJ;[email protected];incubator,druid;incubator;07-
>>>>>>>>>> 07-
>>>>>>>>>> 2018;yes;yes;no;
>>>>>>>>>>
>>>>>>>>>> Do we have more detail on FJ?
>>>>>>>>>
>>>>>>>>> The ICLA shows the public name as just FJ
>>>>>>>>>
>>>>>>>>> https://svn.apache.org/repos/private/documents/iclas/fangjin-
>>>>>>>>> yang
>>>>>>>>> .pdf
>>>>>>>>>
>>>>>>>>> I don't think we can insist on there being two names (cf.
>>>>>>>>> Upayavira)
>>>>>>>>> nor on how long the public names are.
>>>>>>>>>
>>>>>>>>> If the script cannot handle FJ then IMO that is a problem
>>>>>>>>> that
>>>>>>>>> has to
>>>>>>>>> be fixed in the script.
>>>>>>>>>
>>>>>>>>> I'm guessing the problem is that it is trying to split the
>>>>>>>>> name
>>>>>>>>> into
>>>>>>>>> sn and givenName.
>>>>>>>>> If so, just set them both to FJ (this is how Upayavira is
>>>>>>>>> treated)
>>>>>>>>>
>>>>>>>>>> -Chris T.
>>>>>
>>>>> Craig L Russell
>>>>> Secretary, Apache Software Foundation
>>>>> [email protected] http://db.apache.org/jdo
>>>>>
>>>
>>> Craig L Russell
>>> Secretary, Apache Software Foundation
>>> [email protected] http://db.apache.org/jdo
>>>
>
> Craig L Russell
> Secretary, Apache Software Foundation
> [email protected] <mailto:[email protected]> http://db.apache.org/jdo
> <http://db.apache.org/jdo>
