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

[Tomeu Vizoso]

On Fri, May 7, 2010 at 11:05, Aleksey Lim <alsroot at member.fsf.org> wrote:
> On Thu, May 06, 2010 at 05:13:38AM -0300, Andrés Ambrois wrote:
>> 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.
>
> Well, I was talking only from personal POV, having:
>
> * ugly gtk.TreeView usage in journal (lack of lazy model in gtk.TreeView)
> * need to integrate thumbs view
>
> For my own, I decided to concentrate all attention only on new journal
> library because fixing both mentioned code in step-by-step (when step it
> is glucose release) is pretty useless. New journal library inherited
> some model level code and has completely different UI part - field-widget
> based design and using HomogenTable list widget instead of gtk.TreeView.
> More over, I decided to create this library using only Polyol (w/o
> sugar-toolkit at all) to conform another my strong thinking [4].
> So, all this work can't be done within glucose.
>
> [4] http://wiki.sugarlabs.org/go/Documentation_Team/Services/Scalable_development_model
>
>> 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.
>
> To be honest, I didn't think about it at all. I have only one simple
> idea, create more functional journal and give a chance to users to use
> it on 0.82+ sugars. With journal only in glucose, only 0.90 users will
> get features like thumbs view, with activity based scheme (since I'm
> planing to support 0.82+ in journal library) all users (keeping in mind that
> current stable OLPC release is 0.82, next stable will be 0.84) all of XO
> users will have a chance to use new journal like activities. Thus, in my
> mind, library journal is more important.

I'm worried about how this could affect deployments negatively, but as
we don't have a forum for developers to discuss these subjects with
them...

IMHO, you as a maintainer shouldn't take such a decision without
making at least some efforts to make sure you aren't jeopardizing the
ability of downstreams to pick up future versions of Sugar. I know
it's very hard right now for developers like you to get that feedback,
but unfortunately there doesn't seem to be enough interest to create a
deployment team where these questions could be brought...

Regards,

Tomeu

>> 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?
>
> In performance case, new library use the same model scheme (except minor
> improvements) thus performance will be the same.
>
> About other aspects of journal integration like security issues, my
> first intention was not create full functional replacement of current
> journal, only that could be done w/o close core integration. Creating
> full functional replacement will require shell dbus API improvements,
> I was planing to create ready-to-use first journal library based
> activity (Library-2) and only than propose appropriate shell dbus API
> features.
>
>> 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?
>
> Sorry, I meant s/requested/required/, and of course I was talking from
> current journal maintainer POV. If there is someone who think that glucose
> journal should be improved in parallel w/ libjournal or that is wrong
> idea to base glucose Journal on libjournal, and have possibility to
> maintain glucose component, I'll pass my journal maintainanceship.
>
> Anyway, I think it would be good to split #1915 into two parts, ds and
> journal, at the end, these parts are independent, and two maintainers,
> datastore and journal, will have a chance to process only theirs parts
> of responsibility.
>
>>
>> > [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
>
>
>
> --
> Aleksey
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>