<div dir="ltr"><div>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 </div><div>1 Stay in bugfixing mode until January or when things are ready anyway. </div><div>2 Make sure web activities works great on the OS you guys are shipping. </div><div> </div></div><div class="gmail_extra"> <div class="gmail_quote">On 3 October 2013 17:23, Walter Bender <<a href="mailto:walter.bender@gmail.com" target="_blank">walter.bender@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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 <div><div class="h5"> On Thu, Oct 3, 2013 at 9:47 AM, Manuel Quiñones <<a href="mailto:manuq@laptop.org">manuq@laptop.org</a>> 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 .. </div></div>> _______________________________________________ > Sugar-devel mailing list > <a href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a> > <a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a> -- Walter Bender Sugar Labs <a href="http://www.sugarlabs.org" target="_blank">http://www.sugarlabs.org</a> </blockquote></div> -- Daniel Narvaez </div>