Summary of IRC Meeting in #couchdb-meeting at Wed Aug 27 19:13:22 2014:

Attendees: Wohali, davisp, Kxepal, robertkowalski, chewbranca, strmpnk, rnewson

- Preface
- merge
- 1.6.1
  - Action: We should define a backup release engineer approach for when the RE 
becomes unavailable during a release cycle
- new committers
- CouchDB 2.0 scope
  - Action: robertkowalski to get a branch up with the application/json type 
change for testing
  - Info: couchdb 2.0 to be the result of merges of code from bigcouch and 
rcouch's view changes, other scope to be pushed down the road
  - Info: above is a prediction, not a decision
- fauxton
- http refactor (couchdb 3.0 timeframe)
  - Action: chewbranca to write something up that compares pros/cons of each 
and get an email out for a vote eventually


IRC log follows:

## Preface ##
## merge ##
[Wed Aug 27 19:13:30 2014] <Wohali>: take it away rnewson
[Wed Aug 27 19:13:35 2014] <rnewson>: hi
[Wed Aug 27 19:13:59 2014] <rnewson>: windsor-merge is essentially complete, 
davisp and I will be merging that work to the master branches of all affected 
repositories in the next day or two.
[Wed Aug 27 19:14:52 2014] <strmpnk>: rnewson: Is there anything specific you'd 
like to get eyes on or just general testing of the latest merge?
[Wed Aug 27 19:15:07 2014] <rnewson>: after the merge to master it's all about 
testing.
[Wed Aug 27 19:15:29 2014] <rnewson>: the first post-merge work will be 
etap->eunit, I think.
[Wed Aug 27 19:16:28 2014] <Wohali>: indeed
[Wed Aug 27 19:16:32 2014] <Wohali>: chewbranca: are you here?
[Wed Aug 27 19:18:54 2014] <Wohali>: ok
[Wed Aug 27 19:18:56 2014] <Wohali>: guess that's it
## 1.6.1 ##
[Wed Aug 27 19:19:10 2014] <Wohali>: I think dch is away
[Wed Aug 27 19:19:17 2014] <Wohali>: but it looks like rc4 is a good one so far
[Wed Aug 27 19:19:35 2014] <Wohali>: last time, we had the RE vanish in th 
emiddle of a release as well an it blocked.
[Wed Aug 27 19:19:41 2014] <Wohali>: i think we should come up with a backup RE 
approach in case this happens again
[Wed Aug 27 19:19:43 2014] <rnewson>: crap, I meant to vote on that. :D
[Wed Aug 27 19:21:40 2014] <Wohali>: rofl
[Wed Aug 27 19:21:49 2014] <Wohali>: in any case, we are waiting until dch gets 
back at this point.
[Wed Aug 27 19:21:54 2014] <Wohali>: hopefuly no one is in too much pain.
[Wed Aug 27 19:22:10 2014] <Wohali>: #action We should define a backup release 
engineer approach for when the RE becomes unavailable during a release cycle
[Wed Aug 27 19:22:20 2014] <Wohali>: anything else on 1.6.1?
## new committers ##
[Wed Aug 27 19:23:15 2014] <Wohali>: going to skip this one for now
## CouchDB 2.0 scope ##
[Wed Aug 27 19:23:57 2014] <Wohali>: i wanted to briefly touch on this - it 
looks like on the ML we are settling down to 2.0 being the result of this 
merge, hopefully with view sequence/changes as well (see branch being worked by 
Benjamin Bastian and Benoit Chesneau)
[Wed Aug 27 19:24:06 2014] <Wohali>: and that larger changes around API, etc. 
are now being looked at for 3.0
[Wed Aug 27 19:24:19 2014] <rnewson>: sounds about right
[Wed Aug 27 19:24:55 2014] <Wohali>: #info couchdb 2.0 to be the result of 
merges of code from bigcouch and rcouch's view changes, other scope to be 
pushed down the road
[Wed Aug 27 19:25:08 2014] <rnewson>: err
[Wed Aug 27 19:25:18 2014] <Wohali>: did i get that wrong?
[Wed Aug 27 19:25:41 2014] <rnewson>: we can say that's what we believe, 
there's not enough people in here to call it a decision
[Wed Aug 27 19:25:58 2014] <Wohali>: right
[Wed Aug 27 19:26:04 2014] <Wohali>: #info above is a prediction, not a decision
[Wed Aug 27 19:26:04 2014] <robertkowalski>: i have a small breaking change 
where i change a response type - but i agree to it for the large api changes 
mentioned on the ML
[Wed Aug 27 19:26:05 2014] <rnewson>: it's about the same outcome, anyone 
wanting 2.0 to be anything *else* will have to turn up to a meeting.
[Wed Aug 27 19:26:18 2014] <Wohali>: robertkowalski: i know th eone of which 
you speak, yes let's get that into testing
[Wed Aug 27 19:26:26 2014] <rnewson>: which one?
[Wed Aug 27 19:26:43 2014] <Wohali>: that's the application/json thing iirc
[Wed Aug 27 19:26:47 2014] <robertkowalski>: that application/json thingy
[Wed Aug 27 19:26:48 2014] <rnewson>: ah, yeah
[Wed Aug 27 19:26:48 2014] <robertkowalski>: yes!
[Wed Aug 27 19:26:58 2014] <Wohali>: which no one can remmeber what it actually 
breaks
[Wed Aug 27 19:27:01 2014] <rnewson>: right
[Wed Aug 27 19:27:08 2014] <Wohali>: #actoin robertkowalski to get a branch up 
with the application/json type change for testing
[Wed Aug 27 19:27:13 2014] <Wohali>: #action robertkowalski to get a branch up 
with the application/json type change for testing
[Wed Aug 27 19:27:17 2014] <Wohali>: I can also repeat that post-2.0 cloudant 
will contribute back the query functionality, look for that in a 2.1-ish 
timeframe
[Wed Aug 27 19:27:26 2014] <Wohali>: assuming the ASF & PMC agree to accept it
[Wed Aug 27 19:27:39 2014] <robertkowalski>: :D
[Wed Aug 27 19:28:01 2014] <Wohali>: ok onto fauxton
## fauxton ##
[Wed Aug 27 19:28:40 2014] <Wohali>: there's been a lot of work here recently. 
garren is currently working to bring the code over from what deathbear and 
jennmoneydollars were building out
[Wed Aug 27 19:28:54 2014] <robertkowalski>: yes! garren is currently slicing 
the huge branch from the secondary indexes into smaller pieces
[Wed Aug 27 19:28:56 2014] <Wohali>: unfortunately that branch fell far behind 
master so the work is painful, he is having to piecemeal it and it doesn't seem 
he can keep attribution
[Wed Aug 27 19:29:11 2014] <Wohali>: this is unfortunate but he will i'm sure 
annotate this in commit comments
[Wed Aug 27 19:29:24 2014] <Wohali>: some good stuff in there and it looks 
really smashing
[Wed Aug 27 19:29:41 2014] <Wohali>: also thanks to sean barclay who has been 
driving the design process with compositions and wireframes.
[Wed Aug 27 19:29:53 2014] <Wohali>: fauxtoneers, anything more?
[Wed Aug 27 19:30:07 2014] <robertkowalski>: no
[Wed Aug 27 19:30:23 2014] <robertkowalski>: ah wait!
[Wed Aug 27 19:30:38 2014] <Wohali>: ...go on :)
[Wed Aug 27 19:31:12 2014] <robertkowalski>: Kxepal is filing issues (we 
decided last meeting) and he is doing great work
[Wed Aug 27 19:31:19 2014] <Kxepal>: >_>
[Wed Aug 27 19:31:25 2014] <robertkowalski>: so we are working on the action 
from our last meeting
[Wed Aug 27 19:31:37 2014] <Wohali>: yay!
[Wed Aug 27 19:32:04 2014] <robertkowalski>: he also fixes them, which is 
really great
[Wed Aug 27 19:32:24 2014] <robertkowalski>: ok, i think that it is
[Wed Aug 27 19:33:00 2014] <Wohali>: ok great
## http refactor (couchdb 3.0 timeframe) ##
[Wed Aug 27 19:34:04 2014] <Wohali>: strmpnk has something
[Wed Aug 27 19:34:39 2014] <strmpnk>: I know Russell has been considering which 
HTTP server to move forward with.
[Wed Aug 27 19:34:54 2014] <strmpnk>: Right now there are some prototypes which 
consider webmachine and cowboy.
[Wed Aug 27 19:35:30 2014] <strmpnk>: There were questions of cowboy not 
supporting old releases but it seems like we can push this off till 3.0 is 
something planned.
[Wed Aug 27 19:35:40 2014] <strmpnk>: Beyond that it's work on internal API 
placement.
[Wed Aug 27 19:35:56 2014] <Wohali>: strmpnk: chewbranca mentioned something to 
me that he feels a hybrid approach would be best, and that he spoke to basho 
guys who admitted that they have an internal fork or building a 
webmachine-style state machine on top of cowbow.
[Wed Aug 27 19:35:58 2014] <strmpnk>: An idea was put forward to mirror 
fabric-like calls in the couch module.
[Wed Aug 27 19:36:16 2014] <Wohali>: but i am getting the sense there is 
consensus on cowboy at the http level since it has the most going for it.
[Wed Aug 27 19:37:14 2014] <strmpnk>: Wohali: Yes. Cowboy supports the state 
machine REST stuff so it might be a good choice if we can figure out Erlang 
version support issues for 3.0.
[Wed Aug 27 19:38:20 2014] <strmpnk>: So in the meantime, there can be some 
planning on how the single-node API can be cleaned up so we can instantiate the 
code with a specific backend.
[Wed Aug 27 19:38:42 2014] <strmpnk>: For now the consensus is that the 
clustered and single node APIs are separated but this could change...
[Wed Aug 27 19:39:07 2014] <Kxepal>: more interesting question: who already 
supports spdy/http2.0 or will get it in nearest future?
[Wed Aug 27 19:39:09 2014] <strmpnk>: The primary win is unified code.
[Wed Aug 27 19:39:45 2014] <chewbranca>: for cowboy vs webmachine, I think it's 
not a great comparison, I think webmachine is the level of abstraction that we 
want and that cowboy is the server with the best long term potential and also 
the one that currently supports all the web technologies
[Wed Aug 27 19:40:12 2014] <chewbranca>: I think we should V1 run with 
webmachine, and then rip out mochiweb from webmachine and swap in cowboy once 
we get off of r14
[Wed Aug 27 19:41:27 2014] <chewbranca>: cowboy does offer some of the restful 
resource declaration stuff, but it's apparently not as comprehensive and also 
doesn't support the dispatch flow chart 
[Wed Aug 27 19:43:52 2014] <Wohali>: I think the goal was to get off of r14 by 
3.0 
[Wed Aug 27 19:43:58 2014] <Wohali>: in which case we can be more aggressive 
about what we use
[Wed Aug 27 19:44:06 2014] <chewbranca>: I want to write something up at some 
point that compares pros and cons of each and get an email out for a vote
[Wed Aug 27 19:44:08 2014] <Wohali>: i'd also not like to have to change the 
http layer twice in as many versions :)
[Wed Aug 27 19:44:11 2014] <Wohali>: sounds good.
[Wed Aug 27 19:44:19 2014] <rnewson>: I'm going to dispute that as a "goal" 
every time it comes up.
[Wed Aug 27 19:44:27 2014] <Wohali>: #action chewbranca to write something up 
that compares pros/cons of each and get an email out for a vote eventually
[Wed Aug 27 19:45:14 2014] <rnewson>: no.
[Wed Aug 27 19:45:20 2014] <Wohali>: ok
[Wed Aug 27 19:45:21 2014] <chewbranca>: I do think this is the opportunity to 
restructure the http api
[Wed Aug 27 19:45:24 2014] <Wohali>: any other points?
[Wed Aug 27 19:45:42 2014] <rnewson>: "get off of r14" is not a goal. "no 
longer expend effort to support r14" is.
[Wed Aug 27 19:45:51 2014] <rnewson>: but it's currently no effort.
[Wed Aug 27 19:46:22 2014] <Wohali>: if we depend on cowboy we won't be able to 
support r14.
[Wed Aug 27 19:46:24 2014] <Wohali>: then fine.
[Wed Aug 27 19:46:35 2014] <Wohali>: I think the goal was to not have to 
support r14 by 3.0
[Wed Aug 27 19:46:36 2014] <Wohali>: better?
[Wed Aug 27 19:46:42 2014] <rnewson>: what does cowboy require and why?
[Wed Aug 27 19:46:47 2014] <davisp>: R16 soonish
[Wed Aug 27 19:46:52 2014] <rnewson>: no, that's the same goal restated
[Wed Aug 27 19:46:53 2014] <Wohali>: attempts to patch cowboy to support r14 
have been closed
[Wed Aug 27 19:46:59 2014] <Wohali>: they won't accept the PR
[Wed Aug 27 19:47:05 2014] <rnewson>: it is not a "goal" to drop support for 
working versions of erlang.
[Wed Aug 27 19:47:05 2014] <Wohali>: davisp tried once, I think...i forget
[Wed Aug 27 19:47:09 2014] <davisp>: I had a PR to ranch awhile ago that said 
they were going to drop R15 and older "soon"
[Wed Aug 27 19:47:14 2014] <Wohali>: ^^
[Wed Aug 27 19:47:37 2014] <davisp>: I expressed my trepidation depending on a 
project that makes these sorts of decisions forcefully
[Wed Aug 27 19:47:43 2014] <davisp>: especially given the PR itself was trivial
[Wed Aug 27 19:47:45 2014] <rnewson>: right
[Wed Aug 27 19:47:55 2014] <rnewson>: I share that trepidation.
[Wed Aug 27 19:48:04 2014] <Wohali>: got it.
[Wed Aug 27 19:48:08 2014] <rnewson>: cowboy can trivially work with r14 but 
refuse?
[Wed Aug 27 19:48:13 2014] <Wohali>: we're not going to resolve this here but 
this is somethign for the ML
[Wed Aug 27 19:48:18 2014] <rnewson>: sure.
[Wed Aug 27 19:48:22 2014] <Wohali>: fwiw those horrible other people (cb) 
built their own thing
[Wed Aug 27 19:48:26 2014] <davisp>: rnewson: it was ranch that wasn't 
backwards compatible which is a core dep of cowboy
[Wed Aug 27 19:48:27 2014] <davisp>: same authors
[Wed Aug 27 19:48:28 2014] <Wohali>: that is alway san option but ugh
[Wed Aug 27 19:48:35 2014] <davisp>: we could write a NIF!
[Wed Aug 27 19:48:47 2014] <rnewson>: If there is compelling reasons to adopt 
tech that isn't r14 compatible, we can discuss adopting it and accepting the 
trade-off
[Wed Aug 27 19:48:48 2014] <Wohali>: and it means we have to worry about 
websockets, spdy, etc. all of which are in cowboy....pros/cons that russell is 
going to write up should drive the decision making process.
[Wed Aug 27 19:48:58 2014] <rnewson>: but I, at least, oppose dropping support 
without sufficient reason
[Wed Aug 27 19:49:03 2014] <chewbranca>: this is another reason I'm suggesting 
run with webmachine, then rip out mochiweb support from webmachine and replace 
it with cowboy down the road
[Wed Aug 27 19:49:08 2014] <davisp>: Link to that  ranch PR: 
https://github.com/ninenines/ranch/pull/76
[Wed Aug 27 19:49:17 2014] <rnewson>: chewbranca: that's interesting.
[Wed Aug 27 19:49:24 2014] <chewbranca>: we could do a 3.0 release with the new 
http api, but still support r14
[Wed Aug 27 19:49:40 2014] <rnewson>: we should also wonder if adopting any new 
framework is warranted.
[Wed Aug 27 19:49:40 2014] <davisp>: That sounds reasonable to me
[Wed Aug 27 19:49:58 2014] <Wohali>: ok
[Wed Aug 27 19:49:59 2014] <rnewson>: it *feels* like our http layer is simply 
crufty. is mochiweb actually a problem? 
[Wed Aug 27 19:49:59 2014] <chewbranca>: I've looked into it a bit and it 
doesn't look overly complex to replace mochiweb with cowboy, and apparently 
basho already has an internal branch that does that
[Wed Aug 27 19:50:08 2014] <chewbranca>: I'm trying to get them to push that 
out so we can run with
[Wed Aug 27 19:50:17 2014] <Wohali>: that'd be swell
[Wed Aug 27 19:50:20 2014] <rnewson>: rather, is switching to not-mochiweb 
going to improve things mostly by causing us to do the rewrite?
[Wed Aug 27 19:50:27 2014] <chewbranca>: rnewson: mochiweb is a problem in that 
it's significantly behind cowboy in terms of raw technology
[Wed Aug 27 19:50:29 2014] <davisp>: rnewson: I've heard rumblings that cowboy 
is faster, but haven't done the research personally
[Wed Aug 27 19:50:39 2014] <rnewson>: 'raw technology'?
[Wed Aug 27 19:50:55 2014] <davisp>: also, I really don't give a hoot if we use 
either if we switch to webmachine
[Wed Aug 27 19:50:58 2014] <chewbranca>: websockets, server sent events, spdy, 
etc
[Wed Aug 27 19:51:00 2014] <davisp>: rnewson: its the uncooked kind
[Wed Aug 27 19:51:03 2014] <strmpnk>: rnewson: options to use spdy and possibly 
http 2.0. &c.
[Wed Aug 27 19:51:09 2014] <rnewson>: hm, ok.
[Wed Aug 27 19:51:17 2014] <rnewson>: the http 2.0 crap hasn't died down then.
[Wed Aug 27 19:51:19 2014] <strmpnk>: chewbranca: I think we already support 
server sent events but I guess it could make it easier?
[Wed Aug 27 19:52:07 2014] <chewbranca>: so there's two things with the http 
layer IMO, 1) restructure the API, 2) update the http server
[Wed Aug 27 19:52:10 2014] <strmpnk>: rnewson: I'm not sure how couch will 
leverage the standard yet but it could prove useful for those needing the 
channel support to avoid head of line blocking.
[Wed Aug 27 19:52:11 2014] <chewbranca>: we can do those in isolation
[Wed Aug 27 19:52:27 2014] <chewbranca>: and hey, maybe by the time we get to 
2) mochiweb will support all the things and we can skip it
[Wed Aug 27 19:52:53 2014] <chewbranca>: but I think 1) is a good thing to do, 
and refactoring the http stack is a good time to do it
[Wed Aug 27 19:53:39 2014] <rnewson>: I want a swear jar every time someone 
says "refactor" for a change that alters behavior.
[Wed Aug 27 19:54:12 2014] <strmpnk>: My concern there is that altering the API 
will make this much harder to find consensus on.
[Wed Aug 27 19:54:13 2014] <rnewson>: the case for switching from mochiweb is 
clear, at least. next topic?
[Wed Aug 27 19:54:15 2014] <chewbranca>: my point above is not that they're the 
same thing, but rather than it's an opportune time
[Wed Aug 27 19:54:28 2014] <strmpnk>: Iterating on a cleaner codebase will make 
that cheaper, AFTER the unification.
[Wed Aug 27 19:54:35 2014] <chewbranca>: I'm suggesting that changing the http 
api behavior is simplest to do while doing an http refactor
[Wed Aug 27 19:54:51 2014] <rnewson>: that's another dollar for me...
[Wed Aug 27 19:55:08 2014] <chewbranca>: ...
[Wed Aug 27 19:55:28 2014] <Wohali>: dollar?
[Wed Aug 27 19:55:38 2014] <Wohali>: ah right
[Wed Aug 27 19:56:00 2014] <Wohali>: rnewson's a stickler about the use of the 
term refactor meaning absolutely no behaviour change at all
[Wed Aug 27 19:56:15 2014] <chewbranca>: which is why I've chosen my wording 
carefully
[Wed Aug 27 19:56:30 2014] <rnewson>: that's the only meaning of "refactor". 
The term was coinced specifically and solely to mean that, as distinct from any 
other word. :)
[Wed Aug 27 19:56:31 2014] <Wohali>: i.e., a purely structural change with no 
visible change outside of whatever box you are defining as the endpoints of the 
system
[Wed Aug 27 19:56:45 2014] <rnewson>: chewbranca is saying it's both an api 
change *and* a refactor.
[Wed Aug 27 19:57:23 2014] <rnewson>: we'll leave it there, since the sum is 
not a refactor, and neither of us would call it the net result that.
[Wed Aug 27 19:58:08 2014] <chewbranca>: sure, I'll agree with you there, 
consolidating down to one API would strictly be a refactor, and everything past 
that would be outside the scope of a refactor
[Wed Aug 27 19:59:03 2014] <Wohali>: ok thanks.
[Wed Aug 27 19:59:40 2014] <rnewson>: chewbranca: even that wouldn't be because 
there are discrepancies between chttpd and couch_httpd behavior :(
[Wed Aug 27 19:59:51 2014] <chewbranca>: rnewson: ahhh true
[Wed Aug 27 20:00:30 2014] <robertkowalski>: rnewson: is there another 
direction you would prefer?
[Wed Aug 27 20:01:18 2014] <robertkowalski>: and you have currently in mind
[Wed Aug 27 20:03:52 2014] <rnewson>: no, I just want it clear what our options 
are and what they mean.
[Wed Aug 27 20:03:56 2014] <rnewson>: and what they aren't.
[Wed Aug 27 20:04:10 2014] <Wohali>: ok cool we are all in agreement that the 
next step is to write that up
[Wed Aug 27 20:04:14 2014] <robertkowalski>: ok, i mean i have no clue on 
erlang, but maybe we need more time for a decision
[Wed Aug 27 20:04:17 2014] <Wohali>: and russell's volunteered, thank you 
russell!
[Wed Aug 27 20:04:23 2014] <Wohali>: robertkowalski: no decision is being 
reached today
[Wed Aug 27 20:04:26 2014] <Wohali>: this is just lively chat :)
[Wed Aug 27 20:04:29 2014] <rnewson>: I don't see 2.0 being anything more than 
the merge
[Wed Aug 27 20:04:30 2014] <Wohali>: anyway we are over our time for this 
meeting
[Wed Aug 27 20:04:32 2014] <rnewson>: and maybe view changes
[Wed Aug 27 20:04:42 2014] <Wohali>: +1 and i think everyone's in line there
[Wed Aug 27 20:04:49 2014] <rnewson>: that will introduce two http layers that 
are not identical in behavior
[Wed Aug 27 20:04:54 2014] <rnewson>: then in 3.0 we fix that
[Wed Aug 27 20:05:57 2014] <Wohali>: ok i think we're don ehere.
[Wed Aug 27 20:06:03 2014] <Wohali>: thank you all for coming to the meeting!
[Wed Aug 27 20:06:07 2014] <Wohali>: ASFBot: meeting end


Meeting ended at Wed Aug 27 20:06:07 2014

Reply via email to