So there is something to be said about having devs shift focus from dev to testing during an RC. However, as the team grows, not all of us are really being responsible for cutting releases. Maybe that means we need to train the entire team to change current behavior, but that doesn't feel necessary/scalable.
With growing external contributions, I would have to say that a code freeze on trunk doesn't seem to make as much sense. -Michal On Thu, Dec 20, 2012 at 9:47 AM, Andrew Grieve <agri...@chromium.org> wrote: > I definitely think we'd get more done if we didn't have such a long > code-freeze. I'm not sure this is the same as what you were suggesting, but > have a script/tool to branch all of the platforms into an rc branch. Then, > each platform can fix themselves up a bit and tag their RC. Meanwhile, dev > can continue to happen on edge. > > My main concern with our current approach is just that the code-freeze time > is super long. > > > On Wed, Dec 19, 2012 at 3:36 PM, Marcel Kinard <cmarc...@gmail.com> wrote: > > > One of the things that strikes me here is the difference between calendar > > time and effort time. (This assumes folks already concurred that the rc > is > > ready to release.) Based on my reading of http://wiki.apache.org/** > > cordova/CuttingReleases > > <http://wiki.apache.org/cordova/CuttingReleases>there > isn't a lot of effort time involved to cut a release. It seems like a > > good chunk of the calendar time is getting folks to tag their platform. > > Ideally the promotion from rc to final should take very little effort > time. > > > > What I like about the rc is that it provides a settling mechanism for the > > churn to calm down, run tests across more integration, and see the bigger > > picture to assess release readiness. I would expect that the promotion > from > > edge to rc should take a decent amount of effort time, but not because of > > the "cut" activities. > > > > So when we are at rc and don't find any surprises, why does it take a > week > > to promote to final? If we spend a week in rc1, another week in rc2, and > > another week to cut final, that leaves only 1 week in a 4-week cycle for > > active dev work? > > > > I like the ideal of a channel/stream/branch/whatever where there is a > > place for the rc to settle without necessarily blocking commits to edge. > > Where I'm going with this is that if there is an area where commits to > the > > rc are carefully controlled, then perhaps one person (i.e, Steve G) could > > cut the release for ALL platforms using scripts. This may involve that > one > > person tagging/branching/whatever across multiple platforms. > > > > I also like putting the "how to cut" magic in each platform. Then perhaps > > a good chunk of coho is tests to make sure that the platform magic > > delivered the correct format to it. > > > > -- Marcel Kinard > > >
