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

[Marco Pesenti Gritti]

On Dec 15, 2007 3:54 PM, Bernardo Innocenti <bernie at codewiz.org> wrote:
> 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.

Exactly. Can we get this right for Update.2? :)

Marco