On 2012-06-08, at 15:20, Ajay Garg wrote: > On Fri, Jun 8, 2012 at 5:48 PM, Bert Freudenberg <b...@freudenbergs.de> wrote: >> On 07.06.2012, at 21:36, Ajay Garg wrote: >> >> > Well, we need the squeak-vm (with the "Mpeg3Plugin.c" fix) for ceibal >> > right-away. >> >> What do you mean, "for ceibal"? >> >> OLPC is working on 11.3.1, which is based on Sugar 0.94, but appears to be >> fairly stable. 12.x is in the works too but a bit further off. I'd have >> assumed that Plan Ceibal takes the latest OLPC release and customizes it. Is >> that not so? How does your release process work? > > Well yes, that is exactly what Plan Ceibal does. > We do the release work, as and when required by Ceibal.
So which version are you working on? 11.3.1 or 12.1.0? I am confused by you saying you need it "right-away", since OLPC has not released anything yet that you then could customize and test. The two Etoys regressions I'm aware of in 12.1.0 is that the camera does not work (because the new squeak vm has not been released nor packaged) and that sharing doesn't work with a jabber server (because the presence service breaks when using gabble). There may also still be sound playing/recording issues. Are you tracking this work on dev.laptop.org? Or at sugarlabs? Somewhere else? I'm also confused by who does what, when. >> > So, all we need to do is replace the "old" etoys.image and etoys.changes >> > with the "latest" etoys.image and etoys.changes, respectively? >> > If yes, then we would be needing the SRPM for etoys-5.0.2406. (Or the >> > older SRPM for etoys-4.1 would do ?) >> >> Err, not so fast. What I described is how you can develop stuff, and how you >> can test stuff that is in development. >> >> You're welcome to submit fixes upstream. Here's a brief Etoys developer >> how-to: >> >> http://etoys.squeak.org/svn/trunk/Documentation/Developer-HowTo.txt >> >> Also, please subscribe to etoys-dev and tell us what you're doing: >> >> http://lists.squeakland.org/mailman/listinfo/etoys-dev >> > > Bert, I am sorry, as I wasn't clear. The detailed use-case follows :: > > a) > There is the branch etoys 5.0 > > b) > However, there are still some packages, which need updating (via "update code > from server"). Done. > > c) > Now, all that is needed to be done, is to package etoys in such a way, that > etoys-image (when next launched), does not re-need "update code from server". > Of course, any local changes (that have been not been pushed upstream), don't > take effect. The important thing is that, the upstreamed changes should be > the latest one. No "update code from server" should be needed again. > > I was asking about this use-case. In this, would the simple replacements of > etoys.image, and etoys.contents work? It might work, but I'd rather follow proper procedure. We are planning a bugfix release for Etoys, just like Sugar had bug fix releases for 0.96. Also, I was under the impression that you were looking into the MP3 rewind problem. If you have a fix for that you should submit it upstream. Or at least open a ticket at http://tracker.squeakland.org/ >> PS: it would be nice if you could disable the HTML mails in your client. >> Makes proper quoting hard. Still HTML. - Bert - _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
