couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <bchesn...@gmail.com>
Subject Re: git commit: handle CORS. fix #COUCHDB-431
Date Thu, 01 Nov 2012 06:03:41 GMT
doh forget the last part. coffee is needed :)


On Thu, Nov 1, 2012 at 7:02 AM, Benoit Chesneau <bchesneau@gmail.com> wrote:

>
>
>
> On Thu, Nov 1, 2012 at 6:52 AM, Adam Kocoloski <kocolosk@apache.org>wrote:
>
>> On Nov 1, 2012, at 1:41 AM, Benoit Chesneau <bchesneau@gmail.com> wrote:
>>
>> > ok I will stop for now pushed 431_feature_cors (the removing of caps is
>> > wanted here and I will be happy to just update the jira title if someone
>> > really care) .
>>
>> Sure, I only used caps because CORS is an acronym.  It doesn't matter at
>> all.  Is there a reason why you keep using underscores instead of hyphens?
>>
>> > Side note: Imo adding feature in the naming here doesn't give anything
>>  .
>> > Prefixing by feature/ at least would optimize queries for rapid eye
>> looking
>> > or a bot going over the issues...
>>
>> Probably best to bring that up as an objection to Jan's proposal in the
>> "branching in couchdb" thread.  Personally I prefer the 431-feature-cors
>> style from that proposal.
>>
>
> I'm doing it now. The point of using feature/ and fix/ is to help later
> when we will all works actively on different features/ fixes/ and the
> number of branch will be larger. Using XXX-feature_... will not help at all
> in this case. I know this isn't a problem today but I prefer having a
> strict naming like this at first rather than trying to change things later.
> Especially since this is a known problem.
>
>
>
>> I realize I'm being incredibly pedantic, but it just rubbed me the wrong
>> way that we collectively wrote 9 emails on the topic branch naming today,
>> got what appeared to be lazy consensus on a convention, and then almost
>> immediately ignored that convention.  Regards,
>>
>
> That wasn't intended. I may have missed that we reached a consensus on a
> new naming. For hyphen and such well... I will fix it again, though i think
> using - helps to separate meanings when _ is normally used to extend a
> meaning of the same info (here ticket number vs short description) .
>
> - benoƮt
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message