[Sugar-devel] Next release

[Peter Robinson]

On Thu, Oct 3, 2013 at 4:53 PM, Daniel Narvaez <dwnarvaez at gmail.com> wrote:
> It sounds like it might be an opportunity for upstream to get feedback from
> real users, which we need desperately. So I think it would be a good idea to
> "refocus" 0.100 around this deployment. So
>
> 1 Stay in bugfixing mode until January or when things are ready anyway.

What about Sugar on a Stick? We're aiming for a release as usual in
conjunction with the release of Fedora 20. It would be better to get
out a stable release in time for that to get wider testing and then do
0.100.x releases between then and January.

Peter

> 2 Make sure web activities works great on the OS you guys are shipping.
>
>
>
> On 3 October 2013 17:23, Walter Bender <walter.bender at gmail.com> wrote:
>>
>> Sorry I was not able to join the earlier discussion.
>>
>> One data point:
>>
>> In Australia, we are planning to release Sugar 100 (plus some patches
>> we hope to upstream to Sugar 102) to a few schools for extensive
>> testing (the build we are calling 1B). The intention is a
>> broader-based release of Sugar 100 (1C) in January if the testing/bug
>> fixing goes well. These builds are F18-based... don't see that
>> changing in the short term due to lack of support for F19 on the OLPC
>> hardware.
>>
>> +1 to devoting the hackfest in .PY to testing/bug fixing.
>>
>> -walter
>>
>> On Thu, Oct 3, 2013 at 9:47 AM, Manuel Quiñones <manuq at laptop.org> wrote:
>> > For the record, this is the chat we had today in #sugar dnarvaez, tch
>> > and me:
>> >
>> > <manuq> dnarvaez, I'm thinking about the release..
>> > <dnarvaez_> heh me too a bit...
>> > <dnarvaez_> somewhat lost
>> > <dnarvaez_> I'm not sure if anyone depends on 0.100 being released soon
>> > btw
>> > <manuq> dnarvaez, yeah
>> > <manuq> on one hand, people had rpms to test just recently
>> > <dnarvaez_> yeah, those didn't really generate bug reports though
>> > <manuq> on the other, I don't know if even with that, people will
>> > invest time testing
>> > <manuq> in the Paraguay meeting, EduJAM, there will be a sprint
>> > <manuq> I'll be there to push people to test and report bugs
>> > <manuq> maybe that sprint helps a bit
>> > <dnarvaez_> that's cool
>> > <dnarvaez_> I wonder if it would be better to focus on bringing web
>> > activities everywhere, and go maintenace only for native sugar
>> > <dnarvaez_> there seem to be little point to develop new native
>> > features if people don't even bother testing them
>> > <dnarvaez_> web activities could potentially work everywhere, so maybe
>> > they have a wider audience
>> > <manuq> dnarvaez, yes, I think this has to be planned with deploys, I
>> > hope the meeting in Paraguay helps with this too
>> > <manuq> yes
>> > <manuq> there are countries using very old Sugar releases
>> > <dnarvaez_> from the ml it seems like most are :/
>> > <tch__> manuq: you should do a workshop for sugar html5 acivities devel
>> > <dnarvaez_> I guess it's either figure out how to get those to upgrade
>> > <dnarvaez_> or make sugar-web work on those releases
>> > <manuq> tch__, yes, I will.  It will be the Sunday
>> > <tch__> manuq: great!
>> > <manuq> dnarvaez, +1
>> > <manuq> dnarvaez, with gonzalo we made sugar-web work in previous
>> > releases (WebKit1)
>> > <tch__> dnarvaez_: paraguay has 0.88 but we are planning to move to
>> > something newer, probably at february 2014
>> > <manuq> tch__, that's great news
>> > <dnarvaez_> the fact that developers are not dogfooding is also a big
>> > issue, but not sure there is a solution for that, we are not our
>> > target user
>> > <dnarvaez_> tch__: great
>> > <manuq> dnarvaez, I think the community is in a transition too,
>> > previous releases were handled almost exclusively by olpc people, and
>> > we were the ones fixing most of the bugs
>> > <manuq> now the community has to give a step further
>> > <tch__> manuq: dnarvaez_ this problem is not new, deployments move in
>> > a diffrent pace than we do, and we need to figureout how to solve it
>> > <manuq> tch__, yeah
>> > <dnarvaez_> manuq: yeah though in the new situation I'm not sure who
>> > has interest to bring out the release at all... I'm not sure soas has
>> > any real users and deployments seems content with the old releases (or
>> > too scared to update :P)
>> > <tch__> dnarvaez_: manuq testing doesn't get done because what we do
>> > today lands 2 yars after to real users
>> > <tch__> dnarvaez_: today updating is a big logistic problem for
>> > deployments, but there is also some level of fear to change
>> > <dnarvaez_> tch__: and the lack of testing surely doesn't incourage
>> > deployments to update sooner, because quality is low...
>> > <tch__> dnarvaez_: the thing is that real testing == real users
>> > <tch__> dnarvaez_: we need to break the vicious circle
>> > <manuq> what if deploys sponsor a few children for testing?
>> > <dnarvaez_> it would be nice to get at least one deployment to upgrade
>> > and report their issues
>> > <tch__> dnarvaez_: manuq we did that with the first dextrose version
>> > and it went really well,
>> > <dnarvaez_> but I'm not sure how/if that's possible, I have no idea of
>> > what is going on in the deployments
>> > <dnarvaez_> manuq: sounds like a nice idea
>> > <manuq> well, at least the ones with XO-4 had to upgrade to get the
>> > touchscreen features
>> > <tch__> dnarvaez_: manuq but for having real users you need to give
>> > the users something that motivates them to test it
>> > <manuq> tch__, yeah.. I think "Sugar Tester" could be a good title for
>> > children in a classroom
>> > <manuq> like a prize
>> > <manuq> but they might need more motivation than a title
>> > <tch__> manuq: dnarvaez_ motivation comes in many different forms
>> > <tch__> manuq: motivation is just one part of the problem, the other
>> > is the logistic one
>> > <tch__> how do we prepare this build, distribute and do the following up
>> > <dnarvaez_> bugs being fixed in sometimes a reward too...
>> > <manuq> yeah
>> > <manuq> tch__, the other actor then is a coordinator in each deployment
>> > <dnarvaez_> any reason small, automatic, incremental updates wouldn't
>> > work?
>> > <manuq> dnarvaez, that's the ideal
>> > <dnarvaez_> why we are not doing it then? :)
>> > <manuq> dnarvaez, I guess each deploy is a different scenario
>> > <manuq> dnarvaez, some, for example, lack connectivity
>> > <dnarvaez_> yeah, though this doesn't even have to work for all
>> > deployments
>> > <tch__> continous integration sounds  good, but also requires
>> > infrastructure
>> > <dnarvaez_> if it works for one it would be great already
>> > <dnarvaez_> tch__: on the dev side or on deployments side?
>> > <tch__> both
>> > <tch__> we tried doing that with simple yum updates, but is has its
>> > limits..
>> > <dnarvaez_> one of the issue on the dev side is that fedora releases
>> > are not incremental I think
>> > <manuq> dsd was doing nice things to the updater
>> > <dnarvaez_> so people are now scared of doign F18 -> F19 now for example
>> > <tch__> dnarvaez_: I think the eternal issues is the disk space and
>> > bandwidth
>> > <dnarvaez_> tch__: why wouldn't the olpc updater work?
>> > <manuq> dnarvaez, yeah jumping from one OS release to the other is a
>> > major issue, but the updater should work fine for most of the updates
>> > <dnarvaez_> tch__: bandwidth not much we can do I suppose :/ disk
>> > space you mean people are getting too low space to be able to upgrade>
>> > <dnarvaez_> ?
>> > <tch__> dnarvaez_: we never really test back then, it wasn't
>> > recommended even by olpc during that time
>> > <tch__> dnarvaez_: I think has improved since then
>> > <dnarvaez_> if we keep the OS stable updates would be really small I
>> > think
>> > <manuq> tch__, you better contact dsd, I think he makes good use of
>> > the updater in Nicaragua
>> > <dnarvaez_> probably making disk and bandwith a non issue
>> > * satellit_e I see the problem as being the fedora rapid development
>> > cycle : /
>> > <dnarvaez_> satellit: we don't necessarily have to follow it these days
>> > <dnarvaez_> I could see sugar sticking on F19 + few packages for a few
>> > years
>> > <satellit_e> f18-f19 being an example   I work on Soas and it is tough
>> > to stay up
>> > <dnarvaez_> there are security updates but... I'm not sure that's a real
>> > issue
>> > <dnarvaez_> people has stayed for years on very old versions anyway :)
>> > <manuq> dnarvaez, +1
>> > <tch__> dnarvaez_: we still use f11!!
>> > <icarito> this conversation is interesting i'm on the other side of the
>> > coin now
>> > <tch__> if think we can split this problem, and solve things we can,
>> > IE, what we can do is having this "newer sugar build"
>> > <tch__> other problem is the incremental updates, we need to figure
>> > out how olpc updater works
>> > <dnarvaez_> "newer sugar build"?
>> > <tch__> yeah, something we can give deployments
>> > <dnarvaez_> tch__: I know more or less how it works
>> > <dnarvaez_> I'm not sure if we should try to get an F19 image working
>> > <dnarvaez_> or if we should settle on F18
>> > <tch__> dnarvaez_: I know how to make them too, but the thing is mantain
>> > it
>> > <tch__> dnarvaez_: and I think it should be closely tied to SL
>> > releass, if not real continuos
>> > <dnarvaez_> setting up automatic builds of olpc images with latest
>> > sugar code would not be hard
>> > <dnarvaez_> if that's what you are thinking about
>> > <tch__> dnarvaez_: you should come to paraguay too ;)
>> > <dnarvaez_> heh
>> > <tch__> dnarvaez_: I think I can provide the logistics for doing this..
>> > <tch__> dnarvaez_: I am closely related to the deployment and I know a
>> > bunch of geeks who would like to be part of the following up team
>> > <dnarvaez_> great :)
>> > <tch__> dnarvaez_: what we need is figure out how do create these
>> > builds, and define how to update
>> > <dnarvaez_> tch__: we could build rpms automatically in a buildbot
>> > instance and also run the os image scripts in it
>> > <dnarvaez_> tch__: about updates, I'm still not sure to understand
>> > which issues you see with olpc updater
>> >
>> > --
>> > .. manuq ..
>> > _______________________________________________
>> > Sugar-devel mailing list
>> > Sugar-devel at lists.sugarlabs.org
>> > http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>>
>>
>> --
>> Walter Bender
>> Sugar Labs
>> http://www.sugarlabs.org
>
>
>
>
> --
> Daniel Narvaez
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>