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

[Peter Robinson]

On Tue, Sep 15, 2009 at 9:24 AM, Tomeu Vizoso <tomeu at sugarlabs.org> 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.

By creating a separate distribution you are already discriminating
other distributions. You don't see GNOME or KDE creating an entire
distro around their product. They leave that to the people that have
the skills, resources and man power to do it. That said if there is to
be a separate distribution there needs to be ONE SoaS that everyone
contributes to. I know of at least 3-4 differing variants of the
Strawberry release and that doesn't take into account the laptop.org
variants.

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

Because being based on Fedora the vast majority of the issues are
either sugar related and need to the sugar developers or fedora
related and should go to one of the fedora lists. The remainder are
then likely to be policy based and go to IAEP or the like.

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

There's arguments for and against. I've mentioned the Sugar is a
desktop environment and GNOME etc don't produce full distros. Also if
there's so little resources available why spend a lot of engineering
time to create something that is already being created quite
successfully by distributions. I honestly don't really have an opinion
either way. I think the load of work has reduced a lot since we've
either got the changes upstream or discarded/re-engineered the changes
required so as not to need changes to upstream. This also has the
advantage of making it a lot easier for distribution packagers.

If the decision is made to create an end user problem there has to be
ONE SoaS. No Strawberry Trees and all the various other ones. SoaS is
SoaS. Period.

> == SLs to keep empowering the people who choose to do stuff ==
>
> We have almost no budget, so we cannot tell people on what they should
> work. So unless people can do what they want and they feel supported
> by SLs, we are going to disappear quite soon.

Open source is great because if people don't like something they can
pack up their toys and go and play somewhere else. That doesn't mean
there can't be any rules of the playground. Its not about telling
people what to do or not to do its about having a vision so people can
work generally towards it. There needs to be more leadership rather
than people pansying around worried that if they tell someone what or
how to do it they'll leave.

> Just to make it clear, by "do" I don't mean only to code. Actually, we
> could say that we have a surplus of coders if we see releases as a
> continuous process that starts from identifying needs and ends with
> publishing solutions to them.

I doubt we do have surplus coders.... but anyway.

> We need people that talk to users and deployers, that translate and
> consolidate the feedback, that provide this information in a way
> usable by coders and, very importantly, that close the cycle by
> telling deployers which of their needs have been addressed in a new
> release.

Speaking of translations. Has anyone looked at transifex?

> The GPA deployment team has done a remarkably good job at explaining
> their needs and I have been giving priority to those issues over the
> ones expressed by individuals. But still there's lots of room to
> improve: needs should be expressed in a more appropriate moment of the
> release cycle, we need to find a way for deployers to engage in the
> feature process and we need a very simple way for a developer to know
> which issues are important where.

I think that will improve with the new Features process that's been
implemented in this cycle once people get more use to it.

> Most other deployments are totally absent from our community and a few
> others have made too timid attempts to express their needs. This needs
> to change. We have made a call for help with bug triaging and the
> developers are having to do that ourselves because no one replied.
> Several people have spent hours writing emails criticizing developers
> for how little we care about OLPC, but cannot spend less than that
> time in helping triaging bugs.

I'm not sure of the current management interaction between OLPC and
Sugar but from a outsider looking in the term "frosty" comes to mind.
It seems the laptop.org and sl.org mailing lists very much stick to
themselves. The way I look at it both side of the fence are a much at
fault as each other.

> With such an enormous hole in our community I don't think we can tell
> an individual like Sebastian that he should row his boat in some other
> direction. We are still too weak and depend too much on such
> passionate people to waste them.

Well you can. I don't think we should. What needs to happen is to have
someone from Sugar Labs actually give people direction. We need a
leader so that everyone is rowing in unison. At the moment SoaS is a
large boat with a dozen or so people all trying to row in a different
direction at different speeds. At the moment all I see that's going to
happen the is that the boat will come apart and sink. Who are the
people that make up the "official" sugar labs? I have no idea who they
are? Who gives SL its current direction? Who is the leader(s)? Who
makes the decision about whether SoaS is an official product?

I think that final question needs to be answered, and if there's to be
an official product a SoaS Maintainer should then be appointed as a
central point of contact and direction. Whether that be Sebastian or
someone else official from SL. Once that is done all other SoaS must
go away so there is ONE SoaS distribution, I'm not talking about Sugar
Desktops in mainline distributions here - we want them -> they are
good!

Peter