If you refer to the git flow, the intention was not to make the process faster, the intention was to make the process easier and to not freeze progress on master. Both have been addressed (yes, there is a learning curve, lets give it at least one more release to conclude, yeah?)
In order to actually make things faster, I think the problem is with our organization and motivation, not the workflow. What would we actually need in order to iterate over rc's faster? Should we allocate a block of a day for a core group of devs to do nothing but test, patch, and triage? I think that was a good side effect of the old process: freezing master was such a pain, we were motivated to release quickly. I think there are other ways to get that benefit again. -Michal On Thu, Mar 28, 2013 at 4:20 PM, Joe Bowser <[email protected]> wrote: > Hey > > I'm wondering if we should just tag 2.6.0 on the long-lived branch? I > feel like we've taken too long with the RC process, and we really need > to re-evaluate this process, since it's just as slow, if not slower > than the old process. > > Thoughts? > > Joe >
