[Sugar-devel] Next release

Walter Bender walter.bender at gmail.com
Thu Oct 3 11:23:55 EDT 2013


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


More information about the Sugar-devel mailing list