[IAEP] [Sugar-devel] The Future of Sugar on a Stick

Simon Schampijer simon at schampijer.de
Tue Sep 15 05:54:22 EDT 2009


On 09/15/2009 10:24 AM, Tomeu Vizoso wrote:
> FWIW, as a (upstream) Sugar developer what I would like to see is:
>
> == Further separation between upstream and downstreams ==
>
> Without artificially privileging nor discriminating any downstream. So
> a big +1 to giving a stronger identity to the SoaS project and to
> creating a separate mailing list.
>
> We already have devel at lists.laptop.org for OLPC,
> fedora-olpc-list at redhat.com and others for Fedora,
> debian-olpc-devel at lists.alioth.debian.org for Debian,
> ubuntu-sugarteam at lists.ubuntu.com for Ubuntu. Why SoaS would be
> different and share the mailing list with the upstream developers?
>
> As I'm also personally involved in SoaS (because as an individual I
> chose to) I will subscribe to the new SoaS ml and will crosspost as I
> see fit, but I don't think this should be SLs policy.
>
>
> == SLs to decide if it wants to produce an end-user product ==
>
> If we agree on this, then I think it will be easier to decide if
> there's value in designating one as the preferred consumer-oriented
> product and which distro that would be.

I always argued that SL should not do products, and I will still argue 
the same. Soas should have it's own identity. If SL people feel 
passionate about that idea, they can contribute to that project. For me 
SL is *just* a gathering place and we can coordinate our efforts. Soas 
should in my opinion work like any other open source project, like sugar 
for example. If olpc-uruguay is interested in sugar, they contribute to 
the upstream project, if GPA is, they do the same, if I as a developer 
am, I do the same.

We had the same situation a few weeks ago, when it came to the sucrose 
schedule. It is good to be aware of each projects schedule, SL can not 
choose to decide when Sucrose is released. This needs to be decided by 
the people that know the impact of such a decision (aligned to 
distribution schedules). Of course people can make suggestions.

Regards,
    Simon






More information about the IAEP mailing list