Re: [sugar] Joyride is reopened for development.
Hi all, On Wed, Mar 26, 2008 at 12:33 AM, Chris Ball [EMAIL PROTECTED] wrote: Hi, We announced the Joyride builds as having been frozen for new features several months ago, as we solidified the Update.1 build. Now that it's doing fine in its own stream, we're reopening the Joyride process for new development. So, consider Joyride to be gradually unfreezing. Please announce large changes before pushing them, and push via the Joyride ~/public_rpms process or the Koji dist-olpc2 branch. We'd like to invite a discussion about process changes to ensure that our Joyride builds continue to be stable and usable. Ideas welcome! Some of the things I would like to see during this cycle (from a localizer's point of view) are 1. A branching policy 2. Strict string freeze periods Wrt #1, At some point (say, when feature freeze for Update 2 kicks in), I would like to see _all_ the translated modules (activities, etc) to branch to a Update-2 branch (we had this in Update-1 as well, but only for Sugar, Journal, Record and Browse). This should make life easier for the developers as well (as they can continue all the fun and experimentation in the master (or is it HEAD?) branch) If #1 is implemented properly, I guess #2 should naturally follow. Thanks, Sayamindu -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Joyride is reopened for development.
On Fri, 28 Mar 2008, Sayamindu Dasgupta wrote: On Wed, Mar 26, 2008 at 12:33 AM, Chris Ball [EMAIL PROTECTED] wrote: Hi, We announced the Joyride builds as having been frozen for new features several months ago, as we solidified the Update.1 build. Now that it's doing fine in its own stream, we're reopening the Joyride process for new development. So, consider Joyride to be gradually unfreezing. Please announce large changes before pushing them, and push via the Joyride ~/public_rpms process or the Koji dist-olpc2 branch. We'd like to invite a discussion about process changes to ensure that our Joyride builds continue to be stable and usable. Ideas welcome! Some of the things I would like to see during this cycle (from a localizer's point of view) are 1. A branching policy 2. Strict string freeze periods Wrt #1, At some point (say, when feature freeze for Update 2 kicks in), I would like to see _all_ the translated modules (activities, etc) to branch to a Update-2 branch (we had this in Update-1 as well, but only for Sugar, Journal, Record and Browse). This should make life easier for the developers as well (as they can continue all the fun and experimentation in the master (or is it HEAD?) branch) If #1 is implemented properly, I guess #2 should naturally follow. one problem with this approach is that developers will tend to want to move forward with their new version and not pay the needed attention to the older version that's in the feature freeze branch. I've been watching kernel development for many years now, and they've been fighting the same problem. when a freeze starts to drag out, the rate of fixes to the frozen version drops off. their approach has been to go for quick cycles (all new things must be submitted in a 2-week window, then stabilize, release, repeat). This is working for the kernel because they are keeping the cycle time short enough that people who miss one window are willing to wait until the next one (as it's only 1-2 months away from the close of the merge window) I'm seeing the same pressures here as the releases take a while to get out. the same solution may not work, but it should be considered. David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Joyride is reopened for development.
Hi, We announced the Joyride builds as having been frozen for new features several months ago, as we solidified the Update.1 build. Now that it's doing fine in its own stream, we're reopening the Joyride process for new development. So, consider Joyride to be gradually unfreezing. Please announce large changes before pushing them, and push via the Joyride ~/public_rpms process or the Koji dist-olpc2 branch. We'd like to invite a discussion about process changes to ensure that our Joyride builds continue to be stable and usable. Ideas welcome! And finally, this doesn't mean that Update.1 is finished -- it's still very important that we keep on top of the remaining testing and bugs in that stream. Thanks! - Chris. -- Chris Ball [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Joyride is reopened for development.
Hi, We'd like to invite a discussion about process changes to ensure that our Joyride builds continue to be stable and usable. Ideas welcome! And here's my own entry, which limits itself to what we should do in the short-term, before process changes: * Stagger new features so that we maximise our chance of having a working build all the time, and so that we can take performance measurements with independent variables. * The two major features waiting to be pushed to Joyride are tomeu's faster work, which greatly improves activity launch time, and his implementation of the new Sugar shell design. We should push the faster work first so that we can measure its performance impact before and after the new UI. * Continue to have (all) activities present in Joyride builds. * Joyride should be a showcase for XO development, and including plenty of activities will help to get those activities tested. If you have an activity that works and is ready for testing by the community at large, feel free to push it into Joyride. Thanks, - Chris. -- Chris Ball [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Joyride is reopened for development.
The initial round of faster work has been pushed; look for joyride builds containing rainbow-0.7.11 or later. As always, patches are welcome. Thanks to Tomeu for this one. (Incidentally, this rainbow release also supports setting rlimits on activities via a permissions.info file. I'll try to write up some examples as my time permits, but don't wait for me if you want to play!) Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
