harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Beyer" <ndbe...@apache.org>
Subject Re: [classlib][concurrent] how do we fix concurrent?
Date Fri, 09 May 2008 19:03:52 GMT
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.

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.

-Nathan


>
> >
> >  >  -Nathan
> >  >
> >  >
> >  >
> >  >
> >  >
> >  >  On 5/8/08, Tim Ellison <t.p.ellison@gmail.com> wrote:
> >  >  > Alexey Varlamov wrote:
> >  >  >>> Yeah, I've thought the same. Only unclear bit is how should
it be
> laid
> >  >  >>> in SVN - modules/concurrent is svn:externalized - do you have
any
> >  >  >>> tricks in mind?
> >  >  >>
> >  >  >> Argh - really I should have looked into modules/concurrent first,
> >  >  >> sorry. Everything is in place already.
> >  >  >
> >  >  > Yeah, if we put the correct version in concurrent/src/main/java/...
> then
> >  >  > the build script will take it in preference to the (externalized)
> code
> >  >  > in concurrent/standard/src/main/java/... and life is good.
> >  >  >
> >  >  > Regards,
> >  >  > Tim
> >  >  >
> >  >
> >  >  --
> >  >  Sent from Gmail for mobile | mobile.google.com
> >  >
> >
> >
> >
> >  --
> >  http://xiao-feng.blogspot.com
> >
>
>
>
> --
> http://xiao-feng.blogspot.com
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message