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

[Tomeu Vizoso]

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.