[Sugar-devel] Squeak / Etoys development under Sugar (was: Object Chooser)

[Ajay Garg]

Thanks Bert.


On Fri, Jun 8, 2012 at 5:48 PM, Bert Freudenberg <bert at freudenbergs.de>wrote:

> On 07.06.2012, at 21:36, Ajay Garg wrote:
>
> > Thanks Bert for the reply.
> >
> > On Thu, Jun 7, 2012 at 8:27 PM, Bert Freudenberg <bert at freudenbergs.de>
> wrote:
> >> On 07.06.2012, at 15:57, Ajay Garg wrote:
> >>
> >> > Hi Bert.
> >> >
> >> > a)
> >> > Could you give a rough idea, as to what is the release cycle for
> squeak-vm?
> >>
> >> There is no fixed release cycle, releases are done as needed and as
> time permits. Once or twice a year has been typical.
> >>
> >> What is your time frame? If need be one could package a Squeak VM +
> patches.
> >
> > 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.





>
> > It will be best, if you could provide with any of the following options
>  ::
> >
> > a)
> > "squeak-vm-4.4.47 RPM for x86 "AND "squeak-vm-4.4.47 RPM for ARM".
> >
> >                                            OR
> > b)
> > "squeak-vm-4.4.47 SRPM".
>
> I can't provide any of that. My spare time is limited, you know ;)
>

No problem :)
I have written a spec file, which (for now) takes in the pre-compiled
binaries (for a particular platform), and simply packages them.








>
> (I am a freelancing developer, but my schedule is pretty full. I take on
> the occasional contract, in particular if
>
> > 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?



Thanks and Regards,
Ajay



>
> - Bert -
>
> PS: it would be nice if you could disable the HTML mails in your client.
> Makes proper quoting hard.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20120608/f8cc31da/attachment.html>