Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (athena.apache.org: domain of t.p.ellison@gmail.com
 designates 72.14.220.152 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:x-enigmail-version:content-type
         :content-transfer-encoding;
        b=EooGMl8n2//u+AUvNSijoEtyGTM4agk3QrdSXGar9J7L7w3bmIIM9/8sjpJd9n1fCx
         TYnIDRNuOkeEoyEe7SBuNH+wAAvqUXh8EAB1X3M1+dv55k9+wfk3SMd2ddofsOtKh4gE
         hlY0B5/TRs2/xtbwt101pJM6N13QMKAlLyZfc=
Message-ID: <48565B98.5090305@gmail.com>
Date: Mon, 16 Jun 2008 13:24:56 +0100
From: Tim Ellison <t.p.ellison@gmail.com>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: dev@harmony.apache.org
Subject: Re: [classlib][concurrent] how do we fix concurrent?
References: <f944d83d0805080340y2ef0157fq99a21c3a1233efca@mail.gmail.com>
	 <4822DAB8.5040907@gmail.com>
	 <f944d83d0805080409ye4e41e1pc9fc900c0d74a22f@mail.gmail.com>
	 <f944d83d0805080421t4f5de80fjbcb83b597e6edae6@mail.gmail.com>
	 <4822F55F.1090702@gmail.com>
	 <3b3f27c60805081918q23843befh6139df03a4d59e00@mail.gmail.com>
	 <9623c9a50805090151x6e6a8018p43bf9ccbcc8b3143@mail.gmail.com>
	 <9623c9a50805090154u242a7d8cr5dc4acf6c5890d17@mail.gmail.com>
 <3b3f27c60805091203j7ef95b57u21223adb5aa1d42a@mail.gmail.com>
In-Reply-To: <3b3f27c60805091203j7ef95b57u21223adb5aa1d42a@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Nathan Beyer wrote:
> On Fri, May 9, 2008 at 1:54 AM, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> 
>> On Fri, May 9, 2008 at 4:51 PM, Xiao-Feng Li <xiaofeng.li@gmail.com>
>> wrote:
>>> On Fri, May 9, 2008 at 10:18 AM, Nathan Beyer <nbeyer@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