[Sugar-devel] [RFC PATCH v0 0/8] Journal sorting by file size and creation time.

[Andrés Ambrois]

On Thursday 06 May 2010 02:14:44 am you wrote:
> On Sat, May 01, 2010 at 04:33:48PM -0300, Andrés Ambrois wrote:
> ><snip>
> 
> As current datastore and journal maintainer, some points:
> 
> I'm still not sure will ml path proposal scheme work on not, it removes
> some bugs.sl.o issues but adds new e.g. it is pretty hard to collaborate
> (in my mind) via ml history, in case of bugs.sl.o, someone can just
> share http link to complicated query. Other thing is that on bugs.sl.o
> it is easy to query tickets by keywords for example.
> 
> And since having patches both on bugs.sl.o and ml is pretty useless and
> there is no regular way to attach "0.90 targeted" keyword to ml posts,
> please create tickets on bugs.sl.o.

Hi Aleksey. Thanks for taking the time to look at this. 

While I personally don't think it's that hard to collaborate on the ml, I 
believe this discussion belongs in the "Code Review process changes" thread 
[0]. Either way, the bug I referred to (#1915) contains the previous 
discussion and links to both patchsets. It is also tagged as "r?", though no 
one has taken a look at it yet.

I should say that the fact that you commented on this thread before you did so 
on the ticket is evidence that reviewing patches here managed, at worst, to 
grab the right person's attention, and at best will work the same for others.

But I digress. I think your opinion is important and should be part of that 
thread.

> In case of journal, my strong thinking is that Journal shouldn't be only
> one for all purposes and it shouldn't be only in glucose as part of
> sugar core. I initiated journal library [3]. The major idea is that
> anyone can create his own journal activity and glucose can provide
> common/simple/default one.
> 
> So, all my resources I spend to journal library (and related projects)
> not to journal code in glucose. If you share this thinking, please come
> aboard.

I'm not convinced, but I could be. 

While I think opening up the API might encourage activity developers to 
produce their own (potentially better) journal UI's, I feel it is a mistake to 
stop improving the canonical interface for accessing the user's data: it is 
orthogonal; we can work on improving the current UI _and_ provide the tools 
you mention. 

If you think Journal development should be halted until it is moved out of 
glucose, we should get working on that; deployments need this feature. On the 
other hand, the Journal was once an activity but was integrated into the shell 
in 0.84 (see commit f0ff3b) for performance and maintainability reasons, have 
any of those priorities changed in your mind?

I've taken a look at some of the components of your Polyol project and I'm 
impressed by the quality and quantity of your work, congrats!.

> Having covered all the above, I thing only datastore patch is requested.

You mean only the DS patch will be accepted?

> [3] http://wiki.sugarlabs.org/go/Activity_Team/Services/Journal
> 
> -- 
> Aleksey
> 

[0] http://lists.sugarlabs.org/archive/sugar-devel/2010-April/023410.html
-- 
  -Andrés
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.sugarlabs.org/archive/sugar-devel/attachments/20100506/bf932664/attachment.pgp