Proposal for Moose branch layout

gistfile1.txt

New branching layout for Moose/Class-MOP

main branches:

master
stable
branches
topics

people:

authors - people creating a branch
comitters - people reviewing and merging a branch
cabal - people who can release moose


stable (refs/heads/stable) = the branch that releases are made off when making
a new release you merge from master to stable. Only updated by cabal during a
release process.

master (refs/heads/master) = the branch new development is merged into and
branched from

branches (refs/heads/*) = large community branches for big development.
"projects"

topics (refs/heads/topics/*) = small/personal branches that have been published
for review, but can get freely rebased. Targetted features that may span a
handful of commits.


Release workflow:

    git checkout master
    # edit for final version bumping, changelogging, etc
    # prepare release (test suite etc)
    commit
    git checkout stable
    git merge master # must be a fast forward
    git push both
    # ship & tag


Bug/Feature workflow:

    # update your copy of master
    git checkout master
    git pull --rebase

    # create a new topic branch
    git checkout -b topic/my_feature

    # hack, commit, feel free to break fast forward
    commit --amend                       # allowed
    git rebase --interactive             # allowed
    push --force origin topic/my_feature # allowed

Then go on IRC, ask for someone to review and merge to master. If it merges
cleanly and nobody has any objections then it can be pushed to master.

If it doesn't merge as a fast forward the author needs to run

    git rebase origin/master

or

    git merge origin/master

and make sure it will merge as a fast forward.

No actual merging (as in a human resolving conflicts) should be done when
merging into master, only from master.





Emergency bug workflow (for immediate release):

    git checkout stable
    git pull --rebase
    git checkout -b topic/my_emergency_fix
    hack
    commit

Then a cabal member merges into stable:

    git checkout stable
    git merge topic/my_emergency_fix
    git push
    # release
    git checkout master
    git merge stable


Project workflow:

for longer lasting branches we use a subversion style branch layout, where
master is routinely merged into the branch. Rebasing is probably not a good
idea if there are multiple contributers on such branches.

Committing is still done with the same review process as a topic branch, and
the branch must merge as a fast forward.

This is pretty much the way we're doing branches for largeish things right now.




Copying the 'pu' branch idea:

To make things easier for longer lived branches (whether topics or projects),
the 'pu' branch is basically what happens if you merge all of the branches and
topics together into master, as long as they merge cleanly. We can update this
as necessary (e.g. on a weekly basis if there is merit), telling the authors of
the respective branches if their branches did not merge (and why), and running
the test suite.

To update 'pu':

	git checkout pu
	git reset --hard origin/master
	git merge @all_the_branches

If the merge is clean, 'pu' is updated with push --force.

If the merge is not clean, the offending branch is removed from
@all_the_branches, with a small note of the conflict, and we try again.

The authors of the failed branches should be told to try and merge their branch
into 'pu', to see how their branch interacts with other branches.

'pu' is probably broken most of the time, but lets us know how the different
branches interact



Branch archival:

merged branches can be deleted

failed branches may be kept, but consider moving to refs/attic/ (e.g. http://danns.co.uk/node/295) to keep git branch -l current.

Any branch that could still realistically be merged in the future, even if it hasn't had work recently should not be archived.