In message <a43fbc6a0909301705i465f46cbye3f889218dcfc...@mail.gmail.com>,
Jesse Wilson writes:
>
> So Regis and I disagree on the merit of maintaining indices. Actually
> disagreeing on such things is generally healthy since mobile/Android
> prefers simplicity and memory efficiency, whereas serverside prefers
> high throughput. Yet I still feel that the index optimizations were
> misguided, particularly since more effective, simpler optimizations
> were left on the table (and now live in my patch).
I think there is usually quite a lot of overlap between the goals of
memory efficiency and high throughput.
I'd argue that simplicity isn't necessarily a good metric for either
Android nor Harmony since you rarely ever want to maximize simplicity at
the cost of other more significant factors. 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.
> Regardless, I'd prefer to focus on getting the noncontroversial
> changes checked in. Alongside some controversial stuff, the patch I
> attached on Monday includes fixes for a keyset liveness bug. It also
> saves some unnecessary object allocation.
Perhaps "Alongside some controversial stuff, ..." is the reason you are
having trouble making progress? I think you'd have a better chance
of getting patches committed if you supplied more patches with fewer
changes.
I prefer small commits with a small number of very closely related
changes[0]. It may be that you do to but I tend to base my assumptions
on what a (potential) committer would do based on the style of their
JIRA contributions.
At the moment, when I get your patches I tend to:
1) Apply the patch
2) Create a patch ignoring whitespace changes[1].
3) Revert the patch and continue working with the "whitespace" cleaned version.
4) Remove any obviously controversial stuff that hasn't been adequately
discussed on the mailing list[2].
5) Tackle the patch a little at a time pulling out obviously isolated
changes.
6) Procrastinate about what to do about bigger changes - particularly those
that affect cross module dependencies.
I'd certainly find it easier to apply your patches if they were closer
to the final commits I make.
Of course, I appreciate your contributions and will tend to make use
of them (eventually) whether they conform to my personal (possibly
unreasonable?) ideals or not.
> Please apply some or all of the patch. Or let me know how I can
> improve it, so that you'd be inclined to do so.
FYI: Regis is probably "busy" with the Chinese holiday this week.
Regards,
Mark.
[0] I'm human and somewhat pragmatic so I often fall short of my own standards.
[1] I wonder if the contribution guidelines should actually suggest using
"svn diff -x -w" to create patches - unless they are only changing
whitespace.
[2] Author tag removal for example. This has been discussed on this list
before and the consensus was to keep them. Some have been removed
where other changes have taken place and perhaps less justifiably with
the improved JDWP contribution in the java6 branch. Personally I would
be inclined to remove them. Since the last discussion Apache policy
seems to be against having them perhaps we could revisit this discussion.
