ICU port?

[Tijl Coosemans]

On Sat, 10 Dec 2016 23:23:05 -0800 "Steven R. Loomis" <srl at icu-project.org> wrote:
> El 12/10/16 7:04 AM, "Tijl Coosemans" <tijl at freebsd.org> escribió:
>> On Fri, 09 Dec 2016 15:44:47 -0800 "Steven R. Loomis" <srl at icu-project.org> wrote:
>>> I came across this address (though it seems to be a generic one)
>>> on http://portsmon.freebsd.org/portoverview.py?category=devel&portname=icu
>>> and https://svnweb.freebsd.org/ports/head/devel/icu/
>>> 
>>> I work on ICU.  58.2 is shipping today (hopefully).
>>> 
>>> It seems there are a bunch of patches in
>>> https://svnweb.freebsd.org/ports/head/devel/icu/files/
>>> 
>>> It would be great to get these pushed upstream to ICU.
>>> 
>>> Any way we can try to do that?
>>> ICU’s CLA is at https://ssl.icu-project.org/trac/wiki/IcuDownstreams#cla
>>> for accepting patches.
>>
>> Feel free to commit them.
> 
> Could you consider signing the CLA at the bottom of
> http://icu-project.org/trac/#cla ? It’s 1-click if you have a Github
> id.

I don't have a github account so I looked at the form.  I'm sorry, but I'm
not going to sign that.

1) I don't want to give you my address and phone number.  I have no idea
   who you are.
2) If you want people to contribute don't make them jump through hoops like
   this.  Imagine if all open source projects required this.
3) I'm not sure what your form is supposed to accomplish.  I recently
   went through a similar process with the FSF, but their form is a
   transfer of copyright to them so they have standing in court to fight
   GPL violations.  This is part of their mission and I respect that
   even though I'm no fan of the GPL.  I understand that such a transfer
   requires a more formal process with a legal signature.  I have no such
   understanding with your form.  It just looks like a license agreement.
   Why do you need my personal details and signature?  It is completely
   obvious to any open source developer that when they contribute code to
   an open source project it is going to be distributed openly under the
   terms of the project license.  If, for some odd reason, this is not
   legally obvious in front of a judge then the next step would be to put
   this form on your website as a simple clickwrap agreement, and not to
   go full blown signature required.
4) Under "Rights affecting the use of a Contribution" it says I should
   let you know if I know of any rights (e.g. patents) covering the
   contribution.  I can't assess the full legal consequences of signing
   this.  What happens exactly if there are patents that I don't know of
   and somebody gets sued over them?  Can they try to claim that I should
   have known and therefore should have informed you and that the fact I
   didn't was a violation or some form of negligence?  I cannot sign this
   without contacting a lawyer which I'm not going to do.  Projects
   should protect their contributors as much as possible from legal shit,
   not make them vulnerable to it, especially when these contributors are
   essentially doing volunteer work for free.
5) The patches are small and trivial bug fixes and don't add anything
   new or original.  I doubt copyright can even be asserted over them.
6) I have nothing to gain and possibly something to lose by signing that
   form and nothing to lose if I don't sign.  Why would I sign?

Please don't take "you" above personally.  I know you are just following
project protocol.

>> patch-common_umutex.cpp:
>> This code is compiled conditionally and one of the cases is a c++11
>> compiler without <atomic> header.  uio.fState is an atomic variable and
>> cannot be read directly.  I used umtx_loadAcquire in the patch because
>> that's what's used elsewhere to read fState.  
>
> OK. Why would <atomic> not be available?

I didn't remember correctly.  The code isn't compiled conditionally.  The
fState field is declared differently depending on the availability of
<atomic>.  With <atomic> it is declared as a C++11 atomic integer.
Accessing such a variable like the unchanged code does is implicitly
atomic.  Using umtx_loadAcquire just makes it explicit.  The code output
from the compiler is the same.  Without <atomic>, e.g. when ICU is
compiled with a C++98 compiler or with incomplete implementations of C++11
(e.g. FreeBSD 9 has a C++11 capable compiler, but no runtime libraries),
fState is not declared as an integer that you can access like the
unchanged code does.  You must always use one of the functions like
umtx_loadAcquire.