To a first approximation, I like Bob Newson's idea (option 1 in the OP). It seems the most workable for a large distributed team of volunteers.
I am probably a bad teammate, but I always find myself forgetting or misunderstanding policies and changes to policies. So I like the simplest, most intuitive rules that work, e.g. "Features in a branch, merge to master when you're done. Cherry pick backports." On Fri, May 24, 2013 at 6:51 PM, Benoit Chesneau <bchesn...@gmail.com> wrote: > On Fri, May 24, 2013 at 6:32 PM, Noah Slater <nsla...@apache.org> wrote: >> Activity from elsewhere: >> >> http://markmail.org/message/5pxv3ni6qvc2k2jo >> >> http://markmail.org/message/czkylvo2wvbrrikj >> >> http://markmail.org/message/2ybvoo2yjwxmfwze >> >> http://markmail.org/message/ohjwjh6ri72yuagh >> >> http://markmail.org/message/v767rozacnwowlpg >> >> http://markmail.org/message/ftbd5qbv33iq7uxu >> >> Hopefully we can continue the discussion here and resolve this soon. I'm >> hoping the people with the strongest opinions here (lookin at you Bob, >> Randal, and Dirkjan) feel empowered to JFDI. If you don't, ... JFDI. ;) >> > > More useful than these links hat is your summary about this activity? > There are a lot of different issues in them as I see it and not all > related to the workflow. > > To add my 2 cents I would go to something like git workflow: > > master : always stable, these contains all the patch coming from > features and fix/branch. Always rebase on master > develop : branch that contain patches from features and fixed before > they can be applied to the master. Here mainly for CI . merge and > force are accepted on develo. force is accepted so we can clean it for > test > > fix/... for fixes > features/... for features > > release/X.X supported branches > > tags for releases. > > > - benoit -- Iris Couch
