No objection from me, Jan. I don't see the need for a dedicated "develop" branch at the moment, but then I've not worked intensively on a project which had one.
Adam On Oct 31, 2012, at 10:40 AM, Jan Lehnardt <[email protected]> wrote: > > On Oct 31, 2012, at 13:21 , Robert Newson <[email protected]> wrote: > >> For my part, I was pretty content with the scheme we agreed to in Dublin >> (<jira>-<shortdesc>). >> >> I would like to discuss the old branches that don't follow any scheme at >> all, is it time we deleted those? >> >> For going forward, I think every jira-shortdesc branch lives forever. 'git >> branch --no-merged master' will show all the branches we haven't merged in, >> and I advocate that as our mechanism for figuring out which branches are >> dead, rather than removing the sometimes-useful history of a ticket. > > That sounds sane to me. > > It seems to me the the enhanced branching model tries to do two things: > > 1. Allow fast and lose merging of a bigger number of feature branches > to make fast deployment and CI easier and non-blocking. > 2. Establish a naming convention for branches of different types > (hotfix, feature etc.) > > Please correct me if I am missing something. > > For the moment I don't see that we have too many concurrent feature > branches in CouchDB. So for the time being, I think we are okay with > treating the release branches as the “develop” branches. > > I think it will become obvious when that is going to be no longer > sufficient and I would totally support starting to use the develop- > branch method as soon as we hit any issues with the currently > described setup. > > > As for 2. we tag our branch names with the JIRA number which gives > us the branch-type as well. So technically the information is one > lookup away, but I wouldn’t mind changing our branches to > jiranumber-feature-name-of-the-feature > > E.g. 431-feature-cors, or 1500-bugfix-ibrowse-inbox-overflow > > * * * > > > If nobody objects*, I'd sum this up two action items: > > 1. update our wiki to name branches jiranumber-feature-name > instead of just jiranumber-name. (Jan) > > 2. observe our branch/merge procedure closely to see whether > we should have a dedicated “develop”-branch. If we do, > switch to that model. (All) > > Cheers > Jan > -- > * as per ASF Lazy Consensus. > (http://www.apache.org/foundation/glossary.html#LazyConsensus) > > >> >> >> On 31 October 2012 09:16, Dave Cottlehuber <[email protected]> wrote: >> >>> On 31 October 2012 09:07, Benoit Chesneau <[email protected]> wrote: >>>> Hello guys, >>>> >>>> II would like to discuss a little about our branch naming. Today we have >>>> conflicting docs somehow: >>>> >>>> - >>> http://wiki.apache.org/couchdb/Source%20Code%20Repository%20Organization >>>> >>>> - http://wiki.apache.org/couchdb/ContributorWorkflow >>>> >>>> and one another I don't find on the wiki now (without my bookmarks) >>>> >>>> >>>> Maybe we can make a one page describing the branching workflow and such ? >>>> >>>> Also my understanding now is that branch should be named by >>>> <TicketNumber>_<shortdescr> >>>> >>>> which sound good. >>>> >>>> I would like to introduce another level to help us when we have to look >>> on >>>> different branches. This is mainly based on that doc : >>>> >>>> >>> http://nxvl.blogspot.fr/2012/07/a-continous-delivery-git-branching-model.html >>>> >>>> and it could help for continuous integration when we will have it. >>>> >>>> In short : >>>> >>>> - a develop branch where all patches should land before to go in master. >>>> This branch can be used for final review and make sure it doesn't break >>>> anything else. >>>> >>>> - a `fix/<TicketNumber>_<shortdescr>` for changes fixing a bug >>>> - a `feature/<TicketNumber>_<shortdescr>` for new features >>>> - usual X.X.x branch for releases (those we could name them /release/X.X. >>>> >>>> Thoughts? >>>> >>>> - benoît >>> >>> +1 >>> >>> >>> http://4.bp.blogspot.com/-t4yLz-et74A/UBIES98QPmI/AAAAAAAADGY/S5lwne9xpcM/s1600/releaseFlow.png >>> >>> seems very similar to the OTP approach as well. >>> >>> Just tell me what I need to do :-) >>> >>> A+D >>> >
