Re: [classlib][concurrent] how do we fix concurrent?

[Tim Ellison <t....@gmail.com>]

Nathan Beyer wrote:
> On Fri, May 9, 2008 at 1:54 AM, Xiao-Feng Li <xi...@gmail.com> wrote:
> 
>> On Fri, May 9, 2008 at 4:51 PM, Xiao-Feng Li <xi...@gmail.com>
>> wrote:
>>> On Fri, May 9, 2008 at 10:18 AM, Nathan Beyer <nb...@gmail.com> wrote:
>>>  > After a few years of this I think we should just edit the code
>>>  >  directly. I think our original thoughts around the management of it
>>>  >  didn't materialize. Also, the code was public domain, so we own it
>>>  >  now.
>>>
>>>  +1
>>>
>> I recall it was because we didn't really want to own it, but to always
>> have updated code drop. I guess it's not that terrible to merge
>> certain fixes, considering its current stability.
>>
>> Thanks.
> 
> 
> I'd still suggest staying very conservative with changes to concurrent, such
> that we can continue to merge in the latest bits of the public domain code
> easily. The code is very stable and very well written, so I think we should
> avoid "enhancing" it as a convention and only make "fixes", unless there is
> some extremely compelling reason to do otherwise.

After a botched attempt to create an overlay version of Delayed, I'm 
going to create a branch of the code we have in 
harmony\standard\classlib\trunk\modules\concurrent and put the "fixes" 
in there.  Then, as you say, we can easily merge in the latest bits of 
public domain code in the future.

> I think it could still stay in the "standard" folder though, since I don't
> think it would necessitate the ACQ (ICLAs are always needed). Though, it
> might just be easier to treat it just like every other module. In that vein
> of thought, I'd suggest considering doing away with the 'standard' and
> 'enhanced' folders altogether and just apply our general due-diligence on
> contribution checks for all code. I think this would do away with an extra
> layer of folder complexity that, in my opinion, hasn't provided that much
> value.

I see no harm in keeping the standard structure.  Then it is clear which 
bit of code in our SVN is not ALv2'd and has no ACQ/ICLA etc.

Regards,
Tim