I think the source code has to be present in our repository directly (and then
only if the licenses are compatible, which seems to be the case for the two you
mention). Given that git submodules are pretty nasty to work with and the
subtree merge that is the recommended alternative will
Rebar deps, maybe? I guess I just hate git-submodule and would prefer to use
anything else.
B.
On 8 Jan 2014, at 10:51, Benoit Chesneau bchesn...@gmail.com wrote:
On Wed, Jan 8, 2014 at 11:21 AM, Robert Samuel Newson
rnew...@apache.orgwrote:
I think the source code has to be present
all externals dependencies (mochiweb, jiffy, erlang-oauth, ibrowse, snappy)
has been removed from our source
CouchDB has patches against some of these, how are you preserving them?
I think the topic of whether our dependencies should be included, as they have
been to date, or pulled from
we’re pointing at to
an explicit commit id. That’s a help, but not enough imo.
B.
On 10 Jan 2014, at 12:39, Benoit Chesneau bchesn...@gmail.com wrote:
On Fri, Jan 10, 2014 at 1:36 PM, Robert Samuel Newson
rnew...@apache.orgwrote:
all externals dependencies (mochiweb, jiffy, erlang-oauth
Given the decision in Vienna for post-merge releases to be erlang release shape
(that is, shorn of init.d scripts, etc), does this static build thing still
make sense?
B.
On 15 Jan 2014, at 14:30, Paul Davis paul.joseph.da...@gmail.com wrote:
Last commits fix icu=static for me on OS X.
To follow on from Paul’s responses, we will be deleting fabric_rpc2 before the
merge. That exists only temporarily at Cloudant to ease upgrades, as Paul
notes, it has no place in the final source tree.
B.
On 21 Jan 2014, at 11:39, Paul Davis paul.joseph.da...@gmail.com wrote:
Good points
Definitely need to preserve R14 compatibility, that’s still the most stable
recent series (as long as you don’t use R14B02)…
On 21 Jan 2014, at 14:12, Adam Kocoloski kocol...@apache.org wrote:
On Jan 21, 2014, at 9:00 AM, Dave Cottlehuber d...@jsonified.com wrote:
On 21. Jänner 2014 at
The latest docs should clarify that you need the old spelling for old versions,
and both work for current versions.
B.
On 21 Jan 2014, at 15:49, Alexander Shorin kxe...@gmail.com wrote:
On Tue, Jan 21, 2014 at 4:55 PM, Dirkjan Ochtman dirk...@ochtman.nl wrote:
On Tue, Jan 21, 2014 at 12:24
thanks!
On 21 Jan 2014, at 18:42, Alexander Shorin kxe...@gmail.com wrote:
On Tue, Jan 21, 2014 at 8:16 PM, Robert Samuel Newson
rnew...@apache.org wrote:
The latest docs should clarify that you need the old spelling for old
versions, and both work for current versions.
Ok, I'll update
:
On Wed, Jan 22, 2014 at 11:35 AM, Alexander Shorin kxe...@gmail.com wrote:
On Wed, Jan 22, 2014 at 2:19 PM, Benoit Chesneau bchesn...@gmail.com
wrote:
On Tue, Jan 21, 2014 at 3:25 PM, Robert Samuel Newson
rnew...@apache.orgwrote:
Definitely need to preserve R14 compatibility, that’s still
, Benoit Chesneau bchesn...@gmail.com wrote:
On Wed, Jan 22, 2014 at 1:58 PM, Dave Cottlehuber d...@jsonified.com wrote:
On 22 January 2014 13:23, Benoit Chesneau bchesn...@gmail.com wrote:
On Wed, Jan 22, 2014 at 12:41 PM, Robert Samuel Newson
rnew...@apache.orgwrote:
Benoit,
Cloudant
Benoit,
I’m aware of the changes in R15 and R16.
If we are discussing whether to raise the lowest supported version of erlang
for CouchDB from its current value of R13B04, let’s have a new thread. I will
point out that R14 is stable and widely used still and we’ll go from there.
B.
On 22
and unmaintained release then we should know exactly why and check from
time to time if we still need to stay on this version.
Thanks!
- benoit
On Wed, Jan 22, 2014 at 2:06 PM, Robert Samuel Newson rnew...@apache.org
wrote:
I could have phrased it better, so I’ll do so now;
R14
, Robert Samuel Newson
rnew...@apache.orgwrote:
Ditto, can’t think of a thing worth having post-R14 to take the leap
given
the numerous broken releases. I had forgotten that monitoring was
broken in
R16B01. Good grief.
Probably. So again what are **exactly** these grief. Saying
something
docs is ambiguous and might refer to medical professionals.
B.
On 30 Jan 2014, at 12:26, Noah Slater nsla...@apache.org wrote:
Wow. couchdb-documentation is very long! Why not couchdb-docs? :)
Anyway, you can probably dispense with make. Just get a decent Sphinx
thing set up.
On 29
Our replicator doesn’t handle it because it expects CouchDB to return the
requested design document (since it exists). Jens says Yes, Sync Gateway
doesn't support design documents so it'll return a 404 for those URLs. which
seems to be the route of it.
So, it’s a basic compatibility thing,
Hi,
Yes, I started with that, but it can’t build the code we have on this branch.
We are converging, though.
B.
On 31 Jan 2014, at 17:17, Benoit Chesneau bchesn...@gmail.com wrote:
I'm confused. Such thing is already in the rcouch branch. Shouldn't we
start rather to work on the branch
bchesn...@gmail.com wrote:
On Fri, Jan 31, 2014 at 6:31 PM, Robert Samuel Newson
rnew...@apache.orgwrote:
Hi,
Yes, I started with that, but it can't build the code we have on this
branch. We are converging, though.
B.
np at all was asking. I will be back on that topic next week
Cool!
Should we migrate the old one or start a new, clean one? We can take what’s
good from the old one and leave the rest. Given we now have docs.couchdb.org
where the design, philosophy and API guide should live, the new wiki should
just be the other things (pages for various tools, guides
Noah,
The 1 in 10 that need letting through are for folks sending from outside or
folks that are subscribed but triggered a spam filter?
B.
On 3 Feb 2014, at 14:16, Noah Slater nsla...@apache.org wrote:
We have moderators. I am fed up of moderating them. I want to know
there are other
who forgot to subscribe, or Apache members who are notifying us of
things. Occasionally, someone from a company like Cloudant replies to
thread which may have made it to an internal list. Stuff like that.
On 3 February 2014 15:23, Robert Samuel Newson rnew...@apache.org wrote:
Noah,
The 1
+1 to all that, Noah. I can only imagine what this looks like to casual readers.
Few things require unanimity and this is not one of them.
The reason I’ve stayed quiet on the proposal is that while I don’t feel
strongly for it, I don’t feel strongly against it. It’s not my time or effort
Recent commits in the bigcouch branch redoing some
work already done in rcouch (coming from a 2 years experience
Work done in rcouch is not sacred, does not necessarily go into couchdb master
without editing or review by anyone else, and that applies to bigcouch as well.
As you should know,
Chesneau bchesn...@gmail.com wrote:
On Tue, Feb 4, 2014 at 4:13 PM, Robert Samuel Newson
rnew...@apache.orgwrote:
Recent commits in the bigcouch branch redoing some
work already done in rcouch (coming from a 2 years experience
Work done in rcouch is not sacred, does not necessarily go
, at 16:06, Benoit Chesneau bchesn...@gmail.com wrote:
On Tue, Feb 4, 2014 at 4:50 PM, Robert Samuel Newson
rnew...@apache.orgwrote:
Hi,
It's largely because we're all busy with wholly bigcouch internal things
on our 1843-feature-bigcouch branch, there's nothing *yet* to
cooperate
Clear commit messages are something we’ve committed to in the past and will be
a required practice once we get the merges nailed down. The review process will
include ensuring that commits follow the standard we’ve agreed to.
B.
On 11 Feb 2014, at 08:13, Andy Wenk a...@nms.de wrote:
This is
Maybe.. not add it then?
B.
On 11 Feb 2014, at 19:42, Benoit Chesneau bchesn...@gmail.com wrote:
On Tue, Feb 11, 2014 at 8:13 PM, Adam Kocoloski kocol...@apache.org wrote:
What's the rationale for this option? When would I want to avoid using the
index?
Adam
Well on small db you
I can’t think of a way to say that couchdb is still used but behind a layer to
work around perceived deficiencies, so I would personally say nothing.
The story is deeper and wider than I know but I do know that at least some of
the issues encountered here are to do with the approach taken,
Excellent work! How painful would a Debian build be?
B.
On 13 Feb 2014, at 10:16, Noah Slater nsla...@apache.org wrote:
Also, let's get this put on the website.
On 13 February 2014 11:14, Noah Slater nsla...@apache.org wrote:
Dave, are you up for doing a blog post?
On 13 February 2014
[
https://issues.apache.org/jira/browse/COUCHDB-2059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13900284#comment-13900284
]
Robert Samuel Newson commented on COUCHDB-2059:
---
Good idea. Will enhance
Oh, I meant just 'build it against Debian'. Getting into actual Debian upstream
is a feat for the infinitely patient.
B.
On 13 Feb 2014, at 12:35, Andy Wenk a...@nms.de wrote:
On 13 February 2014 13:22, Dave Cottlehuber d...@jsonified.com wrote:
On 13 February 2014 11:17, Robert Samuel
Either way, it will need to work when sharded, since it’ll appear after the
bigcouch merge.
On 17 Feb 2014, at 10:18, Jan Lehnardt j...@apache.org wrote:
Regardless of rcouch and plugins becoming generally available. I’d be in
favour starting to bundle GeoCouch as soon as possible and make
I think we should use github instead (especially as the integration continues
to improve).
The 'upload patch file' approach for Review Board makes it a non-starter in my
opinion. (Yes, we could insist every participant installs command lines tools
to finesse that, but come on)
B.
On 18 Feb
validate_doc_update cannot modify the document for the reasons you state.
As I said when you asked on IRC, you can write a validate_doc_update function
that refuses any update to a document that doesn’t also add information to that
document about the change being made. That is, you can insist
.
On 19 Feb 2014, at 10:42, Alexander Shorin kxe...@gmail.com wrote:
On Wed, Feb 19, 2014 at 2:24 PM, Robert Samuel Newson
rnew...@apache.org wrote:
validate_doc_update(oldDoc, newDoc, userCtx) {
if (newDoc.audit_trail[0].user != userCtx.name) {
throw({forbidden: You didn’t add your name
push.
Jan
--
Robert Samuel Newson rnew...@apache.org wrote:
I think we should use github instead (especially as the integration
continues to improve).
The 'upload patch file' approach for Review Board makes it a
non-starter in my opinion. (Yes, we could insist every participant
:)
On 19 Feb 2014, at 2:49 PM, Robert Samuel Newson rnew...@apache.org
wrote:
We intend to review work before merging to master, which is why we have
an account on Review Board in the first place, to see if it can help.
Given the level of integration with github now, I think we can
bchesn...@gmail.com wrote:
On Wed, Feb 19, 2014 at 3:47 PM, Andy Wenk a...@nms.de wrote:
On 19 February 2014 15:25, Robert Samuel Newson rnew...@apache.org
wrote:
Yes. It's misleading for folks that stumble on it.
+1
On 19 Feb 2014, at 14:22, Noah Slater nsla...@apache.org wrote
wrote:
On Wed, Feb 19, 2014 at 3:47 PM, Andy Wenk a...@nms.de wrote:
On 19 February 2014 15:25, Robert Samuel Newson rnew...@apache.org
wrote:
Yes. It's misleading for folks that stumble on it.
+1
On 19 Feb 2014, at 14:22, Noah Slater nsla...@apache.org wrote:
Should we
Gratz Alex!
On 22 Feb 2014, at 16:17, Riyad Kalla rka...@gmail.com wrote:
Congrats Alexander; a very passionate and intelligent engineer that CouchDB
is lucky to have engaged.
On Fri, Feb 21, 2014 at 1:08 PM, Noah Slater nsla...@apache.org wrote:
Dear community,
I am delighted to
Welcome Andy!
On 22 Feb 2014, at 16:07, Garren Smith gar...@apache.org wrote:
Congrats Andy this is great.
On 22 Feb 2014, at 5:32 AM, Adam Kocoloski kocol...@apache.org wrote:
Congratulations Andy, thanks for everything you've done so far!
Adam
On Feb 21, 2014, at 3:09 PM, Noah
Dear community,
I am pleased to announce that the CouchDB Project Management Committee has
elected Benjamin Young as a CouchDB committer.
Apache ID: bigbluehat
IRC nick: bigbluehat
Twitter: bigbluehat
By default, external contributions to the project follow the Review-Then-Commit
Adam recently reminded us that Bob Ippolito is the maintainer and hasn't worked
at Mochi Media for quite some time. So it doesn’t sound like a worry. It’s also
rare for mochiweb to be the problem in our stack.
B.
On 24 Mar 2014, at 13:55, Benoit Chesneau bchesn...@gmail.com wrote:
Does
Exactly. It’s when a document is updated at two different couchdb servers, in
two different ways, and then the two replicate to each other. Eventual
consistency is the term used for the algorithm that ensures both sites, after
replicating in both directions, show the same revision (and know
I went through the poll but agree with Paul that it can only be a hint. There
were questions that had multiple right answers but would depend on context to
choose, I still picked the best one in my opinion. I don’t think I’ve ever
seen 8 spaces used in erlang code (well, any code) so that
I appreciate firming up a consensus on indentation styles but I want to be
clearly -1 on a codebase-wide reformatting for the foreseeable future. Beyond
the merges, we have active branches for older releases, the more reformatting
we do, the harder back- and forward-porting becomes. I like the
to fixing things,
and that'd be disappointing.
Would it be fair to put a line in the sand, say, 12 months out, and strongly
suggest that all files be reformatted by then? Or we could tie it to a 2.0
release or similar.
-Joan
- Original Message -
From: Robert Samuel Newson rnew
The real issue is that we proceed with bad input, here’s my alternative
suggestion: branch:
https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=shortlog;h=refs/heads/2221-bug-validate-auth-params,
patch:
By a three node couchdb cluster do you mean BigCouch? If not, then you have
three independent couchdb servers, so your findings aren’t that surprising.
B.
On 9 Apr 2014, at 17:36, Alexander Shorin kxe...@gmail.com wrote:
On Wed, Apr 9, 2014 at 7:11 PM, Arnaud Schoonjans
Are you going to take the latest master commit for 1.6.0?
On 10 Apr 2014, at 09:34, Dirkjan Ochtman dirk...@ochtman.nl wrote:
Hi there,
I'm starting to get moving on 1.6.0 again (finally!). I just updated
the changelog:
http://couchdb.readthedocs.org/en/1.6.x/whatsnew/1.6.html
Please
I was hoping the work in COUCHDB-2221 would be included.
B.
On 10 Apr 2014, at 16:08, Dirkjan Ochtman dirk...@ochtman.nl wrote:
On Thu, Apr 10, 2014 at 5:05 PM, Garren Smith gar...@apache.org wrote:
I thought 1.6.x was going to be recut from master?
As I said, it was already, last week.
R14B04 should be fine (B02 is certainly not, though) and does have some
important (but rare) bugfixes over B01. The strong recommendation for R14B01
comes from Cloudant. We run R14B01 and have for years, we trust it to work (and
we trust it to fail in various known ways). I’m curious to know if
Did you 'make clean' first? This looks like you have a module with the old
#changes_args record and other modules with the new one.
On 26 Apr 2014, at 23:04, Stefan Kögl koeglste...@gmail.com wrote:
Hi,
As I see that 1.6.x is coming along, I've tested upgrading an 1.5 db to the
current
Samuel Newson rnew...@apache.org wrote:
Did you 'make clean' first? This looks like you have a module with the old
#changes_args record and other modules with the new one.
On 26 Apr 2014, at 23:04, Stefan Kögl koeglste...@gmail.com wrote:
Hi,
As I see that 1.6.x is coming along, I've
Count me in.
B.
On 28 Apr 2014, at 21:09, Noah Slater nsla...@apache.org wrote:
Yep. Happy to see what the drafts look like. If two docs make sense,
two docs make sense.
On 28 April 2014 22:04, Joan Touzet jo...@atypical.net wrote:
Nice. I personally would still like to see Diversity
It does seem justified though, it’s obviously to make it easy to refer
unambiguously to a particular item, that doesn’t mean to say we can’t render it
better than this. I would rather not have a document that states everything
twice if we can avoid it.
B.
On 28 Apr 2014, at 22:09, Joan
Hrm, OTP-9167 was reported by Filipe, the main author of the current couchdb
replicator, and he also changed how this was handled in couchdb to compensate.
This is some ancient stuff, hard to believe it’s the cause of our latest issue.
I must be missing something.
On 4 May 2014, at 12:46,
Hi,
Wonderful job, I can find no fault in it.
B.
On 18 May 2014, at 15:27, Andy Wenk andyw...@apache.org wrote:
Hi Joan,
thanks a lot. I have read the post the first time and it is really awesome.
It is very clear and I think also non-native English speaking folks can
understand
Hi,
I finally reviewed this. It’s very good, congrats! My comments are principally
about grammar;
The foundation holds the trademark on the name CouchDB — is this true?
will be sorted out by a — avoid idioms.
people what hat you are wearing — s/what/which/
chair — should be capitalised
Please use: make dev/run
We are far from having a working 'make install'
dev/run will start a joined, three node cluster on ports 15984, 25984, 35984
(any one of which can perform any clustered operation) and the 'inside' ports
of 15986, 25986, 35986, which are the individual nodes.
B.
On
I based the rebar work on yours, though I did remove the cross-compile/static
build bits for simplicity. I am also pretty confident that my work does not
work on all the platforms that rebar.config.script implies. It’s certainly a
work-in-progress. Since it *does* build the bigcouch branch
I see Benoit’s point about empathy though not because it is emotionally
charged but because it is somewhat ambiguous. I have no objection to the text
of item in the CoC which uses the term, though. I am interested in seeing
proposed alternate text, though.
B.
P.S As he’s one of my favourite
Hi,
Ah, I don’t use —admin myself so I readily believe you when you say its broken.
For now, do curl localhost:15986/_config/admins/username -XPUT -d 'password'.
B.
On 6 Jun 2014, at 19:30, Jean-Felix Girard jeanfel...@icloud.com wrote:
Hi,
I couldn't wait more to test the BigCouch merge.
Ah, to _all_docs, might not be hooked up yet. Before I replied earlier I had
verified queries against a regular view and that did indeed work.
I’ll look at _all_docs soon.
On 12 Jun 2014, at 17:41, Jean-Felix Girard jeanfel...@icloud.com wrote:
Hi Russel and Robert,
Thanks for the
HI,
These are great questions, thank you.
Yes, single node couchdb still works, that’s a critical goal for the merge.
Port 5986 points directly to the couch_http*.erl modules we all know. Where
they might make calls to fabric/mem3 they do so conditionally. If any couchdb
1.6 API is missing or
Hi All,
The merge of bigcouch has reached a stage now where I think it’s time to merge
to master. I’m therefore asking folks if there are any blockers preventing me
from proceeding, which involves you each taking a look at 1843-feature-bigcouch
(or, by not doing so, giving implicit consent).
Is there more to do on master for that release? If so, what? If not, branch now?
B.
On 7 Jul 2014, at 21:19, Dirkjan Ochtman dirk...@ochtman.nl wrote:
On Mon, Jul 7, 2014 at 9:11 PM, Robert Samuel Newson rnew...@apache.org
wrote:
The merge of bigcouch has reached a stage now where I think
, Robert Samuel Newson rnew...@apache.org wrote:
Hi All,
The merge of bigcouch has reached a stage now where I think it’s time to
merge to master. I’m therefore asking folks if there are any blockers
preventing me from proceeding, which involves you each taking a look at
1843-feature
...@gmail.com wrote:
On Tue, Jul 8, 2014 at 6:13 AM, Alexander Shorin kxe...@gmail.com wrote:
On Tue, Jul 8, 2014 at 8:03 AM, Benoit Chesneau bchesn...@gmail.com
wrote:
On Mon, Jul 7, 2014 at 9:11 PM, Robert Samuel Newson rnew...@apache.org
wrote:
Hi All,
The merge of bigcouch has reached a stage
You mean to false :)
In 2.0, this will default to
B.
On 10 Jul 2014, at 17:00, Klaus Trainer klaus_trai...@posteo.de wrote:
Hi Bhanu!
As long as you follow the official recommendation to set
`delayed_commits` to `true` (see the `couchdb` section in the
configuration), CouchDB guarantees
(trying that again).
in 2.0, delayed_commits will default to false, the safe setting.
B.
On 10 Jul 2014, at 22:14, Robert Samuel Newson rnew...@apache.org wrote:
You mean to false :)
In 2.0, this will default to
B.
On 10 Jul 2014, at 17:00, Klaus Trainer klaus_trai...@posteo.de wrote
The code components (fabric, mem3, rexi, etc) have their own version numbers
(following semver). Because of the way this was merged, many historical tags
(used by Cloudant during our regular release cycle) are missing as they would
pull in the pre-ip-cleared versions of the modules.
I don’t
This assumes there is a meaningful way to deprecate API endpoints within
couchdb, and I can’t think of one right now. If the response from couchdb is
changed to indicate deprecation, how will we a) ensure no user or client
library is broken and b) expect any user or client library to notice
Adding mvcc for _security is a great idea (happily, Cloudant have done so very
recently, so I will be pulling that work over soon).
A better view server protocol is also a great idea.
On 13 Jul 2014, at 13:13, Samuel Williams space.ship.travel...@gmail.com
wrote:
On 13/07/14 23:47,
, but it is appropriate
for a 2.0 timeframe? I would think it would make more sense in a 3.0
timeframe, given 2.0 is all about merging forks, not writing new features
entirely from scratch.
-Joan
- Original Message -
From: Robert Samuel Newson rnew...@apache.org
To: dev
alternatives for
migration.
--
,,,^..^,,,
On Sun, Jul 13, 2014 at 4:51 PM, Robert Samuel Newson
rnew...@apache.org wrote:
This assumes there is a meaningful way to deprecate API endpoints within
couchdb, and I can’t think of one right now. If the response from couchdb is
changed to indicate
, Robert Samuel Newson rnew...@apache.org wrote:
I’m more than a little skeptical that anyone would notice but I’d like to
hear from others. Perhaps if we couple that with a loud announcement at
release time, with instructions on what to look for, it would work out.
B.
On 13 Jul 2014
:17 PM, Robert Samuel Newson
rnew...@apache.org wrote:
Since we follow semantic versioning, the only meaning behind naming our next
release 2.0 and not 1.7 is that it contains backwards incompatible changes.
It’s for the CouchDB community as a whole to determine what is and isn’t
it as if
it was a q=1 db, i.e.
seq:couchdb@foo,000-fff,12
If you want to allow replication from 1.x hosts you'd have to be more lenient
(should not must).
- Original Message -
From: Robert Samuel Newson rnew...@apache.org
To: dev@couchdb.apache.org
Sent: Monday, July 14, 2014 10:34:21 AM
in the 2.0 release - it is a small, but breaking
change and the original issue is flying around in Jira for years.
Best,
Robert
2014-07-13 22:17 GMT+02:00 Robert Samuel Newson rnew...@apache.org:
Since we follow semantic versioning, the only meaning behind naming our
next release 2.0
]
http://mail-archives.apache.org/mod_mbox/couchdb-dev/201312.mbox/%3c529de44c.4090...@bigbluehat.com%3E
On Thu, Jul 17, 2014 at 2:14 AM, Robert Samuel Newson
rnew...@apache.org wrote:
Great point, +1 to just making that change on master right now.
B.
On 16 Jul 2014, at 22:35, Robert
I would like to see a formal change to R-T-C too. I include the useful notes
that Cloudant follows for this model below. Obviously not all this text belongs
in the bylaws. I suggest it, or a variant of it, belongs on our wiki but is
referenced in the bylaws, which should also cover the rules
today.
B.
On 19 Jul 2014, at 10:50, Jan Lehnardt j...@apache.org wrote:
On 19 Jul 2014, at 10:38 , Robert Samuel Newson rnew...@apache.org wrote:
I think this is backward. We are not proposing API changes just because
BigCouch happens to make them.
Given that we have to bump
What important tools or browsers still need text/plain for our json responses
that justify the mismatch?
On 19 Jul 2014, at 11:30, Jan Lehnardt j...@apache.org wrote:
On 19 Jul 2014, at 12:27 , Robert Samuel Newson rnew...@apache.org wrote:
I agree with you on the category split
Empathy: the ability to understand and share the feelings of another.
Expecting people to have empathy is not vague. Expecting people to be honest is
also not vague. I’m sure we all *have* empathy and that it’s a perfectly
reasonable requirement of our community members.
I think your issue is
Great, thanks. I think we all want the COC to be as clear as possible, looking
forward to your suggestions.
B.
On 19 Jul 2014, at 18:11, Benoit Chesneau bchesn...@gmail.com wrote:
On Sat, Jul 19, 2014 at 5:13 PM, Robert Samuel Newson
rnew...@apache.org wrote:
To save this going
On vetos, I’d approve of restricting them to release branches (of any
repository) but I’m wary of wording it that finely (that is, leaving us unable
to veto something objectionable that falls outside of that description when
regular ASF rules would otherwise have permitted one).
To the notion
Hi,
I’ve read the new draft and I am very pleased with it. I have one issue that
prevents me voting for the bylaws;
Section 2.4: The PMC is the Chair's committee and operates at the behest of
the Chair.
This contrasts starkly with https://www.apache.org/dev/pmc.html#chair;
Remember that, as
I vote +1 to the revised (rev 89) bylaws, thanks for the swift update!
I don’t know if it matters but the opening thread states ' Tuesday, July 21,
2014', but it is of course the 22nd.
B.
On 22 Jul 2014, at 02:37, Noah Slater nsla...@apache.org wrote:
Agreed. Unless any major flaws are
The opening mail in this thread is where the end date was stated and it also
says This vote is being conducted as required by the proposed bylaws
themselves. That’s a little ambiguous but, as I read section 3.9, only Create
or amend official document appears to apply, which means majority
The Code of Conduct defines what we mean by empathy, so we don’t need to get
hung up on alternate definitions.
This Code defines empathy as a vicarious participation in the emotions,
ideas, or opinions of others; the ability to imagine oneself in the condition
or predicament of another.
Hi All,
Cloudant is in the process of donating the work they’ve done on BigCouch since
last years initial drop
(https://incubator.apache.org/ip-clearance/couchdb-bigcouch2.html). A vote is
in progress for accepting the donation through IP clearance but we need another
for the couchdb team to
It’s the day-to-day development on BigCouch since last year, the tarball
contains all the patches being donated.
B.
On 28 Jul 2014, at 11:43, Alexander Shorin kxe...@gmail.com wrote:
What is in the contribution?
,,,^..^,,,
On 28 Jul 2014 14:14, Robert Samuel Newson rnew...@apache.org
+1.
The diff itself is not very clear but that’s a tool limitation. It appears to
accurately reflect the changes that Noah describes and hence I am voting for it.
Future votes, however, should be purely on a readable diff once we have the
tooling to provide such.
B.
On 28 Jul 2014, at 16:21,
+1 to that clarification.
On 28 Jul 2014, at 19:07, Noah Slater nsla...@apache.org wrote:
Joan, for clarification, I've not made the edit. I put it in the
errata. If everyone on this thread is happy with me making the
addition of single as previously explained, I will do so. But I'll
need
Yes, you can read the patches in the tarball or look at the cloudant public
repos that I culled them from. It’s all there.
B.
On 28 Jul 2014, at 20:02, Benoit Chesneau bchesn...@gmail.com wrote:
On Mon, Jul 28, 2014 at 12:46 PM, Robert Samuel Newson rnew...@apache.org
wrote:
It’s
they are running live on
hundreds of machines. It’s basically performance enhancements not radical
feature or api changes.
B.
On 28 Jul 2014, at 20:19, Benoit Chesneau bchesn...@gmail.com wrote:
On Mon, Jul 28, 2014 at 9:12 PM, Robert Samuel Newson rnew...@apache.org
wrote:
Yes, you can read
+1
On 28 Jul 2014, at 20:28, Noah Slater nsla...@apache.org wrote:
Thanks folks.
I added it here:
https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=44302833selectedPageVersions=3selectedPageVersions=2
We are now voting on the following changeset:
6 binding +1’s and no -1’s, the vote passes.
B.
On 29 Jul 2014, at 14:54, Benoit Chesneau bchesn...@gmail.com wrote:
+1. I like the couch_event addition...
- benoit
On Mon, Jul 28, 2014 at 12:14 PM, Robert Samuel Newson rnew...@apache.org
wrote:
Hi All,
Cloudant
Hi,
In general the commit messages should be descriptive enough, the bug number is
for cross-referencing purposes and helps us coordinate release management and
release notes.
the change to the default values for max_write_delay in ticket 28257 was
because of observations in production that
1 - 100 of 271 matches
Mail list logo
