Yes, you are correct about Google's code requirement. I've noticed their code requirement later. Ok, let me rephrase my suggestion in a more general and non-restricting way: be closer to the particular project, and do not pay to much attention for Google time line and other non-specific things. This does not mean "remove that from your proposal", but rather "add something project-specific into it". "Submit selected patches as JIRA references to Google as required" would be better. Just think of people from Apache who would be your readers.
> OK, in that case I should rewrite logic within the Harmony GC You will have to patch both sides, but patches on Parrot side would be pretty limited: they have GC interface layer. Adjusting our GC to their interface layer would be more than writing a wrapper. Yes, it is something about changing logic. On Sun, Mar 30, 2008 at 2:37 PM, Senaka Fernando <[EMAIL PROTECTED]> wrote: > Hi Alexei, > > Many thanks for Reviewing my proposal. > > > On 3/30/08, Alexei Fedotov <[EMAIL PROTECTED]> wrote: > > Hello Senaka, > > > > Good job. Let me share few ideas how to improve it. > > > > 1. > > > September 3: Submitting code and documentation to Google > > The code should be submitted to Apache in patches attached to JIRA > > issues with ASF license granted. > > Regarding submitting code to Google, it was somewhat appearing in > their program timeline, [1]. I will actually submit code to Apache at > the end of each Checkpoint/Milestone according to what you mentioned > here, through the JIRA. However, what I'm not sure is whether it is > mandatory to submit the code to Google, if not which can be dropped. > > [1] http://code.google.com/opensource/gsoc/2008/faqs.html#0.1_timeline > > > > > > 2. > > DRL is actually a former name of one of the Intel's labs. Better to > > address a module you are describing as DRLVM or Harmony VM. > > I will change that to DRLVM. > > > > > > 3. > > > As an asset to the improvement of Apache Harmony, several other > > communities have shown interest in this project. > > Word-to-word translation to Russian makes sense, but I never have seen > > "asset" in this context. May be it worth rephrasing that. For Harmony > > the more customers we have, the more successful we are since customers > > of open source support us with patches, money, or just words of > > gratitude and sensible use cases. May be this impact is about > > strengthening Harmony community making an interest to Harmony deeper > > to the stage of acceptance? > > I will rephrase that. > > > > > > 4 > > I do not believe that creating an efficient wrapper is possible. This > > is particularly important to align with Xiao Feng due to his extensive > > experience in GC architecture. My current perception is that you > > should just branch Harmony gc and do all the staff to make Parrot work > > hacking into GC code directly and not thinking of DRLVM. Finally, when > > you get Parrot running, you will understand better the way of > > maintaining a code base. You may either maintain a branch, or add a > > number of #ifdef statements to the initial code. > > > > This would be quite non-trivial to align interfaces, and thinking of > > code base merge would a pretty trivial task compared to that. > > OK, in that case I should rewrite logic within the Harmony GC, and > directly plug it isn't it? But, I might require an extension on the > Parrot side which will be capable of reading the Harmony GC, because > this end is C++ and the other is C. I will have to experiment it and > see. > > > > > > 5. > > Instead of generic terms such as "release", "patch release" I would > > suggest problem-related work breakdown, eg > > > > 1. Get Harmony, build Harmony GC getting rid of java sources and vmcore > > 2. Add another GC to Parrot with calls redirected to loaded library, > > understand Parrot GC interface > > 3. Implement parrot-specific GC interface calls > > basic interfaces such as memory allocation > > checkpoint: small applications which do not need much heap > > should start to work right now > > build a simple logger or other debugging infrastructure > > stack enumeration > > PMC object layout > > checkpoint: get the first GC passed > > finalization and weak references > > Align this plan on the time scale. > > OK. > > > > > > 6. Rewrite deliverables in terms of checkpoints. I believe getting > > things work even without finalization is pretty ambitious for three > > months. > > OK. > > > > > > > Thank you for your effort. > > > > On Sun, Mar 30, 2008 at 1:29 AM, Senaka Fernando <[EMAIL PROTECTED]> > > wrote: > > > I have added the project proposal for harmony-gc-5 at [1]. I would be > > really > > > pleased if you could be kind enough to review it and suggest where I > > could > > > improve it. > > > > > > [1] http://wiki.apache.org/general/SenakaFernando/GSoC2008/harmony-gc-5 > > > > > > Regards, > > > Senaka > > > > > > > > > > > -- > > With best regards, > > Alexei > > > -- With best regards, Alexei
