[
https://issues.apache.org/jira/browse/COUCHDB-1696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13641544#comment-13641544
]
Dave Cottlehuber commented on COUCHDB-1696:
---
For future reference - upgrading
On Thu, Apr 25, 2013 at 5:32 PM, Dave Cottlehuber d...@jsonified.com wrote:
Is anybody interested in doing this with me, and sharing their
enthusiasm?
I'd like to help, count me (:
--
,,,^..^,,,
Dave,
I would like to do the weekly news on the CouchDB blog. We should be
focusing as much of our efforts on official channels, so that they become
rich sources of information. I would hate to bifurcate things.
Along those lines, I would like to redirect couchdbweekly.com to
Am 25.04.2013 15:39 schrieb Alexander Shorin kxe...@gmail.com:
On Thu, Apr 25, 2013 at 5:32 PM, Dave Cottlehuber d...@jsonified.com
wrote:
Is anybody interested in doing this with me, and sharing their
enthusiasm?
I'd like to help, count me (:
Me too!
Hi everybody,
The Apache Software Foundation is participating in GSoC again this
year, and CouchDB is on the project list of course!
By the end of the summer, we hope you've above all, had fun, and we've
enabled you to make a valued contribution, and ideally help you
continue in your involvement
Marek Kowalski created COUCHDB-1777:
---
Summary: 409 response vs persitent connection
Key: COUCHDB-1777
URL: https://issues.apache.org/jira/browse/COUCHDB-1777
Project: CouchDB
Issue Type:
Good stuff, Dave. Why don't you tweet this from @CouchDB?
On 25 April 2013 15:05, Dave Cottlehuber d...@jsonified.com wrote:
Hi everybody,
The Apache Software Foundation is participating in GSoC again this
year, and CouchDB is on the project list of course!
By the end of the summer, we
In, fact this would make a good blog post too.
Perhaps, massage this into a blog post, and then tweet a link to the blog?
On 25 April 2013 18:07, Noah Slater nsla...@apache.org wrote:
Good stuff, Dave. Why don't you tweet this from @CouchDB?
On 25 April 2013 15:05, Dave Cottlehuber
On 25 April 2013 15:45, Noah Slater nsla...@apache.org wrote:
Dave,
I would like to do the weekly news on the CouchDB blog. We should be
focusing as much of our efforts on official channels, so that they become
rich sources of information. I would hate to bifurcate things.
Good. I would
Matt Horning created COUCHDB-1778:
-
Summary: Reduce checkbox doesn't show up when creating temporary
views
Key: COUCHDB-1778
URL: https://issues.apache.org/jira/browse/COUCHDB-1778
Project: CouchDB
[
https://issues.apache.org/jira/browse/COUCHDB-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Horning updated COUCHDB-1778:
--
Priority: Minor (was: Major)
Reduce checkbox doesn't show up when creating temporary
Hi,
We need to agree on how we will use Git effectively to support our new
regular release cadence. The motivating questions are how we handle
branches during feature releases (a.b.0) and how we handle branches
for maintenance releases (a.b.c).
I present two options to get this rolling but these
Thanks for kicking this off, Bob!
Option 1 would require us to change how we think about master. If a release
is ongoing (which will almost certainly be the case, month over month) then
work is going to need to be merged when it is okayed by the release manager.
In this scenario, to we might
#1 is the procedure almost every project I have worked on follows, we do
actually have an integration branch at mozilla but that is purely due to
the sheer size of the codebase and volume of changes, I see no reason why
CouchDB shouldnt be permanently releasable or why a release would be
Dale,
Take a look at the proposed roadmap process and let me know what you think.
http://wiki.apache.org/couchdb/Roadmap_Process
On 25 April 2013 22:03, Dale Harvey d...@arandomurl.com wrote:
#1 is the procedure almost every project I have worked on follows, we do
actually have an
I'll toss this in too: https://sandofsky.com/blog/git-workflow.html
In particular;
If you treat your public history as pristine, fast-forward merges are
not only safe but preferable. They keep revision history linear and
easier to follow
I think this also addresses Paul's objections to merge
On 25 April 2013 22:35, Robert Newson rnew...@apache.org wrote:
I'll toss this in too: https://sandofsky.com/blog/git-workflow.html
In particular;
If you treat your public history as pristine, fast-forward merges are
not only safe but preferable. They keep revision history linear and
Speaking as someone who's used git-flow in a small-corporate context (and
not as someone who is likely to be contributing overmuch, so huge grains of
salt), I'd like to make a couple of observations:
- Git flow also presumes that the integration branch (develop according
to the defaults, though
On Thu, Apr 25, 2013 at 2:35 PM, Robert Newson rnew...@apache.org wrote:
If we enhance the #1 proposal to include a final rebase against master
before merge, then master will be truly linear. That will make for
easier reading, easier backporting and will enable bisecting when
spelunking for
I'm not sure where this notion that bisecting with merge
commits is harder comes from.
From personal experience, but I concede this might point to my
deficiency and not git's.
On 25 April 2013 22:57, Randall Leeds randall.le...@gmail.com wrote:
On Thu, Apr 25, 2013 at 2:35 PM, Robert Newson
Another point in favour of merge commits (non-ff) is that the branch
merged to leaps forward atomically. It might not be appropriate to see
the intermediate tree for a feature that consists of multiple commits.
B.
On 25 April 2013 22:59, Robert Newson rnew...@apache.org wrote:
I'm not sure
Splitting this off to let the Git conversation continue
without interruption.
On 25 April 2013 22:54, Dale Harvey d...@arandomurl.com wrote:
The Roadmap looks good, I would worry that the point of semver is that you
dont need to support 1.0.X / 1.1.X / 1.2.X and 1.3.X as they are all
Not to the thread, I have spun off Dale's excellent point about release
branches into a new thread. I have done this because it doesn't effect this
conversion, and I want to keep us focused on Git workflow.
(It doesn't effect this conversation, because no matter what we decide,
we'll still want
On Thu, Apr 25, 2013 at 3:08 PM, Noah Slater nsla...@apache.org wrote:
Splitting this off to let the Git conversation continue
without interruption.
On 25 April 2013 22:54, Dale Harvey d...@arandomurl.com wrote:
The Roadmap looks good, I would worry that the point of semver is that you
On 25 April 2013 23:16, Randall Leeds randall.le...@gmail.com wrote:
If we are reliable about forward compatibility and breaking changes
That's the plan!
In practice it's identical (keep around as many versions as makes
sense for supporting real users), but the numbering does change.
[
https://issues.apache.org/jira/browse/COUCHDB-1777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13642511#comment-13642511
]
Adam Kocoloski commented on COUCHDB-1777:
-
Interesting. I can't think of any
26 matches
Mail list logo
