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

[Bernardo Innocenti]

C. Scott Ananian wrote:

> 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 approve of delaying code freeze slightly in the
> interest of making the freeze firmer when it occurs.

+1

The moment we create a release branch and start cherry picking
packages for inclusion one by one, we effectively are already
in some sort of code freeze.

Many centralized projects I've worked for tend to have a 2/3
development and 1/3 code freeze time share in each release cycle,
which seem like a good compromise for a lightweight development
process that still allows enough time for stabilization.

Moreover, I was very confused by the fact that we branched Update.1
from Ship.2 rather than from Joyride, which I still considered our
development trunk.  Until a few days ago, I've been working under
the assumption that all the work I had done in Joyride before
Dec 15 would implicitly show up in Update.1.


> As you all know, the main problem with developing in the joyride
> builds have been ensuring its continued stability and usability for
> developers; Michael, I, and others have (as time has permitted!) been
> working on integrated automated testing to help address that issue --
> joyride builds will not be released for general use unless they pass
> automated testing.  I've put that work on hold while I try to finish
> up my update.1 feature set, but I hope to get back to it after code
> freeze.

Looking forward to see this work!  I've been missing our old 

-- 
 \___/
 |___|   Bernardo Innocenti - http://www.codewiz.org/
  \___\  One Laptop Per Child - http://www.laptop.org/