2007/4/11, Stepan Mishura <[EMAIL PROTECTED]>:
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 <[EMAIL PROTECTED]>: > > > > > > On 4/8/07, Mikhail Fursov <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> > > > > > 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
