Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 15857 invoked from network); 5 Dec 2005 16:49:29 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 5 Dec 2005 16:49:28 -0000 Received: (qmail 90981 invoked by uid 500); 5 Dec 2005 16:49:22 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 90933 invoked by uid 500); 5 Dec 2005 16:49:21 -0000 Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: harmony-dev@incubator.apache.org Delivered-To: mailing list harmony-dev@incubator.apache.org Received: (qmail 90912 invoked by uid 99); 5 Dec 2005 16:49:21 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Dec 2005 08:49:21 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: unknown (asf.osuosl.org: error in processing during lookup of archie@dellroad.org) Received: from [216.239.128.26] (HELO smtp.omnis.com) (216.239.128.26) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Dec 2005 08:49:20 -0800 Received: from [10.3.2.13] (unknown [208.63.111.51]) by smtp-relay.omnis.com (Postfix) with ESMTP id 5DAD91407C2F for ; Mon, 5 Dec 2005 08:48:59 -0800 (PST) Message-ID: <43946F77.9080900@dellroad.org> Date: Mon, 05 Dec 2005 10:48:55 -0600 From: Archie Cobbs User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.3) Gecko/20041129 X-Accept-Language: en-us, en MIME-Version: 1.0 To: harmony-dev@incubator.apache.org Subject: Re: Where do we put it? (Was Re: [jchevm] Porting JCHEVM to OSX/PPC) References: <1132691903.2495.14.camel@Elrond.Rivendell> <438384EF.90201@dellroad.org> <1132764963.2490.8.camel@Elrond.Rivendell> <4384AD60.4070009@dellroad.org> <1132849379.3001.2.camel@Elrond.Rivendell> <1133001858.2541.7.camel@Elrond.Rivendell> <1133295663.2549.7.camel@Elrond.Rivendell> <438CD769.6090007@dellroad.org> <1133308091.2543.4.camel@Elrond.Rivendell> <43945A1B.2070809@dellroad.org> <4160914C-840A-4EEB-80BC-FDA144AD4EFB@apache.org> In-Reply-To: <4160914C-840A-4EEB-80BC-FDA144AD4EFB@apache.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Geir Magnusson Jr. wrote: > > On Dec 5, 2005, at 10:17 AM, Archie Cobbs wrote: > >> Geir Magnusson Jr. wrote: >> >>>>>> I stripped out lots of ELF specific stuff, so my version could be >>>>>> interesting for a port to windows too. I just don't want to >>>>>> commit it >>>>>> to "trunk" yet because it's completely untested. >>>>> >>>>> >>>>> You could create a branch to play with in Subversion. If you do, >>>>> I recommend also using svnmerge... http://dellroad.org/svnmerge >>>> >>>> >>>> Good Idea, but where would I place that branch? >>>> "harmony/enhanced/branches/sandbox/contribs/jchevm/osx_port"? >>>> >>>> I'll look at the rest of the issues later... >>> >>> Is there a way to safely get this code in the main trunk? I don't >>> mind (what about others?) if you need to work in the corner of the >>> sandbox, but this seems like enhancement to the trunk rather than a >>> revolutionary experiment... >> >> >> That's OK with me, but since it's still "completely untested" it seems >> like a branch may be better... but in any case, if there is some >> uncertainy, >> why not create a branch? Branches are essentially zero cost with >> Subversion, >> even if it's only for a short while to get things "in order", etc. > > How about testing it? :) Sure.. but for that to happen, the patches have to be committed somewhere first (let's try to avoid emailing patches around and use SVN instead). > I believe that the changes shouldn't break jcheVM on platforms other > than OSX/PPC, but if they don't work yet on OSX/PPC, that's fine. If > that can't be done - if David can't do that, then maybe a sandbox is > right, but at some point, it *has* to come back to the tree, which > means that it doesn't break the existing code, and I think that if we > can do that now in the trunk that's better. OK, that's fine with me. > We'd like to have a culture of "check in stuff that doesn't break > others", but "commit early and often so others can see and work with > what you are doing" I couldn't agree more. This is exactly what branches allow you to do :-) -Archie __________________________________________________________________________ Archie Cobbs * CTO, Awarix * http://www.awarix.com