You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Benoit Chesneau <bc...@gmail.com> on 2012/10/31 09:07:13 UTC
branching in couchdb
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
Re: branching in couchdb
Posted by Noah Slater <ns...@apache.org>.
Oh, and just a note to say that I don't really care as long as whatever we
pick ties in to the branching process that we fleshed out in Dublin. After
this release I want us to be very strict about how changes land on release
branches. But beyond that, I don't actually know enough about Git to offer
any useful comments. For instance, I don't really understand how master
will be used once we switch to these formal release branches. Perhaps
someone can enlighten me?
On 1 November 2012 11:35, Jan Lehnardt <ja...@apache.org> wrote:
>
> On Nov 1, 2012, at 07:15 , Benoit Chesneau <bc...@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 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 <ja...@apache.org> wrote:
> >
> >>
> >> On Oct 31, 2012, at 16:39 , Benoit Chesneau <bc...@gmail.com>
> wrote:
> >>
> >>> On Wed, Oct 31, 2012 at 4:27 PM, Jan Lehnardt <ja...@apache.org> wrote:
> >>>
> >>>>
> >>>> On Oct 31, 2012, at 16:23 , Paul Davis <pa...@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 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
> >> --
> >>
> >>
> >>
> >>
> >>
>
>
--
NS
Re: branching in couchdb
Posted by Adam Kocoloski <ko...@apache.org>.
On Nov 1, 2012, at 11:29 PM, Eli Stevens (Gmail) <wi...@gmail.com> wrote:
> On Thu, Nov 1, 2012 at 9:28 PM, Adam Kocoloski <ko...@apache.org> wrote:
>> Hi Eli, Benoit linked to a variant of it in the beginning of this thread. There's a lot to like about it, and most of it is very similar to the workflow we're converging on in this project. The big difference is that in git-flow the HEAD of "master" is always the latest tagged release, and that "develop" is where the day-to-day completed work lands.
>
> I didn't realize it was a direct variant; the lack of an explicit
> release branch seemed like a significant change in process (perhaps
> appropriate for the poster's use case, but doesn't seem to fit what
> I've seen of CouchDB).
Agreed, I think the original git-flow is a better match for packaged software development.
> Note that at my work we easily changed the
> git-flow "branch 'master' is last stable release" and "branch
> 'development' is integration for next release" defaults to be 'stable'
> and 'master' respectively.
Good to know.
>> Personally I don't think I would coerce CouchDB into the nominal git-flow shape, but I thought I'd note the similarities in case others find the tooling really appealing. Cheers,
>
> As an outsider, aside from naming convention, it's not clear what the
> mismatch is; care to expand? Of course, if this is getting off-topic,
> feel free to let this part of the thread die. :)
So, actually, I forgot one huge detail, which is that our git setup disallows merge commits on master! I was only reminded of it after the X-Couch-Id Pull Request was accepted earlier today. So I guess our conditions for branching and our naming of those branches are reasonably similar to git-flow, but the fact that those branches are rebased/squashed/cherry-picked/deleted instead of merged means we actually have a completely different workflow after all ;) Cheers,
Adam
Re: branching in couchdb
Posted by "Eli Stevens (Gmail)" <wi...@gmail.com>.
On Thu, Nov 1, 2012 at 9:28 PM, Adam Kocoloski <ko...@apache.org> wrote:
> Hi Eli, Benoit linked to a variant of it in the beginning of this thread. There's a lot to like about it, and most of it is very similar to the workflow we're converging on in this project. The big difference is that in git-flow the HEAD of "master" is always the latest tagged release, and that "develop" is where the day-to-day completed work lands.
I didn't realize it was a direct variant; the lack of an explicit
release branch seemed like a significant change in process (perhaps
appropriate for the poster's use case, but doesn't seem to fit what
I've seen of CouchDB). Note that at my work we easily changed the
git-flow "branch 'master' is last stable release" and "branch
'development' is integration for next release" defaults to be 'stable'
and 'master' respectively.
> Personally I don't think I would coerce CouchDB into the nominal git-flow shape, but I thought I'd note the similarities in case others find the tooling really appealing. Cheers,
As an outsider, aside from naming convention, it's not clear what the
mismatch is; care to expand? Of course, if this is getting off-topic,
feel free to let this part of the thread die. :)
Cheers,
Eli
Re: branching in couchdb
Posted by Adam Kocoloski <ko...@apache.org>.
Hi Eli, Benoit linked to a variant of it in the beginning of this thread. There's a lot to like about it, and most of it is very similar to the workflow we're converging on in this project. The big difference is that in git-flow the HEAD of "master" is always the latest tagged release, and that "develop" is where the day-to-day completed work lands.
Personally I don't think I would coerce CouchDB into the nominal git-flow shape, but I thought I'd note the similarities in case others find the tooling really appealing. Cheers,
Adam
On Nov 1, 2012, at 8:54 PM, "Eli Stevens (Gmail)" <wi...@gmail.com> wrote:
> Are the committers familiar with git-flow?
>
> http://nvie.com/posts/a-successful-git-branching-model/
> https://github.com/nvie/gitflow
>
> Having used it at work for closed-source projects, I recommend it as
> the script support is nice, and it provides a decent branching model
> that "just works." While we don't use github's automatic merges, it
> does play nicely with the github pull request system (perhaps less
> relevant for an apache project).
>
> I don't see any reason why it wouldn't work just as well for open
> source projects.
>
> Cheers,
> Eli
Re: branching in couchdb
Posted by "Eli Stevens (Gmail)" <wi...@gmail.com>.
Are the committers familiar with git-flow?
http://nvie.com/posts/a-successful-git-branching-model/
https://github.com/nvie/gitflow
Having used it at work for closed-source projects, I recommend it as
the script support is nice, and it provides a decent branching model
that "just works." While we don't use github's automatic merges, it
does play nicely with the github pull request system (perhaps less
relevant for an apache project).
I don't see any reason why it wouldn't work just as well for open
source projects.
Cheers,
Eli
Re: branching in couchdb
Posted by Randall Leeds <ra...@gmail.com>.
On Thu, Nov 1, 2012 at 4:46 AM, Robert Newson <rn...@apache.org> wrote:
> As long as it has the jira ticket number and a short description, I don't
> see any useful distinction between any of the proposals, you can take this
> as a vote for any of them in the event of a tie. I would like to *not*
> include the COUCHDB- prefix, it's redundant.
>
+1
Re: branching in couchdb
Posted by Robert Newson <rn...@apache.org>.
As long as it has the jira ticket number and a short description, I don't
see any useful distinction between any of the proposals, you can take this
as a vote for any of them in the event of a tie. I would like to *not*
include the COUCHDB- prefix, it's redundant.
On 1 November 2012 11:35, Jan Lehnardt <ja...@apache.org> wrote:
>
> On Nov 1, 2012, at 07:15 , Benoit Chesneau <bc...@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 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 <ja...@apache.org> wrote:
> >
> >>
> >> On Oct 31, 2012, at 16:39 , Benoit Chesneau <bc...@gmail.com>
> wrote:
> >>
> >>> On Wed, Oct 31, 2012 at 4:27 PM, Jan Lehnardt <ja...@apache.org> wrote:
> >>>
> >>>>
> >>>> On Oct 31, 2012, at 16:23 , Paul Davis <pa...@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 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
> >> --
> >>
> >>
> >>
> >>
> >>
>
>
Re: branching in couchdb
Posted by Benoit Chesneau <bc...@gmail.com>.
i don't want to have to always have to use a tool to just sort branches by
topic. I'm fine to have topic branches associated to their jira naming.
Sounds like a good idea.
- benoît
On Sat, Nov 3, 2012 at 5:45 PM, Robert Newson <ro...@gmail.com>wrote:
> I'd say the policy on branch deletions is "don't" but others might
> disagree. git branch --no-merged is useful.
>
> Sent from the ocean floor
>
> On 3 Nov 2012, at 16:38, Benoit Chesneau <bc...@gmail.com> wrote:
>
> > On Sat, Nov 3, 2012 at 5:24 PM, Robert Newson <robert.newson@gmail.com
> >wrote:
> >
> >> Or just leave it out entirely like we said at the start of all this.
> > so at then end we will have XXXXXXXXXXX branches. Or rather what is the
> > policy to delete branches?
> >
> > - benoit
>
Re: branching in couchdb
Posted by Robert Newson <ro...@gmail.com>.
I'd say the policy on branch deletions is "don't" but others might
disagree. git branch --no-merged is useful.
Sent from the ocean floor
On 3 Nov 2012, at 16:38, Benoit Chesneau <bc...@gmail.com> wrote:
> On Sat, Nov 3, 2012 at 5:24 PM, Robert Newson <ro...@gmail.com>wrote:
>
>> Or just leave it out entirely like we said at the start of all this.
> so at then end we will have XXXXXXXXXXX branches. Or rather what is the
> policy to delete branches?
>
> - benoit
Re: branching in couchdb
Posted by Benoit Chesneau <bc...@gmail.com>.
On Sat, Nov 3, 2012 at 5:24 PM, Robert Newson <ro...@gmail.com>wrote:
> Or just leave it out entirely like we said at the start of all this.
>
>
so at then end we will have XXXXXXXXXXX branches. Or rather what is the
policy to delete branches?
- benoit
Re: branching in couchdb
Posted by Robert Newson <ro...@gmail.com>.
Or just leave it out entirely like we said at the start of all this.
Sent from the ocean floor
On 3 Nov 2012, at 16:16, Noah Slater <ns...@apache.org> wrote:
> 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 <ja...@apache.org> wrote:
>
>>
>> On Nov 1, 2012, at 07:15 , Benoit Chesneau <bc...@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 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 <ja...@apache.org> wrote:
>>>
>>>>
>>>> On Oct 31, 2012, at 16:39 , Benoit Chesneau <bc...@gmail.com>
>> wrote:
>>>>
>>>>> On Wed, Oct 31, 2012 at 4:27 PM, Jan Lehnardt <ja...@apache.org> wrote:
>>>>>
>>>>>>
>>>>>> On Oct 31, 2012, at 16:23 , Paul Davis <pa...@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 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
>>>> --
>
>
> --
> NS
Re: branching in couchdb
Posted by Noah Slater <ns...@apache.org>.
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 <ja...@apache.org> wrote:
>
> On Nov 1, 2012, at 07:15 , Benoit Chesneau <bc...@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 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 <ja...@apache.org> wrote:
> >
> >>
> >> On Oct 31, 2012, at 16:39 , Benoit Chesneau <bc...@gmail.com>
> wrote:
> >>
> >>> On Wed, Oct 31, 2012 at 4:27 PM, Jan Lehnardt <ja...@apache.org> wrote:
> >>>
> >>>>
> >>>> On Oct 31, 2012, at 16:23 , Paul Davis <pa...@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 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
> >> --
> >>
> >>
> >>
> >>
> >>
>
>
--
NS
Re: branching in couchdb
Posted by Jan Lehnardt <ja...@apache.org>.
On Nov 1, 2012, at 07:15 , Benoit Chesneau <bc...@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 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 <ja...@apache.org> wrote:
>
>>
>> On Oct 31, 2012, at 16:39 , Benoit Chesneau <bc...@gmail.com> wrote:
>>
>>> On Wed, Oct 31, 2012 at 4:27 PM, Jan Lehnardt <ja...@apache.org> wrote:
>>>
>>>>
>>>> On Oct 31, 2012, at 16:23 , Paul Davis <pa...@gmail.com>
>>>> wrote:
>>>>
>>>>> On Wed, Oct 31, 2012 at 11:18 AM, Adam Kocoloski <ko...@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 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
>> --
>>
>>
>>
>>
>>
Re: branching in couchdb
Posted by Benoit Chesneau <bc...@gmail.com>.
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.
- benoit
On Wed, Oct 31, 2012 at 4:41 PM, Jan Lehnardt <ja...@apache.org> wrote:
>
> On Oct 31, 2012, at 16:39 , Benoit Chesneau <bc...@gmail.com> wrote:
>
> > On Wed, Oct 31, 2012 at 4:27 PM, Jan Lehnardt <ja...@apache.org> wrote:
> >
> >>
> >> On Oct 31, 2012, at 16:23 , Paul Davis <pa...@gmail.com>
> >> wrote:
> >>
> >>> On Wed, Oct 31, 2012 at 11:18 AM, Adam Kocoloski <ko...@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 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
> --
>
>
>
>
>
Re: branching in couchdb
Posted by Jan Lehnardt <ja...@apache.org>.
On Oct 31, 2012, at 16:39 , Benoit Chesneau <bc...@gmail.com> wrote:
> On Wed, Oct 31, 2012 at 4:27 PM, Jan Lehnardt <ja...@apache.org> wrote:
>
>>
>> On Oct 31, 2012, at 16:23 , Paul Davis <pa...@gmail.com>
>> wrote:
>>
>>> On Wed, Oct 31, 2012 at 11:18 AM, Adam Kocoloski <ko...@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 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
--
Re: branching in couchdb
Posted by Benoit Chesneau <bc...@gmail.com>.
On Wed, Oct 31, 2012 at 4:27 PM, Jan Lehnardt <ja...@apache.org> wrote:
>
> On Oct 31, 2012, at 16:23 , Paul Davis <pa...@gmail.com>
> wrote:
>
> > On Wed, Oct 31, 2012 at 11:18 AM, Adam Kocoloski <ko...@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 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.
Anyway if we stay with the current situation yes having one referent doc
would be good.
- benoit
Re: branching in couchdb
Posted by Jan Lehnardt <ja...@apache.org>.
On Oct 31, 2012, at 16:23 , Paul Davis <pa...@gmail.com> wrote:
> On Wed, Oct 31, 2012 at 11:18 AM, Adam Kocoloski <ko...@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 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 <ja...@apache.org> wrote:
>>
>>>
>>> On Oct 31, 2012, at 13:21 , Robert Newson <ro...@gmail.com> 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 <dc...@jsonified.com> wrote:
>>>>
>>>>> On 31 October 2012 09:07, Benoit Chesneau <bc...@gmail.com> 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
>>>>>
>>>
>>
Re: branching in couchdb
Posted by Paul Davis <pa...@gmail.com>.
On Wed, Oct 31, 2012 at 11:18 AM, Adam Kocoloski <ko...@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 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).
>
> On Oct 31, 2012, at 10:40 AM, Jan Lehnardt <ja...@apache.org> wrote:
>
>>
>> On Oct 31, 2012, at 13:21 , Robert Newson <ro...@gmail.com> 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 <dc...@jsonified.com> wrote:
>>>
>>>> On 31 October 2012 09:07, Benoit Chesneau <bc...@gmail.com> 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
>>>>
>>
>
Re: branching in couchdb
Posted by Adam Kocoloski <ko...@apache.org>.
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 <ja...@apache.org> wrote:
>
> On Oct 31, 2012, at 13:21 , Robert Newson <ro...@gmail.com> 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 <dc...@jsonified.com> wrote:
>>
>>> On 31 October 2012 09:07, Benoit Chesneau <bc...@gmail.com> 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
>>>
>
Re: branching in couchdb
Posted by Jan Lehnardt <ja...@apache.org>.
On Oct 31, 2012, at 13:21 , Robert Newson <ro...@gmail.com> 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 <dc...@jsonified.com> wrote:
>
>> On 31 October 2012 09:07, Benoit Chesneau <bc...@gmail.com> 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
>>
Re: branching in couchdb
Posted by Robert Newson <ro...@gmail.com>.
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.
On 31 October 2012 09:16, Dave Cottlehuber <dc...@jsonified.com> wrote:
> On 31 October 2012 09:07, Benoit Chesneau <bc...@gmail.com> 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
>
Re: branching in couchdb
Posted by Dave Cottlehuber <dc...@jsonified.com>.
On 31 October 2012 09:07, Benoit Chesneau <bc...@gmail.com> 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