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

[Aleksey Lim]

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).

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

-- 
Aleksey