Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (nike.apache.org: domain of jessewilson@google.com
 designates 216.239.45.13 as permitted sender)
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns;
	h=mime-version:in-reply-to:references:from:date:message-id:
	subject:to:content-type:x-system-of-record;
	b=n9jeIgUS8FYTSE8UU/a036KurwzWW7lkXMgbgZGA0ASvkLwO472jafr6MFgzkfcMp
	UnTrMOJTNho2rxCLil5lw==
MIME-Version: 1.0
In-Reply-To: <20091008232411.48E95816049@nike.apache.org>
References: <1400244584.1250542154859.JavaMail.jira@brutus>
	<428767572.1254128296087.JavaMail.jira@brutus>
 <a43fbc6a0909281246g35fda8ev6f5a9f102b0c61d8@mail.gmail.com>
	<4AC1C365.6040203@gmail.com>
 <a43fbc6a0909290931s1cecdabcj643f7b35972d620c@mail.gmail.com>
	<4AC32C97.6090102@gmail.com>
 <a43fbc6a0909301705i465f46cbye3f889218dcfcf20@mail.gmail.com>
	<200910080957.n989vU4N013205@d06av04.portsmouth.uk.ibm.com>
	<a43fbc6a0910080958t19bb1c40h94389bbf6d3ba78a@mail.gmail.com>
	<20091008232411.48E95816049@nike.apache.org>
From: Jesse Wilson <jessewilson@google.com>
Date: Thu, 8 Oct 2009 17:08:11 -0700
Message-ID: <a43fbc6a0910081708i117fea9am888c9424058914d6@mail.gmail.com>
Subject: Re: [jira] Commented: (HARMONY-6312) Concurrency problems in NIO
To: dev@harmony.apache.org
Content-Type: multipart/alternative; boundary=001636e1fd3f4fd87f04757561d3

--001636e1fd3f4fd87f04757561d3
Content-Type: text/plain; charset=UTF-8

On Thu, Oct 8, 2009 at 4:23 PM, Mark Hindess <mark.hindess@googlemail.com>wrote:

> If I was in your position I'd probably try to:
>
> 1) Revert the author removal or justify why I thought it made sense
>   to the upstream and do it in one big change.  It looks like you
>   are doing this with HARMONY-6348 but I think some discussion needs
>   happen on the list.  I'll stop talking about it and kick this off.
>
> 2) Revert the whitespace changes or justify why they should be made
>   upstream and do them in one big change.
>
> 3) Create a JIRA with a patch for all the spelling corrections.
>
> 4) Start creating focused patches for the remaining changes in order of
>   importance.
>

Sounds like a plan! I'll try to get started on 2) and 3) shortly...


As I hinted before there is another issue that concerns me.  You could
> probably make more progress as a committer.  I tend to favour committers
> that have made JIRA patches as I'd hope to see them make commits rather
> than just hope that monolithic patches wont just translate in to
> monolithic commits if they had commit access.  (This is not the only
> factor or even a deciding one.)
>
> I don't know whether you'd like to be a committer or not but selfishly
> it would suit me as I'd not have to apply any more of your patches. ;-)
>

Well, on the projects that I do have commit privileges, I tend to submit
patches in logical units. Sometimes one logical unit is large but
uninteresting (whitespace, refactorings) and sometimes it's small and
interesting. For Harmony, I'm really just trying to address the multi-year
gap between Android and Harmony, and this project just lends itself to
larger patches. Once we're caught up (I'd like to have done so in 4-8
weeks), patch sizes should come back to normal.


> Aside: Out of curiosity do you have a feel for how much progress you've
> made getting your changes upstream and how much is still to go?
>

There have been three phases...

   1. Promoting Android Javadoc upstream to Harmony. It was a big project,
   but not particularly uninteresting or technically challenging.
   2. Pulling Harmony changes into Dalvik. This is 90% done; the only
   outstanding modules are nio and nio_char. I've done most of the merge, but I
   got slightly hung up on the selector change.
   3. Pushing Dalvik changes into Harmony. This is 20% done, but I'm quite
   happy with progress thus far.

So yeah I think in 4-8 weeks, Dalvik and Harmony will be fully in sync. I've
written some scripts for pushing code back and forth between the two
projects. That should make it easy to stay up-to-date once we get there.

--001636e1fd3f4fd87f04757561d3--