couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: branch names
Date Tue, 04 Dec 2012 18:38:22 GMT

On Dec 4, 2012, at 19:25 , Dave Cottlehuber <dch@jsonified.com> wrote:

> On 4 December 2012 19:08, Robert Newson <rnewson@apache.org> wrote:
>> +1
>> 
>> 
>> On 4 December 2012 17:55, Jan Lehnardt <jan@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
-- 



Mime
View raw message