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 <nsla...@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 <j...@apache.org> wrote:
>
>>
>> On Nov 1, 2012, at 07:15 , Benoit Chesneau <bchesn...@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 <j...@apache.org> wrote:
>>>
>>>>
>>>> On Oct 31, 2012, at 16:39 , Benoit Chesneau <bchesn...@gmail.com>
>> wrote:
>>>>
>>>>> On Wed, Oct 31, 2012 at 4:27 PM, Jan Lehnardt <j...@apache.org> wrote:
>>>>>
>>>>>>
>>>>>> On Oct 31, 2012, at 16:23 , Paul Davis <paul.joseph.da...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> On Wed, Oct 31, 2012 at 11:18 AM, Adam Kocoloski <
>> kocol...@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
