[Sugar-devel] Next release

[Daniel Narvaez]

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.
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20131003/83f21a15/attachment-0001.html>