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

[Aleksey Lim]

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

Well, maybe my first steps on 2nd way were affected by lack of
communication w/ real deployments, but for now, it is my deliberate
intention.

-- 
Aleksey