> > can you state clearly whats the relation between topic and branch,
A "topic" is just that what is being developed in a "topic branch". A "topic branch" is a specific type of "branch" which will be created, merged into 'experimental', then merged into 'development', then merged into 'trunk-stable' and then deleted again. Branches like 'development' and 'experimental' are sort of temporary branches which only tie up all topic branches together. Branches like 'trunk-stable' and 'branch_2_0_x' are persistent branches. > whats changes constitute new branch creation in your proposal, As I propose that: - the release manager will be the only one merging stuff into trunk-stable (the same as that current the branch release manager is the only one that determines what goes into branch and what doesn't); - the release manager only merges in topic branches, everything is a candidate for branch creation. I made some exceptions: -> po updates go into 'lyx/po', and will be merge in all together; -> scons updates go into lyx/development and will probably never make trunk-stable as I foresee scons support being dropped at some point in this cycle; -> things like typo and cosmetics might go into one lyx/cosmetics branch and merge in all together. > who is responsible for resolving merge conflicts when some changes are > not merged into trunk soon? At the moment, it is basically not possible for merge conflicts to arise. And if they do they will be easily solved. This is due to the fact that for now we still use the linear history as in svn-trunk, so if you merge all feature branches in the correct order, they will never conflict. In the future, when a new branch is created, the committer has to make sure it merges nicely into development. If this means that a certain branch depends on another branch, he can base the new branch on this other branch and indicate this relationship somehow. I don't know yet how to exactly approach this. Vincent
