[Sugar-devel] Sugar Labs Roadmap.

[David Farning]

Does anyone else want to add their thoughts on:

1. What is the future availability of XO hardware? What are the
alternatives? What hardware choices are deployments going to make for
their next and future rounds of purchasing.
2. How effectively does Sugar run on the available hardware options?
What will it take to bring Sugar up to a deployment level quality on
this hardware?
3. What resources are required to make this happen?

Again, this might seem hand-wavy. An shared understanding of where the
project going is important for creating a sense of shared value. It
also helps us as individuals chose our work so that it has the most
impact on the ecosystem and the project.


On Fri, Nov 8, 2013 at 6:34 PM, Walter Bender <walter.bender at gmail.com> wrote:
> On Fri, Nov 8, 2013 at 7:19 PM, Daniel Narvaez <dwnarvaez at gmail.com> wrote:
>> On 8 November 2013 13:10, Walter Bender <walter.bender at gmail.com> wrote:
>>>
>>> Classmate and Classmate variants are already quick wide spread in some
>>> deployments, e.g., Argentina
>>
>>
>> I wonder if we should try to get some classmates in the hands of Sugar Labs
>> community members. It seems like the most solid hardware option we have for
>> deployments at the moment.
>
> I'll look into it.
>
>>
>>>
>>> > * Chromebook
>>>
>>> At least one deployment is looking at this option.
>>>
>>
>> Looking forward to know how this goes :)
>>
>>
>>>
>>> >
>>> > Another couple more for community evaluation (evaluation, testing,
>>> > marketing)
>>> >
>>> > * Linux compatible ARM boards
>>> > * Virtualbox
>>>
>>> SoaS is our current offering for Virtualbox (As you pointed out in a
>>> previous thread, it is a two-step process to install. In my
>>> experience, that is 1 too many for our audience. Something we may be
>>> able to address by approaching some of the VM suppliers.)
>>
>>
>> We are crossing threads here but... I think it would be great to have a
>> single installer but (without having tried it!) the current installation
>> process doesn't seem terribly bad. I feel that documenting it better and
>> turning it into the first thing you see when you click "downloads" could go
>> a long way.
>>
>>>
>>> > - R&D resources
>>> >
>>> > I feel balance with addressing existing deployments needs is not a
>>> > question
>>> > Sugar Labs can or should answer. We should encourage and support both,
>>> > it's
>>> > up to companies and volunteers involved to see how much of either they
>>> > could
>>> > or should be doing.
>>>
>>> +1
>>>
>>> That said, the discipline you have imparted on us regarding unit tests
>>> is a step that the community can take. Maybe one of our priorities
>>> should be to dust off some basic automatic testing for activities as
>>> well. OLPC used to have such a system in place.
>>>
>>
>> Of course I'm all for more unit tests :)
>>
>> The buildbot is already trying to start and close activities on every build
>> but it would be great if people wrote more comprehensive unit and UI tests,
>> similarly to what we are doing in the shell. Get them to run into
>> sugar-build/buildbot would be trivial...
>
> Maybe we can work on an example for an activity and then propagate (via GCI).
>
>>
>>>
>>> >
>>> > We are not a company, we have no resources to allocate. But there are
>>> > lots
>>> > of concrete things we can do to encourage people to allocate them. I'm
>>> > really glad to see that Activity Central figured out how to devote
>>> > resources
>>> > to R&D. I hope you will be able to keep it up and more people will
>>> > follow
>>> > that example. We can leverage initiatives like Google Code. We can try
>>> > crowd
>>> > funding. We can apply for grants, as we have been doing sometimes
>>> > successfully. We can keep lowering the barriers for volunteers, we have
>>> > been
>>> > making great progress on that. We can finally solve the un-marketability
>>> > issue, attracting attention and energies and hence hopefully
>>> > contributions.
>>>
>>> Google Code In starts on Nov. 18. But we can keep adding tasks over
>>> the course of the contest. Please don't be shy about suggesting tasks.
>>> And we could also use a few more mentors.
>>
>>
>> I don't think I'm able to commit to be an "official" mentor but, as usual,
>> I'll be answering as many questions as possible in irc/mailing lists when I
>> am around.
>>
>> Sort of thinking to puth GConf -> GSettings on the list... And Wayland
>> support but that's probably too complex for GCI.
>
> GConf to GSettings is definitely GCI caliber introductory task worthy.
>
> --
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel



-- 
David Farning
Activity Central: http://www.activitycentral.com