RE: [mylar-dev] patch for performance improvements and group actions ont

["Mik Kersten" <beatmik@xxxxxxx>]

The best thing to do with big patches of this sort is to first propose a
design, either on the dev list or on the bug report, depending on whether on
how far-reaching the changes are.  That helps ensure that the patch that you
come up with can be quickly applied instead of going stale.

In the case of this particular patch, as you know from the bugs, I agree
with the need to group actions in the way that your patch does.  However,
there are a couple of design issues that need to be discussed up-front in a
patch of this size.  The main problem is the addition of a couple of methods
on ITaskListElement including canComplete() and canRead().  There is a
strong case for task containers not being forced to implement such methods
(they are not things that users read or complete) so the burden on someone
making such a contribution is to make the case for adding those first, or to
come up with or request a change to the framework that ensures that this
top-level interface stays minimal.

There is a second problem with the patch.  When I review big patches of this
sort there is an element of trust that the patch is focused on the problem
it is addressing, because there is always a chance I will miss some changes.
This patch additionally changes the order of the Mark complete/incomplete
and read/unread elements in the UI.  That is something that you have asked
for previously, and I realize that it will work better for you (and me too
for that matter), but I have argued that it I do not want to make this
compromise for users of non-repository tasks without additional input.  From
now on, I request that ANY patch that makes a change to the UI make that
change clear in the comment on the bug report.  UI additions are fine since
they're harder to miss.  I have updated the Contributor reference
accordingly.

The meta point here is that I expect anyone who is a committer or frequent
contributor on the project to both think and state requests in terms of how
they will benefit the user community as a whole, and not just benefit them.
Other contributors should feel free to make self-serving patches, since the
burden is on the committers to prioritize and filters those to ensure that
they meet the needs of the user community as a whole.  So while the
statement "I get annoyed by slow UI responsiveness when group actions" could
be representative of others, it is not stated as such, and is far from clear
whether this has priority in the committers' single-minded focus of
stabilizing for the 1.0 release.

In terms of your stating that you "have to beg to review and apply them", if
there has been a problem with the turn-around of your patches please state
the average number of days waited to apply.  I have been prioritizing your
patches very high because they are generally very valuable, and if the
turn-around is insufficient for you to continue investing time into them I'd
like to know how we can improve on that without starving other users'
requests that need attention.

Mik

> -----Original Message-----
> From: mylar-dev-bounces@xxxxxxxxxxx [mailto:mylar-dev-bounces@xxxxxxxxxxx]
> On Behalf Of Eugene Kuleshov
> Sent: Saturday, December 02, 2006 10:49 PM
> To: Mylar developer discussions
> Subject: [mylar-dev] patch for performance improvements and group actions
> ontask list
> 
> Hi all,
> 
>   I get annoyed by slow UI responsiveness when group actions are called
> on Task List (mark read, completed, schedule..., etc). More over group
> actions aren't enabled for local and web tasks...
> 
>   So, after looking at these issues I again come up with quite big
> patch. Apparently I am unable to produce the small ones and have to beg
> to review and apply them, so they won't get into conflicts with ongoing
> changes.
> 
>   Patch attached to issue 165732 adds canRead() and canComplete()
> methods to ITaskListElement and moves other methods like isCompleted()
> up to class hierarchy. Logic for mark read/unread and complete actions
> became much simpler and group actions now work for local and web tasks.
>   Another improvement that worth to note is moving task saving (which
> takes 2..3 seconds here) into the background job, so it don't block the
> UI anymore and as a side effect skips lots of sequential save requests.
> With this change I observe significant improvement in UI and task saving
> operations.
> 
>   See https://bugs.eclipse.org/bugs/show_bug.cgi?id=165732
> 
>   I hope Mik or Rob can review this and apply this patch before it get
> stale.
> 
>   regards,
>   Eugene
> 
> 
> _______________________________________________
> mylar-dev mailing list
> mylar-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/mylar-dev