You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Jan Lehnardt <ja...@apache.org> on 2012/12/04 18:55:11 UTC

branch names

Hey all,

just a heads up, the scheme for branch names we agreed on
is: 1532-feature-add-docs No underscores. Please follow
this.

The fact that the cors branch doesn’t follow this is a
historic artefact that I thought wasn’t worth cleaning
up, but it looks I was wrong.

From now on, I will rule with an iron fist about getting
these details right. Current branches with diverging names
are exempt.

Cheers
Jan
-- 


Re: branch names

Posted by "matt j. sorenson" <ma...@sorensonbros.net>.
fwiw, I switched my company's team to using slashes a couple weeks ago, and
it's been a very positive change, e.g.

  issue/<issue#>/topic-or-bug

Makes the nature of the branch unmistakeable, and as a bonus, GUI clients
like sourcetree fold them up like a folder hierarchy.

Re: branch names

Posted by Jan Lehnardt <ja...@apache.org>.
On Dec 4, 2012, at 19:44 , Benoit Chesneau <bc...@gmail.com> wrote:

> On Tue, Dec 4, 2012 at 7:33 PM, Jan Lehnardt <ja...@apache.org> wrote:
> 
>> 
>> On Dec 4, 2012, at 19:19 , Benoit Chesneau <bc...@gmail.com> wrote:
>> 
>>> On Tue, Dec 4, 2012 at 6:55 PM, Jan Lehnardt <ja...@apache.org> wrote:
>>> 
>>>> Hey all,
>>>> 
>>>> just a heads up, the scheme for branch names we agreed on
>>>> is: 1532-feature-add-docs No underscores. Please follow
>>>> this.
>>>> 
>>>> The fact that the cors branch doesn’t follow this is a
>>>> historic artefact that I thought wasn’t worth cleaning
>>>> up, but it looks I was wrong.
>>>> 
>>>> From now on, I will rule with an iron fist about getting
>>>> these details right. Current branches with diverging names
>>>> are exempt.
>>>> 
>>>> Cheers
>>>> Jan
>>>> --
>>>> 
>>> 
>>> Actually we were agree to discuss that later a little more.
>> 
>> Nope, we made a decision:
>> 
>> 
>> http://mail-archives.apache.org/mod_mbox/couchdb-dev/201210.mbox/%3cDEC04DB0-172C-4517-8554-2BE049A2F606@apache.org%3e
>> 
>> 
> I only said:
> 
> "Anyway if we stay with the current situation yes having one referent doc
> would be good."
> 
> wasn't considering it so strict neither as a decision. Anyway if most
> think it should be done like this then go.

I am operating under “lazy consensus” here. I made a proposal, some people
weighed in, there were no objections, the issue is resolved. Case closed,
moving on. We have software to ship.

If you want to discuss the finer points of hyphen/underscore branch names,
be my guest, but don’t expect me to spend energy on this that could go
into shipping 1.3.0.

Cheers
Jan
-- 



Re: branch names

Posted by Benoit Chesneau <bc...@gmail.com>.
On Tue, Dec 4, 2012 at 7:33 PM, Jan Lehnardt <ja...@apache.org> wrote:

>
> On Dec 4, 2012, at 19:19 , Benoit Chesneau <bc...@gmail.com> wrote:
>
> > On Tue, Dec 4, 2012 at 6:55 PM, Jan Lehnardt <ja...@apache.org> wrote:
> >
> >> Hey all,
> >>
> >> just a heads up, the scheme for branch names we agreed on
> >> is: 1532-feature-add-docs No underscores. Please follow
> >> this.
> >>
> >> The fact that the cors branch doesn’t follow this is a
> >> historic artefact that I thought wasn’t worth cleaning
> >> up, but it looks I was wrong.
> >>
> >> From now on, I will rule with an iron fist about getting
> >> these details right. Current branches with diverging names
> >> are exempt.
> >>
> >> Cheers
> >> Jan
> >> --
> >>
> >
> > Actually we were agree to discuss that later a little more.
>
> Nope, we made a decision:
>
>
> http://mail-archives.apache.org/mod_mbox/couchdb-dev/201210.mbox/%3cDEC04DB0-172C-4517-8554-2BE049A2F606@apache.org%3e
>
>
I only said:

"Anyway if we stay with the current situation yes having one referent doc
would be good."

wasn't considering it so strict neither as a decision. Anyway if most
think it should be done like this then go.

- benoit

Re: branch names

Posted by Jan Lehnardt <ja...@apache.org>.
On Dec 4, 2012, at 19:19 , Benoit Chesneau <bc...@gmail.com> wrote:

> On Tue, Dec 4, 2012 at 6:55 PM, Jan Lehnardt <ja...@apache.org> wrote:
> 
>> Hey all,
>> 
>> just a heads up, the scheme for branch names we agreed on
>> is: 1532-feature-add-docs No underscores. Please follow
>> this.
>> 
>> The fact that the cors branch doesn’t follow this is a
>> historic artefact that I thought wasn’t worth cleaning
>> up, but it looks I was wrong.
>> 
>> From now on, I will rule with an iron fist about getting
>> these details right. Current branches with diverging names
>> are exempt.
>> 
>> Cheers
>> Jan
>> --
>> 
> 
> Actually we were agree to discuss that later a little more.

Nope, we made a decision:

http://mail-archives.apache.org/mod_mbox/couchdb-dev/201210.mbox/%3cDEC04DB0-172C-4517-8554-2BE049A2F606@apache.org%3e

that resulted in: 

http://wiki.apache.org/couchdb/Merge_Procedure?action=diff&rev1=10&rev2=11

We can always change things as this is completely arbitrary. But we must stick
to one scheme. And I am tired of discussing this because we have a working
solution that doesn’t warrant any more bikeshedding.


> I do think we should distinct the issue number from the rest. And using an
> underscore was good for that. Not a big deal though.

The issue number is always first and an integer, the issue type is always one
of "fix", "feature", or other type we come up with that is a single word,
everything else is the short description of the issue. there are no ambiguities
and things are pleasant to read.

I’m happy to change this too all underscores, but not mixed. And we’ve been
through this and everyone who cared weighed in, so hyphens it is.


> Also something that wasn't discussed is how we distinct ticket or pr from
> github from the rest.  *If* this should be distinguished.

Please open a separate discussion on this.

Cheers
Jan
-- 


Re: branch names

Posted by Benoit Chesneau <bc...@gmail.com>.
On Tue, Dec 4, 2012 at 6:55 PM, Jan Lehnardt <ja...@apache.org> wrote:

> Hey all,
>
> just a heads up, the scheme for branch names we agreed on
> is: 1532-feature-add-docs No underscores. Please follow
> this.
>
> The fact that the cors branch doesn’t follow this is a
> historic artefact that I thought wasn’t worth cleaning
> up, but it looks I was wrong.
>
> From now on, I will rule with an iron fist about getting
> these details right. Current branches with diverging names
> are exempt.
>
> Cheers
> Jan
> --
>

Actually we were agree to discuss that later a little more.

I do think we should distinct the issue number from the rest. And using an
underscore was good for that. Not a big deal though.

Also something that wasn't discussed is how we distinct ticket or pr from
github from the rest.  *If* this should be distinguished.

- benoit

Re: branch names

Posted by Paul Davis <pa...@gmail.com>.
On Tue, Dec 4, 2012 at 12:25 PM, Dave Cottlehuber <dc...@jsonified.com> wrote:

> On 4 December 2012 19:08, Robert Newson <rn...@apache.org> wrote:
> > +1
> >
> >
> > On 4 December 2012 17:55, Jan Lehnardt <ja...@apache.org> wrote:
> >
> >> Hey all,
> >>
> >> just a heads up, the scheme for branch names we agreed on
> >> is: 1532-feature-add-docs No underscores. Please follow
> >> this.
> >>
> >> The fact that the cors branch doesn’t follow this is a
> >> historic artefact that I thought wasn’t worth cleaning
> >> up, but it looks I was wrong.
>
> We have 3 branches that are out of kilter, I've fixed them up now,
> 431, 1346, 1536 respectively.
>
> That leaves:
>
> new-security-object - which I can't see in master - any idea what this
> relates to @davisp?
>

It was work on giving _security objects a revision tree. Quite complicated
and exists on my GitHub fork. Feel free to delete it.


> test-for-unexported-functions - @jan ?
> docs - which I will clean up once we are OK on the docs merge.
>
> Finally, I've a suggestion - to keep the working list of branches
> short, but still have the actual commits available if needed, we could
> tag branches like docs or cors that have had significant intermediary
> work. The tags ensure that despite the branch being removed, the
> commits will not be garbage collected. Or just get rid of the branches
> completely if others think that's better.
>
> A+
> Dave
>

Re: branch names

Posted by Jan Lehnardt <ja...@apache.org>.
On Dec 4, 2012, at 19:25 , Dave Cottlehuber <dc...@jsonified.com> wrote:

> On 4 December 2012 19:08, Robert Newson <rn...@apache.org> wrote:
>> +1
>> 
>> 
>> On 4 December 2012 17:55, Jan Lehnardt <ja...@apache.org> wrote:
>> 
>>> Hey all,
>>> 
>>> just a heads up, the scheme for branch names we agreed on
>>> is: 1532-feature-add-docs No underscores. Please follow
>>> this.
>>> 
>>> The fact that the cors branch doesn’t follow this is a
>>> historic artefact that I thought wasn’t worth cleaning
>>> up, but it looks I was wrong.
> 
> We have 3 branches that are out of kilter, I've fixed them up now,
> 431, 1346, 1536 respectively.
> 
> That leaves:
> 
> new-security-object - which I can't see in master - any idea what this
> relates to @davisp?
> test-for-unexported-functions - @jan ?

This one doesn’t have a JIRA and is a dev-branch. We could ask to
prefix them with the dev handle, but this ruling is getting out of hand.

The purpose is to see how we can implement that we can etap-test module-
private functions.


> docs - which I will clean up once we are OK on the docs merge.

+1.

> Finally, I've a suggestion - to keep the working list of branches
> short, but still have the actual commits available if needed, we could
> tag branches like docs or cors that have had significant intermediary
> work. The tags ensure that despite the branch being removed, the
> commits will not be garbage collected. Or just get rid of the branches
> completely if others think that's better.

I did some pruning a few weeks back. We currently don’t have any
superfluous branches around.

I don’t want to restrict usage of branches, we should use them free and
loose. Barring the naming rules for branches that have a JIRA issue
attached.

Can we get back to shipping 1.3.0 now?

Cheers
Jan
-- 



Re: branch names

Posted by Dave Cottlehuber <dc...@jsonified.com>.
On 4 December 2012 19:08, Robert Newson <rn...@apache.org> wrote:
> +1
>
>
> On 4 December 2012 17:55, Jan Lehnardt <ja...@apache.org> wrote:
>
>> Hey all,
>>
>> just a heads up, the scheme for branch names we agreed on
>> is: 1532-feature-add-docs No underscores. Please follow
>> this.
>>
>> The fact that the cors branch doesn’t follow this is a
>> historic artefact that I thought wasn’t worth cleaning
>> up, but it looks I was wrong.

We have 3 branches that are out of kilter, I've fixed them up now,
431, 1346, 1536 respectively.

That leaves:

new-security-object - which I can't see in master - any idea what this
relates to @davisp?
test-for-unexported-functions - @jan ?
docs - which I will clean up once we are OK on the docs merge.

Finally, I've a suggestion - to keep the working list of branches
short, but still have the actual commits available if needed, we could
tag branches like docs or cors that have had significant intermediary
work. The tags ensure that despite the branch being removed, the
commits will not be garbage collected. Or just get rid of the branches
completely if others think that's better.

A+
Dave

Re: branch names

Posted by Paul Davis <pa...@gmail.com>.
+1


On Tue, Dec 4, 2012 at 12:08 PM, Robert Newson <rn...@apache.org> wrote:

> +1
>
>
> On 4 December 2012 17:55, Jan Lehnardt <ja...@apache.org> wrote:
>
> > Hey all,
> >
> > just a heads up, the scheme for branch names we agreed on
> > is: 1532-feature-add-docs No underscores. Please follow
> > this.
> >
> > The fact that the cors branch doesn’t follow this is a
> > historic artefact that I thought wasn’t worth cleaning
> > up, but it looks I was wrong.
> >
> > From now on, I will rule with an iron fist about getting
> > these details right. Current branches with diverging names
> > are exempt.
> >
> > Cheers
> > Jan
> > --
> >
> >
>

Re: branch names

Posted by Robert Newson <rn...@apache.org>.
+1


On 4 December 2012 17:55, Jan Lehnardt <ja...@apache.org> wrote:

> Hey all,
>
> just a heads up, the scheme for branch names we agreed on
> is: 1532-feature-add-docs No underscores. Please follow
> this.
>
> The fact that the cors branch doesn’t follow this is a
> historic artefact that I thought wasn’t worth cleaning
> up, but it looks I was wrong.
>
> From now on, I will rule with an iron fist about getting
> these details right. Current branches with diverging names
> are exempt.
>
> Cheers
> Jan
> --
>
>