This topic has been brought up before but we never really came to a consensus on how we want to organize our branches in the official git repository. Yet I want to get a final decision on this before we open a master for feature development again.
To refresh memory here is a link to the thread on gnucash-devel last year January about this topic: http://lists.gnucash.org/pipermail/gnucash-devel/2013-January/034843.html The model I defended in that thread is more or less this (quoted from http://lists.gnucash.org/pipermail/gnucash-devel/2013-February/034878.html ) - one branch for future development (features, refactoring, anything too complex for a stable release) - there can be subbranches for separate features or refactoring efforts that get merged into the main development branch when they are considered ready - one branch for stable development (bugfixes, translation updates). This branch gets merged into development regularly to get all bugfixes into the future development as well - one release branch. The only direct commits here are those purely related to releasing, like updating the version number. Other than that it receives bugfixes and translation updates merged in from the stable branch. This setup leverages the git history to keep track of which changes go where. It solves the problem of forgotten backports (there no longer are any) and makes sure that all bugfixes eventually end up in all branches that should carry them. This obsoletes our current BP/AUDIT machinery which was adopted because svn history was not capable of managing this on its own. At some point we had some kind of a gatekeeper to tell which bugfixes were allowed on stable and which aren't. This person tracked the AUDIT mails to know which commits to verify. If we want to re-establish this function in the future I think the easiest way would be as follows: - only the gatekeeper can push to the central stable branch. - bugfixes are done on their local stable branches and they send pull requests (or patches) for review to the gatekeeper - the gatekeeper evaluates the pull requests/patches and accepts or rejects. Using pull requests once more leverages one of the powers of git. Since that long-winded thread I have found some workflows as recommended by other projects managed in git. I have collected some links to such workflows in our wiki [1]. Reading those you will find they all more or less start on a similar basis. I find it rather amusing we got to such a similar result by independently thinking about this. Some workflows add more branches in the mix, like an integration branch. We may want to discuss if those extra's make sense in the small team we currently are. Please give your feedback on whether or not we want to adopt such a workflow. If so we really need to review the Backporting stuff on our Git wiki page. Geert [1] http://wiki.gnucash.org/wiki/Git#Branching_and_Merging _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
