On Nov 1, 2012, at 07:15 , Benoit Chesneau wrote: > So I didn't realize we settled on Ticket-{feature,fix}_coolname here (hence > my git spam this morning) . Imo this naming is awkward and miss the initial > goal. ie make it easy to parse even for humans. > > Today this isn't a problem we have not so many branch. But in near future I > expect more activity on the repo and it will become important. It will be > hard to rename it after than deciding today on a good naming. Imo we should > really think a little more on that. Beeing relaxed is fine, but to be > honest I am generally more relax when I know that things in the future > won't be a problem. No worries Benoit, this is all very new and in flux. Thanks Adam for looking after consistency with our processes. I realise this was all a bit hurried. * * * I don’t much care for whether we do [fix|feature]/jiranumber-summary or jiranumber-[fix|feature]-summary or just jiranumber-summary or whatever else (that is sensible) as long as we stick to one of them. I went with the lazy consensus version of jiranumber-[fix/feature]-summary because that’s how I understood the proposal, but then I could have been wrong. Sorry about that. Now is the time to fix this. I’m happy to change this to [fix|feature]/jiranumber-summary or [fix|feature]/jiranumber_summary, or an entirely new (sensible) formats now. Please cast your bikeshedding opinions. I’ll make a call after 72 hours based on the responses (note that this isn’t a vote, I’ll just make an informed decision for the group). I’ll update this thread AND make a formal announcement of the branch naming scheme. Thanks for all your patience! Jan -- > > > - benoit > > > On Wed, Oct 31, 2012 at 4:41 PM, Jan Lehnardt wrote: > >> >> On Oct 31, 2012, at 16:39 , Benoit Chesneau wrote: >> >>> On Wed, Oct 31, 2012 at 4:27 PM, Jan Lehnardt wrote: >>> >>>> >>>> On Oct 31, 2012, at 16:23 , Paul Davis >>>> wrote: >>>> >>>>> On Wed, Oct 31, 2012 at 11:18 AM, Adam Kocoloski >>>> 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 >>>> -- >>>> >>>> I'm not sure it will help when we will have n branches. Also I think we >>> should have more test and c-i. The current situation is not that good and >>> we spoke about it at the boston summit. >> >> Fully agreed! >> >>> Anyway if we stay with the current situation yes having one referent doc >>> would be good. >> >> I updated http://wiki.apache.org/couchdb/Merge_Procedure. >> >> Cheers >> Jan >> -- >> >> >> >> >>