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/11/01 07:15:21 UTC
Re: branching in couchdb
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 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 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 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
>> --
>>
>>
>>
>>
>>