Nathan Beyer wrote:
On Fri, May 9, 2008 at 1:54 AM, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
On Fri, May 9, 2008 at 4:51 PM, Xiao-Feng Li <[EMAIL PROTECTED]>
wrote:
On Fri, May 9, 2008 at 10:18 AM, Nathan Beyer <[EMAIL PROTECTED]> 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
