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