Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
MIME-Version: 1.0
In-Reply-To: <CB03EB15-811F-4804-94E1-53F485414D55@apache.org>
References: 
 <CAJNb-9p9YxLT82vE01Gj7nO2+HLRCNveU3tP0MvXQs9KpJuA8w@mail.gmail.com>
	<CAL+Y1nuVEZE+o8mh2hoiDZ1xqYm1QOYxToYwmZkuu2AwZNKnwg@mail.gmail.com>
	<CABvT1DGCh9JYYEhTp6AnLNRcVe6mtBcV3=rLYndo8p+m3b57fg@mail.gmail.com>
	<DEC04DB0-172C-4517-8554-2BE049A2F606@apache.org>
	<7D76050A-3095-46A3-81EA-2DB30E78E263@apache.org>
	<CAJ_m3YC3Uyt5bZodgtTPViB099XE9bM9TXwk2UuDCXGuB4pF7w@mail.gmail.com>
	<87B791B0-2812-41FB-A91B-E005EB785D9B@apache.org>
	<CAJNb-9pHGcDRdxWZQREgTA-SOHDfC2nUq74t-rnBHUDOMfb=ZA@mail.gmail.com>
	<B8D20B04-5785-4E1B-81B2-6D1A77CF3F3B@apache.org>
	<CAJNb-9opo0ys7AsHCKrpxqPtiLtmaigm5LFqhwEvbibZnSv3Kw@mail.gmail.com>
	<CB03EB15-811F-4804-94E1-53F485414D55@apache.org>
Date: Sat, 3 Nov 2012 16:15:51 +0000
Message-ID: 
 <CAPaJBx6jhrrXBee5rck1xEqt_Z9gF1oFF5pUqhjkNDjdGMdtmA@mail.gmail.com>
Subject: Re: branching in couchdb
From: Noah Slater <nslater@apache.org>
To: dev@couchdb.apache.org
Content-Type: multipart/alternative; boundary=047d7b33d48ee8aed004cd999053

--047d7b33d48ee8aed004cd999053
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

I think the "fix/feature" thing in the branch name is a little odd. Is
there any real need for that? We're going to struggle with branch name
lengths anyway, trying to cram a useful summary of the JIRA title, etc. If
we really DO want it, I would suggest we mirror the categories in JIRA. We
have "Bug", "Improvement" and "Feature" from what I can figure. I don't
think any other ticket types would result in Git commits.

On 1 November 2012 11:35, Jan Lehnardt <jan@apache.org> wrote:

>
> On Nov 1, 2012, at 07:15 , Benoit Chesneau <bchesneau@gmail.com> 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 hurrie=
d.
>
> * * *
>
> I don=92t 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]-summar=
y
> because that=92s how I understood the proposal, but then I could have bee=
n
> wrong. Sorry about that. Now is the time to fix this.
>
> I=92m 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=92ll make a call after 72
> hours based on the responses (note that this isn=92t a vote, I=92ll just
> make an informed decision for the group). I=92ll 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 <jan@apache.org> wrote:
> >
> >>
> >> On Oct 31, 2012, at 16:39 , Benoit Chesneau <bchesneau@gmail.com>
> wrote:
> >>
> >>> On Wed, Oct 31, 2012 at 4:27 PM, Jan Lehnardt <jan@apache.org> wrote:
> >>>
> >>>>
> >>>> On Oct 31, 2012, at 16:23 , Paul Davis <paul.joseph.davis@gmail.com>
> >>>> wrote:
> >>>>
> >>>>> On Wed, Oct 31, 2012 at 11:18 AM, Adam Kocoloski <
> kocolosk@apache.org>
> >>>> 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 tes=
t
> >>>>> suite that accurately represents reality. Thus when you're landing
> >>>>> features in quick succession you have a place to test the combinati=
on
> >>>>> 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
> >> --
> >>
> >>
> >>
> >>
> >>
>
>


--=20
NS

--047d7b33d48ee8aed004cd999053--