Hi, Proposal seems good to me. Also would like to stress that I think an important change to make is not just updating the b-con levels to fit better, but really doing a time based release cycle.
>From this presentation about the google chrome release cycle: https://docs.google.com/present/view?id=dg63dpc6_4d7vkk6ch&pli=1 * The pace of the schedule sets the boundaries for the amount of work that can be completed. * It's important to have specific points in the schedule to review features and cut scope. * Establish clear expectations (and engineering practice) to developers that any features not ready to ship will be disabled. On Fri, Jul 29, 2011 at 1:59 AM, Campbell Barton <[email protected]> wrote: > If we need to do an 'a' release individualizer fixes could be applied > from trunk rather then keeping trunk frozen *just in case* we need to > do another release (could branch from the tagged rev and merge only > the fixes from trunk). > > I'd like to know what others think about doing a release and > unfreezing soon after ahoy (1-2 days). I agree, better to unfreeze trunk nearly immediate and merge critical fixes for a/b releases to a branch. Brecht. _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
