Hi, Joan, thanks for moderating the meeting. Very interesting things have been discussed. I am really looking forward to test the merged windsor-merge (where does that name come from btw :) ) into master.
Thanks to everybody for this tremendous work! Cheers Andy On 27 August 2014 22:06, ASF IRC Bot <asf...@urd.zones.apache.org> wrote: > 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 > -- Andy Wenk Hamburg - Germany RockIt! GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 9588 https://people.apache.org/keys/committer/andywenk.asc
