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

[Aleksey Lim]

On Fri, May 07, 2010 at 12:28:33PM +0200, Tomeu Vizoso wrote:
> On Fri, May 7, 2010 at 12:18, Aleksey Lim <alsroot at member.fsf.org> wrote:
> > On Fri, May 07, 2010 at 12:04:38PM +0200, Tomeu Vizoso wrote:
> >> 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'm not saying that 1st is less important then 2nd, I meant that 2nd
> > should grow. btw w/ 0install entirely sugar could (will, after
> > implementing Saccharin distro, 0install based sugar) be installed on
> > most of GNU/Linux distrobutions.
> 
> I still think that having a default journal makes sense and that
> having alternative implementations would hurt Sugar deployability.

libjournal is not about not having journal in glucose, it is just about
developing journal like activities that are based on libjournal, glucose
could be based on libjournal as well.

> From that derives that the default Journal should be actively
> developed, specially as fundamental parts of it are still
> unimplemented.

Don't see problems in developing such thing in libjournal, moreover,
libjournal based activities will be more cutting edge projects since
they will be developing by small groups of coders.

> I also think that if deployers discussed with you their needs and you
> had a more direct knowledge of how your work impacts learners you
> would change your mind. In any case, it's awkward that we are having
> this discussion because I don't have the authority to speak in behalf
> of deployers.

This brings us to situation when we have *only* 2nd scheme. IMHO, sugar
should grow in both ways and I don't see problems (due to limited of
resources and hugeness of task) if some of sugar related developers will
be concentrated only on one scheme.

-- 
Aleksey