[sugar] Joyride is reopened for development.

[david at lang.hm]

On Fri, 28 Mar 2008, Sayamindu Dasgupta wrote:

> On Wed, Mar 26, 2008 at 12:33 AM, Chris Ball <cjb at laptop.org> 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