See below the proposed schedule for the next Sugar release.
Since Etoys is part of Sugar, we will need to have some version ready for this.
- Bert -
Begin forwarded message:
From: Simon Schampijer simon@schampijer.de Date: 20. November 2009 18:38:07 MEZ To: Sugar-dev Sugar-devel@lists.sugarlabs.org Subject: [Sugar-devel] Roadmap to 0.88 --- Proposal
Hi,
I have written a proposal for the new 0.88 schedule [1]. Basically, I followed the GNOME schedule for 2.30 [2]. Following in terms of dates, and I have added certain new freezes we did not have before.
In detail:
- tarballs due will be on Mondays, and the release on Wednesdays: I hope
this will allow us to see the tarballs packaged by the end of the week by the distributions ---> getting more testing done over the weekend
- UI Freeze added: No UI changes may be made without approval from the
release-team and notification to the documentation list. Having such a freeze helps documentation efforts, and to not introduce workflow regressions and issues late in the cycle.
- The feature freeze and API freeze is earlier compared to previous
cycles. This should help to get a more stable release at the envisioned release date. After this shortened release cycle, from one feature freeze to the next one, there will be always 6 months. So the same amount of time to allow for development of features.
- To allow for long term planning, I have drafted the 0.90 schedule, too
[3]. This should help to schedule bigger features.
- Testing: I hope to see much much more testing in this release cycle.
Two things should help here: a) I encourage the creation of a testing team. b) The 0.88 release will be packaged early. For testing purposes 0.88 will be packaged for F12. Other distributions are encouraged to do similar.
- Feature Process: We will follow the process [4] defined in the 0.86
cycle. It will be communicated another time.
- Getting it into a release: As we follow the same schedule as GNOME is,
we should have no issues in getting our packages into the distributions in time. See the F13 [5] for example.
Comments welcome, Simon
[1] http://wiki.sugarlabs.org/go/0.88/Roadmap#Schedule [2] http://live.gnome.org/TwoPointTwentynine [3] http://wiki.sugarlabs.org/go/0.90/Roadmap#Schedule [4] http://wiki.sugarlabs.org/go/Features/Policy [5] https://fedoraproject.org/wiki/Releases/13/Schedule _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
I would like to see DrGeo shipped in this next version if possible. It will make easier for XO user to save/load project with interactive geometry.
Hilaire
2009/11/20 Bert Freudenberg bert@freudenbergs.de:
See below the proposed schedule for the next Sugar release.
Since Etoys is part of Sugar, we will need to have some version ready for this.
- Bert -
Begin forwarded message:
From: Simon Schampijer simon@schampijer.de Date: 20. November 2009 18:38:07 MEZ To: Sugar-dev Sugar-devel@lists.sugarlabs.org Subject: [Sugar-devel] Roadmap to 0.88 --- Proposal
Hi,
I have written a proposal for the new 0.88 schedule [1]. Basically, I followed the GNOME schedule for 2.30 [2]. Following in terms of dates, and I have added certain new freezes we did not have before.
In detail:
- tarballs due will be on Mondays, and the release on Wednesdays: I hope
this will allow us to see the tarballs packaged by the end of the week by the distributions ---> getting more testing done over the weekend
- UI Freeze added: No UI changes may be made without approval from the
release-team and notification to the documentation list. Having such a freeze helps documentation efforts, and to not introduce workflow regressions and issues late in the cycle.
- The feature freeze and API freeze is earlier compared to previous
cycles. This should help to get a more stable release at the envisioned release date. After this shortened release cycle, from one feature freeze to the next one, there will be always 6 months. So the same amount of time to allow for development of features.
- To allow for long term planning, I have drafted the 0.90 schedule, too
[3]. This should help to schedule bigger features.
- Testing: I hope to see much much more testing in this release cycle.
Two things should help here: a) I encourage the creation of a testing team. b) The 0.88 release will be packaged early. For testing purposes 0.88 will be packaged for F12. Other distributions are encouraged to do similar.
- Feature Process: We will follow the process [4] defined in the 0.86
cycle. It will be communicated another time.
- Getting it into a release: As we follow the same schedule as GNOME is,
we should have no issues in getting our packages into the distributions in time. See the F13 [5] for example.
Comments welcome, Simon
[1] http://wiki.sugarlabs.org/go/0.88/Roadmap#Schedule [2] http://live.gnome.org/TwoPointTwentynine [3] http://wiki.sugarlabs.org/go/0.90/Roadmap#Schedule [4] http://wiki.sugarlabs.org/go/Features/Policy [5] https://fedoraproject.org/wiki/Releases/13/Schedule _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
Sugar releases are pretty much independent of XO software releases.
E.g., OLPC is working on a software release for the XO-1.5. It is based on Fedora 11, and it will use the Sugar version packaged in Fedora 11 - namely, 0.84. In the mean time, Sugar 0.86 has been released already and development of 0.88 has started (and Fedora 12 has been released too). There is a difference between development and shipping to end-users. And there is no telling yet when later Sugar releases will make it into an XO update.
OTOH, F11-1.5 includes the latest Etoys version packaged for it, which already is much more recent than Sugar 0.84 (currently, etoys-4.0-2332). Soon there should be a 4.0.2337 (I just pushed Yoshiki's fix for SQ-565). So the Etoys release version *shipped* is not necessarily tied closely to the Sugar version.
That said, I agree it would be great to have a version including DrGeo ready for Sugar 0.88. At least we might get some more testing that way. And since Sugar itself is not stable yet, we could release a development version around the time - provided we don't break too much until then. We simply need to declare a certain interim Etoys version the "official" one for that Sugar release. Another option would be to follow the Sugar release cycle more closely.
For the XO 1.5 we need to have a stable version. Currently it looks like that's going to be Etoys 4 + critical fixes (that is, only SQ-565 so far). Unless OLPC slips past the Etoys 5 release, of course ;)
- Bert -
On 23.11.2009, at 07:52, Hilaire Fernandes wrote:
I would like to see DrGeo shipped in this next version if possible. It will make easier for XO user to save/load project with interactive geometry.
Hilaire
2009/11/20 Bert Freudenberg bert@freudenbergs.de:
See below the proposed schedule for the next Sugar release.
Since Etoys is part of Sugar, we will need to have some version ready for this.
- Bert -
Begin forwarded message:
From: Simon Schampijer simon@schampijer.de Date: 20. November 2009 18:38:07 MEZ To: Sugar-dev Sugar-devel@lists.sugarlabs.org Subject: [Sugar-devel] Roadmap to 0.88 --- Proposal
Hi,
I have written a proposal for the new 0.88 schedule [1]. Basically, I followed the GNOME schedule for 2.30 [2]. Following in terms of dates, and I have added certain new freezes we did not have before.
In detail:
- tarballs due will be on Mondays, and the release on Wednesdays: I hope
this will allow us to see the tarballs packaged by the end of the week by the distributions ---> getting more testing done over the weekend
- UI Freeze added: No UI changes may be made without approval from the
release-team and notification to the documentation list. Having such a freeze helps documentation efforts, and to not introduce workflow regressions and issues late in the cycle.
- The feature freeze and API freeze is earlier compared to previous
cycles. This should help to get a more stable release at the envisioned release date. After this shortened release cycle, from one feature freeze to the next one, there will be always 6 months. So the same amount of time to allow for development of features.
- To allow for long term planning, I have drafted the 0.90 schedule, too
[3]. This should help to schedule bigger features.
- Testing: I hope to see much much more testing in this release cycle.
Two things should help here: a) I encourage the creation of a testing team. b) The 0.88 release will be packaged early. For testing purposes 0.88 will be packaged for F12. Other distributions are encouraged to do similar.
- Feature Process: We will follow the process [4] defined in the 0.86
cycle. It will be communicated another time.
- Getting it into a release: As we follow the same schedule as GNOME is,
we should have no issues in getting our packages into the distributions in time. See the F13 [5] for example.
Comments welcome, Simon
[1] http://wiki.sugarlabs.org/go/0.88/Roadmap#Schedule [2] http://live.gnome.org/TwoPointTwentynine [3] http://wiki.sugarlabs.org/go/0.90/Roadmap#Schedule [4] http://wiki.sugarlabs.org/go/Features/Policy [5] https://fedoraproject.org/wiki/Releases/13/Schedule _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
That said, I agree it would be great to have a version including DrGeo ready for Sugar 0.88. At least we might get some more testing that way. And since Sugar itself is not stable yet, we could release a development version around the time - provided we don't break too much until then. We simply need to declare a certain interim Etoys version the "official" one for that Sugar release. Another option would be to follow the Sugar release cycle more closely.
For the XO 1.5 we need to have a stable version. Currently it looks like that's going to be Etoys 4 + critical fixes (that is, only SQ-565 so far). Unless OLPC slips past the Etoys 5 release, of course ;)
Shipping DrGeo into this Etoys version for XO 1.5 should not break any things. It has been used in a dedicated etoys image since several months, both for XO or PC. Of course we'd want it to be documented, but this is another story.
Hilaire
On 23.11.2009, at 18:46, Hilaire Fernandes wrote:
That said, I agree it would be great to have a version including DrGeo ready for Sugar 0.88. At least we might get some more testing that way. And since Sugar itself is not stable yet, we could release a development version around the time - provided we don't break too much until then. We simply need to declare a certain interim Etoys version the "official" one for that Sugar release. Another option would be to follow the Sugar release cycle more closely.
For the XO 1.5 we need to have a stable version. Currently it looks like that's going to be Etoys 4 + critical fixes (that is, only SQ-565 so far). Unless OLPC slips past the Etoys 5 release, of course ;)
Shipping DrGeo into this Etoys version for XO 1.5 should not break any things. It has been used in a dedicated etoys image since several months, both for XO or PC. Of course we'd want it to be documented, but this is another story.
Hilaire
In that case we would need to plan doing a 4.1 release, which would add Dr Geo as new feature. This needs to be available on all platforms, otherwise projects authored under Sugar could not be loaded on other computers.
You might want to bring this up in the IRC developers meeting today.
- Bert -
Hi everyone,
Until we have more developers, let's stick to one public release per year, at least for Etoys 5. Remember, we cannot rely on Bert, Yoshiki, and Scott after New Year's.
As for developer releases, we can be more regular ... and we can encourage people to use alpha/beta releases, which will help with our testing.
To get into a regular rhythm, let's do installer builds on the first of each month, if there's enough change to warrant it (decided at dev meet).
We could call the developer builds .... Etoys 5 alpha 1, Etoys 5 alpha 2, etc, or 5a1, 5a2. When we reach "brave user" level stability, we switch to Etoys 5 beta 1, etc, or 5b1.
In other words .... to the community, alpha means "risky, you will find bugs", beta means "please test personally" .... final means, "use in your classrooms."
Here's a potential release cycle:
Dec 1st ... Etoys 5 alpha 1 ... includes Dr Geo, with update stream & build on skylab
Jan 1st ... Etoys 5 alpha 2 ... riskiest changes first
Feb 1st ... Etoys 5 alpha 3 ... debatable UI changes
Mar 1st ... Etoys 5 alpha 4 ... last iffy build
Apr 1st ... Etoys 5 beta 1 ... community review of UI and new features
May 1st ... Etoys 5 beta 2 ... includes community suggestions
June 1st ... Etoys 5 release candidate ... code freeze
June 21st ... Etoys 5 final ... nothing but criticals and blockers
This means we need to "get the hood down" partially for the first four releases, and completely for the next three.
Thoughts?
Tim
On Tue, Nov 24, 2009 at 9:16 PM, Timothy Falconer timothy@squeakland.org wrote:
Feb 1st ... Etoys 5 alpha 3 ... debatable UI changes Apr 1st ... Etoys 5 beta 1 ... community review of UI and new features
I know you said several times in meeting log hat UI changes needed but detail about what part and aspect you are going to change have not been discussed yet (at least not logged in meeting minutes). You might say idea is evolving in your brain but I would say you should plan how idea will be disclosed and discussed in community. For an instance some early sketch or mock up could be shared and discussed in much earlier stage. And do you think who will actually develop the UI stuff?
/Korakurider
Korakurider,
I'm working on a goals document that includes mockups.
As for who, the visuals will certainly be shown before they become real. I plan to do what I've always done ... find a designer with an interesting portfolio, then ask for a design or two. On big jobs I get as many as three designers and let stakeholders decide, which in this case would be the teams and community.
My overall goal is to create a fresh new look throughout ... a new skin. I want Etoys to look like it's a recent thing.
Take care, Tim
On Nov 24, 2009, at 11:56 PM, Korakurider wrote:
On Tue, Nov 24, 2009 at 9:16 PM, Timothy Falconer timothy@squeakland.org wrote:
Feb 1st ... Etoys 5 alpha 3 ... debatable UI changes Apr 1st ... Etoys 5 beta 1 ... community review of UI and new features
I know you said several times in meeting log hat UI changes needed but detail about what part and aspect you are going to change have not been discussed yet (at least not logged in meeting minutes). You might say idea is evolving in your brain but I would say you should plan how idea will be disclosed and discussed in community. For an instance some early sketch or mock up could be shared and discussed in much earlier stage. And do you think who will actually develop the UI stuff?
/Korakurider
-- Timothy Falconer Squeakland Foundation http://squeakland.org 610-797-3100 -- "Intelligence is what you use when you don't know what to do." ... piaget
etoys-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Hilaire Fernandes -
Korakurider -
Timothy Falconer