couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ASF IRC Bot <>
Subject Summary of IRC Meeting in #couchdb-meeting
Date Wed, 27 Aug 2014 20:06:15 GMT
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
[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
[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
[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:
[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

  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message