Meeting in #couchdb-meeting, started Wed Jan 16 20:21:36 2013, ended Wed Jan 16 21:17:12 2013:

Members present: Noah, benoitc, jan____, dch, Humbedooh, Kxepal

Table of contents:

  1. Preface
  2. 1.3.x
    1. planning to kick off release cycle on 2013/2/1 (dch, 20:26:41)
  3. documentation for building on linux
  4. CI
    1. jan announced http://wiki.apache.org/couchdb/CI which is just being soft launched and needs your help! (dch, 21:09:28)
  5. CouchDB Conf

Actions:

  1. dch to update COUCHDB-1629 with Windows status and any other info if possible (dch, 20:24:42)
  2. Jan nudge 1629 on dev@ for resolution. (jan____, 20:25:26)
  3. dch to summarise approach for erlang & spidermonkey dependencies to dev@ for comment. (dch, 21:02:19)

Preface

20:21:49 [dch]: Humbedooh: np, I can learn a new syntax
20:21:49 [jan____]: dch: http://people.apache.org/~humbedooh/asfbot.html

1.3.x

20:22:19 [dch]: phew
20:22:19 [jan____]: woot woot
20:22:49 [dch]: so, jan____ anything to share on the performance discussion? I've loosely followed it but not up to speed.
20:22:58 [jan____]: heh "speed"
20:23:05 [jan____]: nothing I can share here.
20:23:11 [dch]: ok.
20:23:49 [dch]: blockers - we only have https://issues.apache.org/jira/browse/COUCHDB-1629 according to jira.
20:24:27 [jan____]: https://issues.apache.org/jira/browse/COUCHDB-1634 is blocking too

dch: dch to update COUCHDB-1629 with Windows status and any other info if possible

20:24:56 [jan____]: we should raise 1629 on dev@ so someone can take a stab
20:25:26 [dch]: ok, I added FIX FOR 1.3.x as well

jan____: Jan nudge 1629 on dev@ for resolution.

20:26:04 [jan____]: thanks
20:26:19 [dch]: Um I will have a long train ride next week, I will spend it on documenting something. any requests?
20:26:19 [jan____]: otherwise business as usual, trying to start teh release on 1/2/2013
20:26:26 [dch]: good call.

dch: planning to kick off release cycle on 2013/2/1

20:27:04 [dch]: ok, so we are done with 1.3.x discussions for the moment.
20:27:06 [jan____]: ok, next topic?
20:27:07 [dch]: other topics?
20:27:11 [jan____]: :)

documentation for building on linux

20:27:41 [jan____]: dch: can you give a status?
20:27:51 [dch]: so the last maintenance releases produced the usual par-for-course issues with building on various linux flavours and combinations.
20:28:34 [dch]: main contributing factors are:
20:28:56 [dch]: 1. inappropriate erlang releases or versions (R14A on debian, too old or too new on ubuntu for a specific couchdb release)
20:29:41 [dch]: 2. the usual spidermonkey shenanigans when we have any of the firefox or seamonkey / thunderbird xulrunner stuff in the way
20:29:56 [dch]: 3. general hiccups with other dependencies not being what they expect
20:30:33 [dch]: from a project perspective I would like to see installing couchdb on debian, ubuntu, and centos/rhel be clear, reliable and consistent as an outcome.
20:30:33 [dch]: this means:
20:31:04 [dch]: referring to, or providing directly, a tested working erlang package separate from the actual linux distribution makes available
20:31:11 [jan____]: 1. we try to match release lines with older distributions, e.g. if you are on 1.1.z, we try to keep it so you can go up the z, but you might run into trouble when you want to go to 1.2.z
20:31:19 [jan____]: we might fail here, too, as we don’t have any rigorous lists or anything
20:31:34 [dch]: and doing a similar thing for spidermonkey as well. e.g. cloudant has a very nice libmozjs1.8.5 for releases that don't yet have that.
20:32:11 [jan____]: dch: excellent idea, have packages for all dependencies and shit. lots of work, but definitely worth it
20:32:13 [dch]: and thirdly putting into somewhere in the source tree what the lower and upper bounds are for the dependencies. and remove all the external pointers for that.
20:32:34 [benoitc]: we could just stop to build against shared libs ...
20:32:49 [dch]: so erlang: I've done some testing with erlang solutions releases, that seems pretty good. I'm also pleased to see that they serve this via COUCHDB so it seems fated.
20:33:34 [dch]: and spidermonkey is nicely provided via http://packages.cloudant.com/debian/dists/wheezy/main/binary-amd64/ for example
20:33:36 [dch]: icu normally "just works"
20:34:26 [jan____]: benoitc: possible, but unlikely given regular distros unbundling BS
20:34:26 [dch]: benoitc: fair point.
20:34:56 [dch]: putting my "package maintainer" hat on, I'm not sure I like this. But the current state is damaging for our project, and I don't see a flood of maintainers updating the wiki content.
20:35:35 [dch]: to finish, I am by no means an expert in packaging, or maintaining, so I could be speaking through the proverbial aperture.
20:35:56 [benoitc]: my question is : do we need all the power of latest spidermonkey or icu
20:35:59 [benoitc]: also erlang
20:36:21 [benoitc]: and behind that how we can gracefully degrade our requirements in couch
20:36:33 [dch]: But the status quo is woeful, and we need to get to this level of simplicity http://docs.mongodb.org/manual/tutorial/install-mongodb-on-ubuntu/
20:36:41 [benoitc]: so we can work on old versions
20:37:26 [jan____]: benoitc: we don’t nead cutting edge latest, but it is generally good practice to stay on current releases.
20:37:34 [jan____]: at least be compatible with them
20:38:12 [jan____]: maybe this is a good time to ralley up a “builds team” that could get people active that don’t necessarily contribute to the erlang core
20:38:13 [benoitc]: well do we need for example to be compatible with 10.04 when a new LTS replaced it ?
20:38:19 [jan____]: till__ comes to mind
20:38:37 [dch]: so let's break this up into 2 parts.
20:38:41 [jan____]: benoitc: definitely not with 1.2.x or 1.3.x
20:38:43 [benoitc]: also why do we need to have our new versions of couch works on old release like 10.04 where we have some versions that already work
20:39:12 [jan____]: benoitc:but if, say 1.0.x or 1.1.x are current for 10.04, they should stay cpmpatible with whatever is current for the dependenceis on that LTS
20:39:20 [jan____]: benoitc: exactly, that’s what I mean :)
20:39:20 [dch]: 1. erlang. do we focus on a tested "works with Erlang Solutions" path? Basically acknowledging that anybody with an LTS ubuntu or debian, or RH equivalent, will be doomed trying to use the default packages provided with their OS?
20:39:26 [benoitc]: what i am saying is that we should try to have current working on latest distri at the release but other than that we shouldn't care
20:39:43 [dch]: benoitc: yes I think we do need to provide a working configure build for 10.04 (as an excellent example).
20:40:04 [jan____]: dch: but for 1.3.0?
20:40:19 [benoitc]: well those who want to stay with 10.04 have to understand they cant have the cutting edge
20:40:26 [jan____]: dch: if you want to run 1.3.0, we should be able to expect a newer linux
20:40:34 [benoitc]: you can't have the butter and the girl coming with
20:40:41 [jan____]: in an ideal world, we can cater all permuations, but I don’t see it today given the manpower
20:40:49 [jan____]: benoitc: lol, exactly :D
20:40:56 [dch]: jan____: if erlang and spidermonkey are available, then couchdb typically "just works".
20:41:26 [jan____]: dch: If the packages are there, weay as well write things up
20:41:41 [jan____]: but I don’t see us maintaining old distros
20:42:21 [dch]: jan____: the effort to test , assuming we specify "works with X and Y" is not enormous. And not supporting 1.0.x and 1.1.x will help a lot in this regard, once 1.3 is released.
20:43:19 [dch]: lucid's pretty old. I would love our test suite to share (with suitable disclosure) the OS platform, spidermonkey, and erlang versions used. I would guess that is doable.
20:43:19 [benoitc]: related, but what is wrong with our approach with the distrib?
20:43:41 [Noah]: will this get easier when we adopt V8 and rebar?
20:43:49 [benoitc]: or rather why maintainer of distri don't do the extra effort to come back with us with patches related to
20:43:56 [jan____]: Noah: a little.
20:43:57 [dch]: lucid, is supported by ubuntu until april 2015 on server side.
20:44:03 [benoitc]: Noah: v8 now except if we embed it
20:44:19 [Noah]: benoitc: please clarify
20:44:34 [benoitc]: Noah: each distri has their version of v8
20:44:42 [benoitc]: because their is no official tarball of v8
20:44:50 [benoitc]: only tagged version in their scm
20:44:56 [Noah]: see no reason why we can't provide binary packages for linux that bundle V8 maybe?
20:45:05 [Noah]: doesn't rebar solve that for us?
20:45:19 [Noah]: i thought rebar can prepare an archive will all the deps downloaded?
20:45:21 [benoitc]: sure that was i was saying when it was about giving static binaries
20:45:26 [Noah]: we can just distribute that as a "binary" tarball
20:45:26 [benoitc]: Noah: yes
20:45:41 [Noah]: cool
20:45:43 [benoitc]: i would be all for that, but it would alien us the distri bs
20:45:48 [Noah]: i really think we need to switch to rebar ASAP
20:45:49 [Noah]: fuck this autotools shit
20:46:05 [dch]: so IMHO that swaps spidermonkey issues for node issues. I think there will be similar pain there.
20:46:19 [Noah]: dch: i hear V8 is a lot easier to build
20:46:35 [Noah]: i also think there are more creases being ironed out here for us by other people (riak, node, etc)
20:46:57 [benoitc]: the good thing with v8 is that they provide real version even if not as tarball
20:47:03 [benoitc]: (riak is using spidermonkey)
20:47:11 [dch]: Noah: as a user, no real difference for me in building either. but node is evolving *very* fast. and v8 also. So we will still need to ensure compatibility with a changing binary target.
20:47:19 [dch]: benoitc: super old tho, still on 1.7.0 something last I checked.
20:47:26 [benoitc]: dch: v8 != nodejs
20:47:49 [benoitc]: dch: mmm i though they had made the change for tracemonkey
20:47:56 [Noah]: right, and we're not the only db building on v8 - in fact, at this stage, we're practically the only db *not* building on it
20:48:04 [dch]: benoitc: sure. but the point is, irrespective of the JS engine, it will still change over time, and we will still need to manage our integration with that.
20:48:26 [Noah]: dch: nothing new there. we've been doing it for half a decade with SM
20:48:29 [benoitc]: dch: if we embed it we can stay as long we want with the version we embed
20:48:42 [benoitc]: when with sm we can't embed it due to the license
20:49:04 [jan____]: I agree that while some build/install issues might go away with v8, it is not a given. there are other advantages, too.
20:49:34 [dch]: so let's not get too off track here, and turn this into a JS engine discussion.
20:50:19 [dch]: any major objections to me using erlang solutions + cloudant as the reference for testing and building couch, and updating the wiki/docs accordingly?
20:50:34 [dch]: I'll draft a suitable email for the list anyway to discuss.
20:50:41 [Noah]: cool
20:51:04 [benoitc]: dch: i am a little annoyed to propose to rely on third party
20:51:19 [Noah]: can you clarify "rely"?
20:51:34 [Noah]: is this an ongoing dependency? i am not up to speed on what the proposal is
20:52:04 [Noah]: 20:36:32 <•dch> But the status quo is woeful, and we need to get to this level of simplicity http://docs.mongodb.org/manual/tutorial/install-mongodb-on-ubuntu/
20:52:13 [Noah]: dch, the INSTALL.Unix file is meant to be ^^^ THIS ^^^ simple
20:52:21 [dch]: we need to reduce our "attack surface" here. We are trying to get couch to build anywhere, anytime, with anything. And we are failing at it.
20:52:45 [jan____]: benoitc: I’m not sure how to solve this except providing our own binary builds for erlang which seems overkill. This is (as far as I understand) only for old versions of distros for older versions of CouchDB.
20:52:58 [jan____]: newer stuff should work with whatever the distros have
20:53:05 [benoitc]: dch: but we need to be neutral in our proposal
20:53:28 [benoitc]: jan____: yes I understand
20:53:29 [dch]: Noah: INSTALL.Unix is good, but the normal user gets a broken or incompatible erlang version, which we don't check for, and there are multiple options for spidermonkey that continually bite us as they get upgdated over time.
20:53:33 [jan____]: benoitc: who else provides binary erlang packages and why do we need to be neutral?
20:53:42 [jan____]: we go with whatever works best for our users.
20:54:04 [Noah]: dch: can we start to check for those things? is this a patch to configure.ac?
20:54:11 [benoitc]: jan____: to be honest I would prefer : here is the hard path, then say "oh by the way you can get a full erlang build "
20:54:12 [benoitc]: with esl
20:54:18 [dch]: look I don't mind what is picked, but I want us to pick *something*.
20:54:34 [benoitc]: jan____: i proposed sometimes ago to work on an sdk
20:54:49 [dch]: Noah: it's technically feasible to detect and manage all of these, but we don't have time and resource to achieve that, and test for it.
20:55:04 [benoitc]: posted a mail about that : https://github.com/refuge/refuge-sdk
20:55:04 [Noah]: dch: well how do we hope to document it then?
20:55:04 [jan____]: benoitc: I understand 100% where you are coming from, but I am willing to forgo that in favour of giving users a simple way to use CouchDB and worry about independent free softawre later
20:55:26 [benoitc]: general idea was to provide the tools to allows people to build things like couchdb using erlang
20:55:26 [dch]: and even then, when we do say in configure.ac "your erlang is too old/new" the user will still go "too hard, how do I install this" ?
20:55:37 [jan____]: benoitc: I had not seen that email, or forgot about it, sorry
20:55:49 [Noah]: dch: ideally we need both things
20:56:26 [dch]: Noah: I am thinking we end up with just 2 levels of INSTALL guides. (1) use these packages from these non-core repos to get your dependencies in order, and then you will be able to build couchdb from source knowing we tested it.
20:56:41 [dch]: and (2) read INSTALL.Unix, it shares all the gory details.
20:56:49 [dch]: Noah: yup, so I agree, we need both.
20:56:56 [benoitc]: does oour INstall files link to the wiki ?
20:57:04 [Noah]: yes
20:57:14 [jan____]: benoitc: yes, many times
20:57:18 [dch]: benoitc: that's part of the problem, its like a nested GOTO spaghetti monster hell. Which one do you trust?
20:57:26 [benoitc]: i mean for linux do we link to a specific link ?
20:57:34 [dch]: oh and this guy wrote a blog post last week.
20:57:34 [jan____]: benoitc: yes
20:57:43 [benoitc]: ACTION reread that file
20:57:56 [Noah]: i patched it recently
20:57:57 [Noah]: added a link to the wiki at the top
20:58:03 [dch]: benoitc: we can be a lot cleaner with this, but I think 1.3.x and 1.2.1 are pretty damn good now.
20:58:11 [dch]: thanks noah and all for working on this.
20:58:56 [benoitc]: mmm I see http://wiki.apache.org/couchdb/Troubleshooting
20:58:56 [jan____]: ok, any action items here?
20:59:13 [Noah]: benoitc: might be on 1.3 branch
20:59:20 [Noah]: benoitc: probably on 1.3 branch
20:59:41 [jan____]: benoitc: master and 1.3.x
20:59:49 [benoitc]: mmm https://github.com/apache/couchdb/blob/master/INSTALL.Unix
20:59:50 [jan____]: > grep -c wiki.apa INSTALL.Unix
20:59:56 [jan____]: 5
21:00:06 [jan____]: first occurence in line 5
21:00:11 [dch]: so unless you're telling me I am an idiot and this approach is a path to failure, I'll #action send note to dev@ and start working on this for a 1.2.1 and 1.3.x on debian squeeze, wheezy, ubuntu LTS versions and precies.
21:00:11 [dch]: for a start
21:00:11 [benoitc]: ok http://wiki.apache.org/couchdb/Installing_on_Debian
21:00:11 [Noah]: specifically the first one
21:00:13 [jan____]: line 8
21:00:13 [benoitc]: goood
21:00:35 [benoitc]: was just thinking we could have an sh | wget http://install.couchdb.org/install.sh
21:00:41 [dch]: benoitc: except I started updating these wikis for 1.3.x and now they don't always work for <= 1.2.1
21:00:41 [jan____]: dch: great approach, just needs work
21:00:41 [benoitc]: that could do the work for the user
21:00:49 [benoitc]: check the distri
21:00:56 [benoitc]: find the appropriate thing
21:01:04 [jan____]: benoitc: that is also nice, but compeltely derailing the current discussion
21:01:04 [dch]: benoitc: yes, that has also come to mind, but its complicated if we want to point to upstream packages.
21:01:04 [benoitc]: eventually ask to update the sources.list
21:01:04 [benoitc]: thing like this
21:01:34 [Noah]: benoitc: the effort needed to make that might be better spent getting rebar working and shipping "binary source" packages
21:01:44 [benoitc]: Noah: i agree

dch: dch to summarise approach for erlang & spidermonkey dependencies to dev@ for comment.

21:02:29 [benoitc]: dch: maybe we can version the wiki
21:02:36 [benoitc]: ie install/1.2.1/ ...
21:02:43 [benoitc]: on 1.3 copy and eventually change
21:02:50 [dch]: benoitc: I actually think it would be better in docs/.rst files in github.
21:02:58 [dch]: erm asf git sorry.
21:03:07 [jan____]: dch: +1, but that won’t work for 1.2.x and 1.1.x
21:03:08 [dch]: and then link to 1.2.x/INSTALL.Unix for example.
21:03:20 [jan____]: so for these versioned wiki would be nice
21:03:23 [dch]: jan____: yes, those will still need something.
21:03:43 [dch]: I'll find a way to have our cake and eat it.
21:03:50 [jan____]: anyway, good action. next topic?
21:04:06 [dch]: none from me
21:04:07 [jan____]: (excellent discussion, too)
21:04:15 [Kxepal]: jan____: I can handle docs for 1.2.x / 1.1.x so where will be right articles for them
21:04:35 [dch]: thanks Humbedooh for all the botification work it feels very professional
21:04:36 [dch]: ASFBot
21:04:38 [Noah]: dch: agreed this should be in the actual docs
21:04:58 [jan____]: Kxepal: confer with dch maybe after the meeting?
21:04:59 [Noah]: dch: versioning will be taken care of for automatically
21:05:08 [Humbedooh]: dch: hold the thanks till it spits out a page for you :)
21:05:13 [dch]: Kxepal: excellent - thanks!
21:05:13 [Kxepal]: jan____: ok
21:05:20 [jan____]: Noah: but not for <= 1.2.x
21:05:35 [jan____]: so some work needs to be done nad Kxepal just volunteered
21:05:35 [Noah]: jan____: yep - well, in 12 months: who cares? :)
21:05:51 [jan____]: Noah: sure :)
21:06:13 [Noah]: (release cadence means in 12 months 1.3.x will be EOLed - for context for anyone else)
21:06:13 [dch]: MOAR TOPICS?
21:06:15 [Noah]: so actually 9 months
21:06:36 [benoitc]: jan____: what is the status of the CI ?
21:07:00 [jan____]: benoitc: http://wiki.apache.org/couchdb/CI
21:07:50 [benoitc]: this link is new for me sorry :/
21:08:35 [jan____]: benoitc: no worries, I only added this a week ago or so and didn’t publicise it, because we were busy with the CVE releases
21:08:43 [jan____]: so you only could know about it if you looked at wiki@c.a.o

CI

21:08:58 [jan____]: oopsn
21:08:59 [jan____]: :)

dch: jan announced http://wiki.apache.org/couchdb/CI which is just being soft launched and needs your help!

21:09:35 [benoitc]: jan____: so i understand this ais a wip but anything working right now ?
21:09:43 [benoitc]: i see travis is working
21:10:05 [jan____]: benoitc: this is unrelated to travis, but yes, this is working
21:10:22 [dch]: can the CI build slaves be delegated? e.g. can I run a couple nodes "here" and "there" ? I have a quantal in the cloud, and I can squeeze a few more next month when I upgrade RAM on my desktop. Windows + others for example.
21:10:35 [benoitc]: i meant jenkins
21:10:43 [jan____]: benoitc: https://dl.dropbox.com/u/82149/Screen%20Shot%202013-01-16%20at%2022.10.09%20.png
21:11:07 [jan____]: the few red and grey ones are intermittent errors. the freebsd 1.3.x & master are broken as reported on dev@
21:11:13 [jan____]: dch: totally can
21:11:28 [dch]: sweet, I created me an account and it 404d
21:11:52 [jan____]: dch: yeah, rnewsonr eported that as well, I need to investigate that
21:11:59 [dch]: ok, job to maybe next week when we are all in one place.
21:12:19 [benoitc]: jan____: i would be interrested by the config
21:12:21 [jan____]: I also created https://docs.google.com/spreadsheet/ccc?key=0AhESVUYnc_sQdHZ6OEVYc3hGNFVXUTZUYU9lLVNEeVE#gid=0 which tracks what source versions work with what OS?dependency combinations
21:12:26 [jan____]: dch: yea
21:12:33 [dch]: so if I google jenkins build slaves, I could probably set this up myself
21:12:44 [dch]: BTW jan____ nice, this is a huge step fwdds
21:12:49 [jan____]: benoitc: yup, you will be able to see it all soon
21:13:04 [benoitc]: cool
21:13:07 [Noah]: ACTION ^5s jan____
21:13:12 [jan____]: dch: I can help you get started once your login works
21:13:21 [dch]: we should have a jenkins party in berlin for a couple hours.
21:13:26 [Noah]: jan____: the plan is to move to ASF jenkins eventually right?
21:13:28 [dch]: nobody leaves the room until your OS builds.
21:13:33 [jan____]: my plan ist to give all committers access to this so we can tinker at will
21:13:34 [dch]: Noah: that would be the plan, yes.
21:13:34 [jan____]: heh
21:13:41 [jan____]: Noah: yes
21:13:41 [Noah]: cool
21:13:51 [jan____]: it is under roadmap on the wiki page
21:13:56 [benoitc]: dch: sorry but i will pass the openbsd case ;)
21:14:05 [Kxepal]: dch: could you share your founds? I have free server that could be used for this propose - currently it just in idle ):
21:14:07 [dch]: benoitc: maybe I can have a go, you already have erlang and stuff working, right?
21:14:28 [benoitc]: dch: i guess it can work, yes i built 1.3 yesterday
21:14:29 [dch]: Kxepal: sweet, we can start a thread on the list and work through it.
21:14:48 [benoitc]: not sure how jenkins will play with
21:14:48 [Kxepal]: dch: sounds good(:
21:15:13 [benoitc]: anyway off topic
21:15:34 [jan____]: cool, next topic
21:15:34 [dch]: any more topics? or do we have a wrap?

CouchDB Conf

21:16:11 [jan____]: EXCITED TO SEE YALL NEXT WEEK
21:16:48 [dch]: remember: bring some coffee, asynchronous eventually consistent international coffee swapping!
21:16:48 [jan____]: ok, EOT.
21:17:06 [Humbedooh]: meeting end :)
21:17:11 [jan____]: dch: heh, good call. I shall include that in the attendee email