Just my two cents here - I don’t want to reheat the debate - but I find it confusing just for one reason, terminology : the 2.2-staging branch is, at least for me, the develop branch (where all new commits should happen), and then the different branches (master = 2.1, 2.1.1-staging) are managed by the release manager. I would find it much more logical to have : - master as the main development branch (I know the argument about freezing, but I believe this does not hold, since anyways people can continue to develop wherever they want with git) - then releases branches (releases/2.1.0, releases/2.1.1) which are managed by the release manager that can pick commits from the develop/master (or ask the committer to commit in the release branches). Branches can be cascading (like 2.1.0 is merged into 2.1.1) or not, again this is managed by the release manager.
I know it puts (maybe) more burden on the release manager (I am not fully convinced by this though), but this could reduce the confusion. There is the case of translations which are always asynchronous since they start when coding has stopped, but this can follow a slightly different logic - working only in release branches which are then merged to the develop branch. Just one last note about the freezing/development process : - I find it very difficult to understand from the trac interface what is the current state of the project, what are the bugs that need to be fixed and what are the bugs which are already worked on by some people. - this is somehow due to trac lagging against other collaboration interfaces that make it much easier to understand what a patch is doing by allowing to visualize it, to comment directly the changes before pulling the changes. I know there had been discussions about it in the past (like switching to github if I recall well), but I don’t remember what was the outcome; I could work on switching to such a platform (there is also an open source alternative, gitlab), there are some scripts that exist on the Web for this that could be adapted. - it would be great also to have some automated build processes (and tests?) to reduce the likeliness of a bug being introduced in the repository. I could do this for the OS X platform (have to check how much work this is first). Benjamin On 26 Mar 2014 at 20:10:36 , Georg Baum ([email protected]) wrote: Pavel Sanda wrote: > No difference. But what you described above is concept different from what > I see happening in this branches; it' clear that at least part of our team > does not understand these branches that way, and some commits there belong > to to 2.1.0 to me. I think the lack of understanding is the main problem. My personal solution is simply not to commit anything until master is open again. Georg
