harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hindess <mark.hind...@googlemail.com>
Subject Re: [jira] Commented: (HARMONY-6312) Concurrency problems in NIO
Date Thu, 08 Oct 2009 23:23:20 GMT

In message <a43fbc6a0910080958t19bb1c40h94389bbf6d3ba78a@mail.gmail.com>,
Jesse Wilson writes:
>
> Mark,
> Thanks for hanging along with me on these changes, and also for the
> heads up on Regis' holiday.
> 
> 
> On Thu, Oct 8, 2009 at 2:57 AM, Mark Hindess <mark.hindess@googlemail.com>
> wrote:
> >
[ snipped: Jesse and I agreeing with each other ]
> >
> For the specific case of selector indices, my main concern has been
> that the epoll microbenchmark inflated the benefit and hid the cost.

I tend to agree with this.  I'd like to see some more practical benchmarks.

> > For example, your changes to make fewer object allocations (doubling
> > the number of parameters to the select method) don't improve
> > simplicity but are brilliant idea.
> 
> Actually, this is Regis' brilliance. Yay Regis!

Oops.  Sorry Regis.  This is another thing I don't like about these
patches.  They contain other people's work.

Regis, with hindsight and given that the next milestone release is a
little way off, I think what should have happened here is that once we
decided that most of Jesse's changes were valid we should have committed
them and then evolved the code in the repository.  This means code
origin is more obvious and also has the advantage that others can then
take different revisions, test them and run (their favourite) benchmarks
to ensure progress is being made.

> > I'd certainly find it easier to apply your patches if they were
> > closer to the final commits I make.
>
> Thanks for going the distance on my patches; I'm sorry they're so
> scary!
>
> Since I was recently complaining to Regis about his use of too-many
> small patches, it seems we've simply got different workflow
> patterns! I read patches in my IDE, which takes care of hiding
> whitespace problems, etc. And I find the JIRA process slightly
> cumbersome, so it's easy just to send one uberpatch.

I suspected this was the case.  The different workflow is entirely
understandable given your perspective.

I didn't write my message expected you to start producing patches
conforming to my particular ideal but simply to explain honestly and
openly why things might seem to be moving slowly so that you didn't get
frustrated at the lack of progress and that we might both understand
each others positions a little better

> So as you probably all know, Dalvik's core library was forked from
> Harmony several years ago. We recently caught back up-to-date with
> Harmony, so all of your bugfixes will be shipping on our devices
> this holiday season. But we also have made lots of changes of our
> own including whitespace, bugfixes, optimizations, simplifications,
> spelling corrections and removing author tags. To send these changes
> upstream, I can either do it as a single giant scary patch, or as a
> series of focused patches.
>
> The primary drawback of focused changes is what they use as a
> baseline. I can create patches that depend on each other in series,
> so you need the whitespace change in order to get the bugfixes. Or
> patches that all apply to Harmony's HEAD, so the patches could
> slightly conflict with one another (if there's a whitespace change
> near a bugfix). Or I could wait for the whitespace change to be
> applied, and send a second patch with the bugfixes.  In any case it'll
> just be me taking the giant patch, and then trying to split it up into
> chewable pieces. Any preference from you guys?

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.

Naively assuming that getting 1), 2) and 3) out of the way makes
producing more focused patches a little less likely to generate
conflicts.

Having said that, I really don't mind that much because if the changes
are worth having then I'll figure out even the most unwieldy of patches
eventually.

But the key here is "eventually".  If time is important to you then
doing what you can to make patches consumable by committers might be a
consideration.

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. ;-)

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?

> Thanks again Mark!

Thank you.

Regards,
 Mark.



Mime
View raw message