harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [drlvm][jitrino.JET] "-Xem jet:" and "-Xjit jet::wb4j" don't work anymore
Date Sat, 30 Sep 2006 23:53:56 GMT
On 30 Sep 2006 21:01:50 +0700, Egor Pasko <egor.pasko@gmail.com> wrote:
> On the 0x1F3 day of Apache Harmony Mikhail Fursov wrote:
> > Egor,
> > I think this is right suggestion to synchronize our WB and H1580
> > implementations.  AFAIK H1580 uses old JET version and is not
> > compatible with the latest compiler version.
> Agreed.
> This patch is "before BBC" if this is what you mean. Need to test
> against a newer revision. Mikhail, I guess, it's you who are going to
> provide the committable version of the JET/WB patch. So it's up to you
> whether to update or reimplement..
> If it's true, our implementation for the new JET/OPT version will do the
> job
> > for the both subprojects.
> >
> > The only question I have now is a question to Geir and other commiters:
> > Do I really need to create a new JIRA for WB support in Jitrino? Or is
> it
> > better to add my patches to H1580?

If h1580 is based on svn revision number that is before BBC.patch, I
recommend closing h1580 and opening a new JIRA.  (I recently closed H-816
for similar reasons.)  Also, if Yu-Nan He's patch does not work with current
svn head, this patch needs updating.

An option you may not have thought about.  Open a new JIRA and ask Yu-Nan to
re-submit his patch to the new JIRA.

> I ask this because the last time a person added a patch to the JIRA
> created
> > by me was asked by Geir to use another JIRA to separate our
> contributions (I
> > mean Jitrino.OPT testing framework).
> That makes me confused a little. Another question from me:
> Can I combine some patches and attach them back to JIRA listing all
> original contributors to the patch explicitly? If yes, I would be
> happy. If no, that makes it difficult to exchange ideas/code/etc. Are
> there any recommendations how to make effective development of a big
> feature (say, new ABCD or JIT-testing framework) a) by several people
> b) avoiding commits to SVN for a long time?

Hmm... the real issue is how multiple engineers can publicly collaborate on
a subsystem.  The best way to do this is with an svn branch.  Of course, the
engineers will need committer access to the branch.  There may be some pain
during the startup phase, but this is where we need to end up.

 Products Division

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