[Sugar-devel] journal maintenance (was Re: [RFC PATCH v0 0/8] Journal sorting by file size and creation time.)

[Simon Schampijer]

On 05/17/2010 12:01 PM, Tomeu Vizoso wrote:
> On Thu, May 6, 2010 at 07:14, Aleksey Lim<alsroot at member.fsf.org>  wrote:
>> On Sat, May 01, 2010 at 04:33:48PM -0300, Andrés Ambrois wrote:
>>> This patchset implements sorting in the Journal UI as described in [0].
>>>
>>> This feature was requested in [1] and sponsored by Activity Central [2].
>>>
>>> Sorting by filesize is vital in the field where users need to free up disk
>>> space. Currently, the only way to find candidates for deletion is to access
>>> the expanded view of each entry, one by one. This can be a very time consuming
>>> process and often leads to indiscriminate deletion and thus potential loss of
>>> valuable data. This is bad.
>>>
>>> Sorting by creation time (ctime) is also implemented as described in the Design
>>> Proposal.
>>>
>>> This implementation currently lacks two aspects which I hope will be sorted out
>>> in the review process:
>>>
>>> 1- The proposal does not include a specification for changing the order of the
>>> sort. This patch assumes an ascending order.
>>>
>>> 2- There are no icons for the sorting criteria. Or at least I couldn't find the
>>> ones presented in the proposal. I'm sure someone from the design team could
>>> vectorize the ones there.
>>>
>>> v0: Initial submission to sugar-devel
>>
>> 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.
>>
>> 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.

I hope I understand this right, please state so if not.

As it is perfectly ok to develop new solutions, a maintainer, should 
well maintain existing code. We have <= 0.84 shipped to 1 million kids, 
and the Journal as it exists is a very important part of the Sugar 
experience.

Please think about the position you have in.

Regards,
    Simon