Builds and release process ( was Re: Update.1 schedule and code freeze...)

Marco Pesenti Gritti mpgritti at gmail.com
Sat Dec 15 09:43:24 EST 2007


On Dec 15, 2007 3:14 PM, C. Scott Ananian <cscott at cscott.net> wrote:
> On Dec 15, 2007 7:35 AM, Marco Pesenti Gritti <mpgritti at gmail.com> wrote:
> > On Dec 14, 2007 11:01 PM, Jim Gettys <jg at laptop.org> wrote:
> > > Declaring code freeze for Update.1 today would not see a rational
> > > resolution of these issue.  As promised, this is a release that is
> > > driven by completion of content, rather than driven by necessity of
> > > hardware schedules.
> >
> > On the Sugar side, the main reason of the delay is that dealing with
> > the various release process steps has been a lot more painful then it
> > needs to be. We wasted a *lot* of time there.
>
> My personal feeling is that we created update.1 too soon.  IMO
> development should have been occurring in the joyride builds up until
> code freeze (yesterday, or a week from yesterday).  There's no reason
> to fork update.1 just for string freezes; translation can still occur
> in the joyride branch.  Code freeze is the point at which we should
> fork the builds.

I agree that branching should happen at code freeze. But then
ApprovalForUpdate should only be introduced *after* the freeze and
update.X should be branched from joyride. Otherwise ApprovalForUpdate
tickets accumulate for weeks, until we branch, and then we get to
cleanup the mess.

We already have an approval step in place (Update.1? -> target
Update.1) and IMO that's enough for the development period.

Marco



More information about the Devel mailing list