harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yang Paulex" <paulex.y...@gmail.com>
Subject Re: [OT] JFYI: Dave Gilbert (jfree.org) on Apache Harmony
Date Wed, 11 Apr 2007 10:02:51 GMT
2007/4/11, Stepan Mishura <stepan.mishura@gmail.com>:
>
> On 4/11/07, Alexey Varlamov wrote:
> > 2007/4/11, Yang Paulex :
> > > 10 Apr 2007 17:39:17 +0400, Egor Pasko:
> > > >
> > > > On the 0x2B4 day of Apache Harmony Yang Paulex wrote:
> > > > > 2007/4/10, Alexey Petrenko :
> > > > > >
> > > > > > Yeah, let's start a branch.
> > > > >
> > > > >
> > > > > So let's heads up a little into a little details :), currently
> > > > in  Harmony
> > > > > svn enhanced directory[1], we have classlib/drlvm/jdktools/others
> in
> > > > > separated directories, and every directories has a subdirectory
> trunk,
> > > > the
> > > > > problem now is, do we branch whole enhanced directory[1], or
> create a
> > > > branch
> > > > > for every modules? I prefer the latter one a little, because: 1.
> not
> > > > every
> > > > > module needs(or wants) branch; 2. it's convenient for guys only
> working
> > > > on
> > > > > one area to maintain, for example, it's easier to a classlib
> contributor
> > > > to
> > > > > follow all classlib changes. I guess that's why the current
> directory
> > > > > structure looks like.
> > > > >
> > > > > If so, another issue is how to deal with the federate build
> > > > directory[2],
> > > > > which aims at combining all modules as a whole HDK, depending on
> its
> > > > > build.xml to "svn switch" subdirectory to relevant modules. Now I
> > > > suggest we
> > > > > either create a enhanced/branch/java6 for federate build, or
> update the
> > > > > build.xml so that some options can be used to specify which branch
> the
> > > > > federate build will use.
> > > > >
> > > > > Ideas?
> > > >
> > > > If we are considering branches for different components, I should
> say
> > > > that for JIT branching does not make sense. All difference I know of
> > > > related to JIT is disabled subroutines in bytecode, that can be
> > > > triggered with some Verifier's compile-time option.
> > >
> > >
> > > I was not proposing to branch to such a detail level, IMO it would be
> > > difficult to maintain to create branch for every modules in
> classlib/vm etc.
> > > My thoughts look like:
> > >
> > > https://svn.apache.org/repos/asf/harmony/enhanced/
> > > |__ classlib
> > >     |__trunk
> > >     |__branches
> > >         |__java6
> > > |__drlvm
> > >    |__trunk
> > >    |__branches
> > >         |__java6
> > > |__jdktools
> > >    |__trunk
> > >    |__branches
> > >         |__java6
> > > |__...(other directories)
> > > |__trunk   (federate build for java 5)
> > > |__branches
> > >    |__java6 (federate build for java 6)
> > >
> > > And I also suggest, as long as possible, check in updates to Java 5
> trunk,
> > > and then merge into Java 6 branch, because, as you said, many
> improvements
> > > apply to both Java 5 and 6. And in case other components don't have
> much
> > > difference between Java 6 and 5, we can just create a java6 trunk for
> > > classlib and federate build as pilot at first
> >
> > Good idea to start with classlib as pilot, but do we really need to
> > branch the federated build? I suppose Stepan meant just tweak it for
> > supporting extra property for a desired branch.
> >
>
> I think we should just update build.xml by adding new property, say
> 'java6', so if it is set then federated build switches class library
> to 'java6' branch.


Yes, that's another option I mentioned, and it's fine to me.

Thanks,
> Stepan.
>
> > >
> > > In case I am not mistaken in the estimation, we should better support
> > > > JIT in a single trunk.
> > > >
> > > > > [1] https://svn.apache.org/repos/asf/harmony/enhanced/
> > > > > [2] https://svn.apache.org/repos/asf/harmony/enhanced/trunk
> > > > >
> > > > > 2007/4/8, Andrew Zhang <zhanghuangzhu@gmail.com>:
> > > > > > > On 4/8/07, Mikhail Fursov <mike.fursov@gmail.com>
wrote:
> > > > > > > >
> > > > > > > > Bloggers blog while developers work :)
> > > > > > > >
> > > > > > > >
> > > > > > > > I like we pushed RI to become open source. I like
our scores
> in
> > > > > > benchmarks
> > > > > > > > and I like our plans on stability improvements for
the next
> > > > quarter.
> > > > > > >
> > > > > > >
> > > > > > > Ya,  but we need to do something more to prove that  Harmony
> is not
> > > > only
> > > > > > > toy.
> > > > > > >
> > > > > > > One thing I agree with the blog is about "branch". We need
to
> think
> > > > more
> > > > > > > about branch.
> > > > > > >
> > > > > > > It's easy to use branch, but porting back fix and merge
sound
> like
> > > > > > nightmare
> > > > > > > to me.
> > > > > > >
> > > > > > > What I really miss is an absence of Geir in our mailing
list
> last
> > > > > > weeks...
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On 07 Apr 2007 23:05:48 +0400, Egor Pasko <
> egor.pasko@gmail.com>
> > > > > > wrote:
> > > > > > > > >
> > > > > > > > > $subj:
> > > > > > > > >
> > > > http://jroller.com/page/dgilbert?entry=the_death_of_apache_harmony
> > > > > > > > >
> > > > > > > > > entitled:
> > > > > > > > > The Death of Apache Harmony
> > > > > > > > >
> > > > > > > > > Just to let you know, and no comments.
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Egor Pasko
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Mikhail Fursov
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Best regards,
> > > > > > > Andrew Zhang
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Paulex Yang
> > > > > China Software Development laboratory
> > > > > IBM
> > > >
> > > > --
> > > > Egor Pasko
> > > >
> > > >
> > >
> > >
> > > --
> > > Paulex Yang
> > > China Software Development laboratory
> > > IBM
> > >
> >
>
>
> --
> Stepan Mishura
> Intel Enterprise Solutions Software Division
>



-- 
Paulex Yang
China Software Development laboratory
IBM

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