On Oct 31, 2012, at 16:23 , Paul Davis <[email protected]> wrote:
> On Wed, Oct 31, 2012 at 11:18 AM, Adam Kocoloski <[email protected]> wrote: >> 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 > > I think the intention there is if you have a sufficiently large test > suite that accurately represents reality. Thus when you're landing > features in quick succession you have a place to test the combination > before they "go live". I'm not sure we really have that (also > considering that we run our test suite locally and don't rely on a > central CI server). Good summary! I think we want to be working towards that, but yeah, we are not really there yet, and we don't have many concurrent features and fixes going on. But again, I am happy to reconsider this, when we run into issues with the current setup. Cheers Jan -- > >> >> 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 >>>>> >>> >>
