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

[Tomeu Vizoso]

On Fri, May 7, 2010 at 11:56, Aleksey Lim <alsroot at member.fsf.org> wrote:
> On Fri, May 07, 2010 at 11:15:12AM +0200, Tomeu Vizoso wrote:
>> 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:
>> >> 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...
>
> Well, at the end polyol/libjournal for me are experimental projects
> that could be somehow part of glucose, but they couldn't be as well
> because they are designed to be glucose agnostic.
>
>> 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...
>
> Well, at the end we talking about two not-so-similar schemes:
>    developer -> deployment/QA/releases/etc -> user
> and
>    developer/doer -> user/doer
>
> In my mind, sugar by nature is 2nd, but 1st scheme is also important
> (OLPC, XO, SOAS). But strive for only 1st scheme, imho, is pretty wrong
> way.
>
> Everything I'm doing is from a man who are from 2nd scheme:
>
> * more decentralized deployment (0sugar)
> * more decentralized development (polyol)
> * more decentralized collaboration (Activity_Library activity [5] [6])
>
> I'm sure 2nd scheme is not less important (at least), and more
> appropriate to community-driven projects like sugar (not sugar like an
> OS on XO).

Like it or not, Sugar gets used because someone deploys it, and in
>99.9% of the cases it's not the final user who deploys it. If we
pretend otherwise, Sugar won't reach users in an optimal way and we
are failing to aim for our stated goals.

I don't think it's entirely your fault, because deployers are trusting
that SLs' maintainers will guess what they need without them having to
get involved, which is the root cause of this problem.

Regards,

Tomeu

> [5] http://wiki.sugarlabs.org/go/Activities/Activity_Library
> [6] http://wiki.sugarlabs.org/go/Collab_mockup
>
> --
> Aleksey
>