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

[Tomeu Vizoso]

On Tue, Sep 15, 2009 at 11:10, Peter Robinson <pbrobinson at gmail.com> wrote:
> 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.

I guess I should have distinguished more clear between Sugar and Sugar
Labs. Sugar is a project that is being run as part of Sugar Labs, but
there are several other projects there. SoaS is at present part of
Sugar Labs, but isn't part of the Sugar project.

I don't care too much if SoaS is part of SLs in the future or not, but
I think it's very important for Sugar so as long as not enough people
work there, I will have to spend some of my time on that project. Same
thing applies to any GNOME or KDE developers that feel that part of
their job needs to happen downstream for whatever reasons. Having SoaS
in or outside SLs is not going to change that.

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

I'm not sure how we are going to avoid forks and merges here, perhaps
in the future we get a SoaS release that works as best as possible in
several platforms and all use cases, but for now I think that
temporary forks are needed so the mainline is useful to someone.

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

If the SoaS people want to carry their specific discussions in a
fedora mailing list, that is for them to decide. I would prefer such
downstream issues to not be brought so often in sugar-devel, be SoaS
or other distros.

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

First, nothing comparable to SoaS is being produced by any other
distro I know of. Secondly, our resources are not that much
transferable, more about it below.

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

Not sure if SLs should have SoaS as its only end user product or not,
but I don't see how we could avoid other people forking it and doing
their own derivatives. Nor why we would want to avoid it.

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

It's not about they leaving, but about not creating the best
environment in which they can contribute. It makes zero sense to me to
have 1-3 guys doing a distro specifically tailored for Sugar and a
dozen of other guys looking at the side telling them how their effort
should be managed. Nor keeping a small group of overworked decision
makers on which everybody block when trying to get something done.

Part of creating that best environment is explaining very clearly what
needs to happen so that learning of our users improve and then working
together in a strategy to achieve that. But this isn't telling
contributors on what they should work, it's rather inspiring them and
keeping a connection between what we do and where we head as a
community.

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

As long as they don't know on what their time would be best spent, I
think we have. Unless our goal is to just do a cool new desktop, then
we don't need feedback from the field at all.

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

I hear this being brought up from time to time and I think Sayamindu
is in contact with Dimitris Glezos.

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

I also hope so, though I think we should make clearer that not only
developers can enter new features.

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

I spend a non-trivial slice of my time on OLPC-exclusive things and I
share your concern that we are not succeeding in working together, do
you have any ideas about how to improve this?

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

The SoaS team is already working on improving their management and
they are also asking SLs to take a position. SLs has already a
management structure that allows for these decisions to be taken,
including the leadership you refer to, you can read up in the wiki
about governance.

I'm more concerned about Sugar's leadership, because if I don't know
what needs to happen so our users can have a better learning
experience, then I don't think I can inspire other people to do
awesome work in Sugar.

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

I agree with that.

Regards,

Tomeu

-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning