If I may... why QA need source code branches rather than a sequential builds from the trunk (as it usually done)? Say: - build qa1 is cut - QA works on it and finds issues - issues are reported against build qa1 - dev fixes some issues and mark them appropriately - build qa2 is cut - QA verifies that all issues from qa1 marked as 'fixed in qa2' are fixed and keep going with their usual cycle.
Is there anything wrong with that model? It also eliminates the need to maintain two branches at the same time. Cos On Mon, Aug 23, 2010 at 03:19PM, Owen O'Malley wrote: > I'd like to get started testing 0.22. > > I plan to start making mini-branches for QA. These branches will be > snapshots that QA can use for testing with an expected lifetime of two > weeks each. Only bug fixes that are blocking QA will be applied to the > mini-branches and every two weeks, the base of the branch will be > moved to the head of trunk. This will allow QA to test a point in time > (possibly with required bug fixes) with requiring development to > continually maintain two branches. > > To simplify automated builds, I'll call the branch the final name of > "branch-0.22." But it will be rebased every two weeks or so. > > Are there any concerns? > > -- Owen
pgpRpEe1UmIEt.pgp
Description: PGP signature
