[Sugar-devel] Next release

[Manuel Quiñones]

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