On Fri, May 07, 2010 at 12:04:38PM +0200, Tomeu Vizoso wrote: > On Fri, May 7, 2010 at 11:56, Aleksey Lim <alsr...@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 <alsr...@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 _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel