On Monday, July 15, 2013 11:51:38 Scott Kitterman wrote: > 30 of the 42 weeks are spent in some kind of freeze state. Without process > changes to get from "feature complete" to "released" there's no way to get > to a three month cycle.
those of us in favour of a shorter development cycle are also recommending topic branch based development, with optional integration branches for code bases that have multiple concurrent changesets being worked on. with topic branches and multi-topic merge branches where necessary, it is quite clear how one can do 3 month cycles with very little freeze period. in such a regime, any freeze period should only be what is necessary for packaging, artwork or translation. development itself should never freeze, only merging of topic branches during freezes as for packaging freezes, that can probably be dropped to near zero by branching when the first RC happens. modules would need to be ready for such a branching event (easy enough with topic branches), and then merges of topic branches into master would be frozen for whatever period the release team feels they need to work out that they don’t need to re-branch from master. this time period might even be zero with a topic branch based workflow. translations .. this will require some time spent with the translation maintainers to figure out what will work well for those efforts. artwork should probably just be another topic branch where it is significantly modified. > Rather than aim for some arbitrary cycle length when you are discussing it, > I think that it would be useful to look ways to reduce the time from FF to > release without reducing code quality at release time. Once there's a the goal is even to improve code quality in general, though, i agree that the shorter dev cycles only really makes sense when paired with an appropriate workflow. -- Aaron J. Seigo
signature.asc
Description: This is a digitally signed message part.