You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by ASF IRC Services <as...@wilderness.apache.org> on 2013/10/02 16:01:07 UTC
Summary of IRC meeting in #couchdb-meeting, Wed Oct 2 13:01:16 2013
Members present: djc, deathbear, nslater, JasonSmith, garren, benoitc, dch, jan____, strmpnk
----------------
Meeting summary:
----------------
1. Preface
2. Fauxton deploy for 1.5
a. garren and deathbear to prepare compiled Fauxton in _utils/next (garren, 2)
3. plugins 1.5
4. node view server
5. Couchdb Conf Vancouver
a. everyone tell everyone about http://conf.couchdb.org (jan____, 5)
b. put a banner on the website for couchdb conf (nslater, 5)
c. jan____ has spoken to Yuriy about the banner (nslater, 5)
--------
Actions:
--------
- garren and deathbear to prepare compiled Fauxton in _utils/next (garren, 13:27:15)
- everyone tell everyone about http://conf.couchdb.org (jan____, 13:56:22)
- put a banner on the website for couchdb conf (nslater, 13:59:29)
IRC log follows:
# 1. Preface #
13:01:45 [garren]: ASFBot: #topic Fauxton deploy for 1.5
# 2. Fauxton deploy for 1.5 #
13:02:24 [garren]: Ok for Fauxton release.
13:02:46 [garren]: We can either release Fauxton as a couchapp or we can do a compile and deploy it to share/www
13:03:10 [JasonSmith]: IMO I like how Futon builds as part of CouchDB
13:03:10 [garren]: I like the idea of the share/www and make it similar to the _util for futon.
13:03:24 [JasonSmith]: I personally, and for CouchDB hosting, I like to compile once and it is installed for all users
13:03:32 [JasonSmith]: garren: +1
13:03:40 [jan____]: garren: yeah, could we make it /_utils/next/ or something?
13:03:41 [garren]: JasonSmith: great, to compile Fauxton we would need node integrated into the couchdb build process.
13:04:20 [garren]: Or should one of the fauxton team members rather just compile beforehand and commit the compiled Fauxton into git?
13:04:51 [strmpnk]: +1 maybe we should have a _contrib/
13:05:37 [garren]: jan____: which is easier at this stage, compiling Fauxton in the build process or compile it beforehand?
13:05:39 [JasonSmith]: The way I always imagined it would work was ./configure would detect if you could build it (you have Node and maybe Grunt)
13:05:52 [JasonSmith]: Checking for Node.js.....ok
13:06:25 [garren]: JasonSmith: yeah that makes a lot of sense.
13:06:40 [garren]: who is the most capable bash-fu expert to help us with that?
13:06:47 [strmpnk]: I don't see why the artifacts should be committed.
13:06:47 [JasonSmith]: To me the thing I am not sure about is, npm installs at build time? I kind of don't personally like that
13:06:57 [jan____]: garren: either is possible, I think doing it as part of the build (like Jason says) makes the most sense, but it would mean some autofoo work needing to be done
13:07:02 [JasonSmith]: to me your npm packages should be a build-time dependency, like libicu or libmozjs
13:07:43 [JasonSmith]: Correct me if I'm wrong, but I really want to roll it out on Iris Couch and then overnight anybody can just try it out on their account
13:07:50 [jan____]: nslater to the rescue!
13:07:57 [garren]: JasonSmith: that would be great.
13:08:29 [jan____]: garren: can you sum up the question for nslater ?
13:09:01 [garren]: nslater: we trying to find the best way of deploying Fauxton for the next release. Should we commit the compiled artifacts of Fauxton into git or..
13:09:31 [garren]: should the build process do all that for us. Bearing in mind that we would then require node plus some npm packages as dependancies of Couchdb.
13:10:09 [garren]: It might be easier for this first release just to commit the compiled artifacts and later we look to integrate Fauxton into the build process.
13:10:49 [nslater]: "compiled"?
13:11:40 [garren]: nslater: We compile all the css, html templates and javascript and compile it into 3 files. Instead of the 50 or so files we have in development.
13:12:09 [nslater]: i think we should do it in make
13:12:18 [nslater]: note that this doesn't introduce a user dependancy on node
13:12:42 [nslater]: we could do it so that we ship the pre-compiled files along with the source
13:12:47 [garren]: nslater: could you explain a little more.
13:12:56 [nslater]: sure
13:13:28 [nslater]: in autotools it is possible to set it up so that during the "make dist" step of preparing the release tarball, some targets are built from the sources, and shipped along with the rest of the source, so that end users don't need to remake them
13:13:38 [nslater]: the manpages are one example of this (we can't expect users to have help2man installed)
13:13:44 [nslater]: the entire docs are another example
13:13:51 [deathbear]: hi :)
13:14:00 [garren]: hey deathbear.
13:14:38 [dch]: hey, late but made it
13:14:38 [garren]: nslater: that sounds good. Would that mean that the release manager would then be the only one needing the node dependancies?
13:14:45 [garren]: hey dch
13:14:54 [nslater]: garren: yes. or anyone trying to built from a git checkout
13:15:07 [nslater]: but if you're trying to build from a git checkout then you need everything else too
13:15:17 [garren]: ok great.
13:15:19 [nslater]: i am talking autotools, autoconf, help2man, sphinx, etc, etc
13:15:33 [garren]: nslater: would you have time to help us set this up in make?
13:15:34 [nslater]: we call these developer dependancies in the root doc files
13:15:55 [nslater]: garren: how much help do you folks need? are you comfortable setting up the default targets?
13:16:11 [nslater]: (which i could then tweak)
13:16:19 [nslater]: or do you need help with the whole thing?
13:16:35 [garren]: nslater: to be honest I'm rubbish with make. I could take a look. Our whole build process is run via grunt which is similar to make.
13:16:51 [jan____]: I’m happy to land a hand, too, but I will need some guidance
13:17:02 [nslater]: don't worry about it. i am happy to pair with garren on it. it sounds simple enough
13:17:07 [garren]: So all we would need to do is possibly do a check that node is installed, install npm dependancies and run grunt release task.
13:17:07 [nslater]: but thanks for the offer
13:17:18 [nslater]: garren, we wouldn't install npm stuff from make
13:17:29 [nslater]: we'd just bail out of configure unless the modules were detected
13:17:38 [garren]: ok great.
13:17:53 [nslater]: jan____ corrects me on this
13:17:54 [JasonSmith]: To me the most complex and error-prone part is the rather large npm install
13:17:55 [garren]: nslater can I follow up with you after this meeting and we can set a time we both around in the next 24 hrs our so to do this.
13:17:55 [nslater]: but we'll see when we get to it
13:18:07 [nslater]: next 24 hours? woo jeez
13:18:07 [deathbear]: hi, we have a make file for deploying
13:18:07 [deathbear]: if that helps
13:18:30 [nslater]: what is "grunt" and do we need to continue using it?
13:18:39 [jan____]: garren: deathbear: a broader question before we set times, is Fauxton ready to be shown off in 1.5.0?
13:18:48 [garren]: deathbear: that could help. Maybe you and I can take a stab at this today and then get nslater and jan____ to check it and apply any tweaks.
13:18:55 [deathbear]: I think it is, as experimental
13:19:03 [garren]: yeah definitely as experimental.
13:19:10 [nslater]: when are we pulling the trigger on 1.5.0?
13:19:11 [deathbear]: we've been working really hard on it since the redesign
13:19:33 [jan____]: nslater: grunt is a make for JS projects. we definitely want to keep using it
13:19:34 [JasonSmith]: nslater: grunt is a build tool, to a first approximation it is Node.js's make
13:19:41 [jan____]: nslater: djc wants to cut in ~24 hrs.
13:19:49 [nslater]: i am wary of including a build tool inside a build tool
13:19:50 [garren]: nslater: djc sent an email saying he is cutting the release in the next 24 hrs or so.
13:19:55 [nslater]: but i guess we did it for sphinx
13:20:03 [nslater]: jan____: okay then fauxton isn't going to go in
13:20:17 [jan____]: nslater: why not?
13:20:24 [nslater]: because i can't commit to getting this working in 24 hours
13:20:42 [jan____]: tomorrow is a holiday in .de ;)
13:20:49 [garren]: nslater: can we not rather do a precompiled artifact for this release? And then after 1.5 integrat into the build procedure
13:20:57 [jan____]: I can give it a shot.
13:20:58 [JasonSmith]: nslater: This is what I was saying earlier. I would say call Grunt a build dpeendnecy
13:21:06 [jan____]: garren: that’s a decent shortcut
13:21:08 [JasonSmith]: so you need Grunt the same way you need libicu-dev
13:21:13 [nslater]: jan____: disagree
13:21:19 [jan____]: JasonSmith: nslater wasn’t around then
13:21:28 [nslater]: i think it would run afoul of asf principals
13:21:44 [jan____]: which one?
13:22:07 [djc]: (sorry I'm late)
13:22:15 [nslater]: our source releases should be source releases. they should contain everything you need to modify and run the product. i don't think we're allowed, and i don't think we should, ship compiled files
13:22:53 [garren]: nslater: when we talk compiled files its just a html file, a javascript file, a css file, a image file and 1 font file.
13:23:00 [jan____]: our docs are compiled
13:23:08 [nslater]: jan____: but we also ship the source for them with the compilation
13:23:24 [jan____]: we can also ship the fauxton source
13:23:33 [garren]: yes
13:23:42 [nslater]: this seems very 11th hour
13:23:49 [jan____]: plus, it is a preview, not a final release, so I think we have some leeway for shortcuts
13:23:56 [nslater]: part of the rolling release schedule is that we don't panic about this stuff
13:23:59 [djc]: I think shipping source + "compiled" is fine
13:24:05 [jan____]: nslater: I think this is a simple issue.
13:24:05 [nslater]: they'll be another release in a month
13:24:06 [jan____]: nobody panics
13:24:08 [nslater]: jan____: i don't feel comfortable doing this
13:24:20 [nslater]: and i would prefer about 1w to work on the build system for it
13:24:44 [nslater]: and even then, i would prefer a bit longer, because i would have to stop working on everything else couchdb related
13:24:46 [nslater]: and i have some other pressing items that need my attention
13:24:54 [jan____]: src/fauxton/README.md explains how to build from source, and we also ship share/www/next/ (or whatever) with the compiled version of fauxton. End of story
13:25:08 [jan____]: then let’s not integrate that into hte build today but ship a compiled version
13:25:33 [nslater]: src/fauxton/ with instructions, and a compiled share/www/next is not ideal, but i agree it doesn't violate our principals
13:25:40 [garren]: awesome.
13:25:48 [deathbear]: :)
13:26:03 [jan____]: I agree it is not ideal, but it would allow us to ship a fauxton preview tomorrow :)
13:26:05 [nslater]: i would like to work on it so that in the next release we have it properly wired up to the build system
13:26:11 [jan____]: plus, it is not a dirty hack
13:26:18 [garren]: deathbear and I can work on getting fauxton working on _utils/next url.
13:26:26 [nslater]: (With garren or deathbear or whomever)
13:26:34 [deathbear]: in the next release fauxton will be even more awesome.
13:26:43 [jan____]: yeah, I consider it a blocker for a proper fauxton release that it is integrated into the build system
13:26:45 [garren]: nslater: I would definintely be happy to help integrate into the build tools. I do think thats the best option long term.
13:26:50 [nslater]: okay cool
13:27:07 [djc]: consensus \o/
13:27:15 [garren]: #action garren and deathbear to prepare compiled Fauxton in _utils/next
13:27:29 [garren]: everyone happy ready for the next topic?
13:27:29 [deathbear]: woo
13:27:38 [djc]: bikeshedding: does _utils-ng/ or something make more sense?
13:27:38 [jan____]: ^5
13:27:54 [deathbear]: ^5
13:27:56 [jan____]: djc: literally don’t care
# 3. plugins 1.5 #
13:28:24 [nslater]: wait wait
13:28:33 [nslater]: is _utils-nx the new X-feature?
13:28:35 [nslater]: *_utils-ng
13:28:48 [nslater]: i.e. we're not going to be lumbered with this url choice are we?
13:29:02 [djc]: nslater: no
13:29:19 [djc]: just while it's experimental
13:29:34 [garren]: djc yea I agree.
13:30:05 [dch]: ACTION then call it _experimental and make it crystal clear. But as djc said "don't care" lets pick one.
13:30:29 [garren]: dch: I can send an email with suggestions and people can vote on one?
13:30:52 [JasonSmith]: yeah xylophone
13:30:52 [jan____]: hell no, just pick one
13:30:55 [djc]: xylophone
13:30:59 [dch]: lets not, pick one now.
13:31:08 [dch]: ding ding
13:31:15 [garren]: ok we will pick one.
13:31:23 [garren]: Okay next topic?
13:31:24 [djc]: yeah
13:31:32 [jan____]: aye
13:31:32 [garren]: JasonSmith: can you start up off on plugins for 1.5
13:31:32 [djc]: I think jan____ killed plugins for 1.5
13:31:47 [JasonSmith]: really?
13:32:03 [jan____]: soo, I wanted to spend a minute today to see what’s missing for plugins
13:32:05 [jan____]: I haven’t managed to do that yet
13:32:19 [djc]: JasonSmith: if you have round tuits to make it happen, I'm all for it!
13:32:22 [jan____]: I think I can frame it shippable, but I only will know later today
13:32:27 [djc]: just that jan____ didn't have time, I think
13:32:42 [jan____]: yeah, I found some time under the carpet
13:32:49 [jan____]: but not before the meeting
13:32:59 [JasonSmith]: jan____: I think I am happy with plugins, but just my definition of "plugins" may be different from yours
13:32:59 [jan____]: I will update the 1.5 thread on dev@ later today
13:33:38 [jan____]: JasonSmith: well, you rip out /_plugins and /_utils/plugins.html
13:33:40 [jan____]: which is all that I did
13:34:10 [jan____]: e.g the binary installer & one-click-install-registry page
13:34:33 [jan____]: the rest were just minimal changes in how CouchDB operates, but that’s all that you neede
13:34:33 [jan____]: d
13:34:57 [benoitc]: one thing to consider is how the pluging would work in a system where you do live upgrade of a node
13:35:12 [jan____]: so far the things I am not too happy about are the barren look of /_utils/plugins.html / same for the fauxton version
13:35:13 [benoitc]: they won't be part of the release which may be problematic
13:35:28 [jan____]: benoitc: yeah, totally, but for this release that is out of scope and won’t work
13:35:53 [jan____]: e.g. if you do live upgrades you will want to make the plugins you need part of your source distribution
13:36:15 [benoitc]: well if we ship it , we make a promise to the user that it will stay for a long time
13:36:38 [benoitc]: so we need to make sure it can really exists with a release system
13:36:40 [jan____]: benoitc: no, we ship it as “this will change a lot”
13:36:53 [jan____]: as a preview, this isn’t a commitment yet
13:37:44 [benoitc]: in the head of people it can be
13:38:00 [nslater]: well then we need to properly set expectations
13:38:14 [jan____]: yeah, but we can’t win that. we need to embrace experimntal features
13:38:15 [JasonSmith]: I am happy regrading plugins
13:38:17 [JasonSmith]: regarding plugins
13:38:22 [benoitc]: why would they care to try a feature that could change a lot tomorrow
13:38:30 [JasonSmith]: 1.5 as-is, I myself am happy
13:38:30 [benoitc]: this is not that i am happy or not
13:38:38 [benoitc]: i like the idea of having plugins
13:38:54 [djc]: benoitc: if we document it clearly as changing, then there's nothing else we can do
13:38:59 [benoitc]: but i wonder how it can really work with an erlang program
13:39:08 [djc]: if it changes out from under people, it's their fault for relying on it
13:39:24 [djc]: and experimental stuff leads to experimentation, which is good
13:39:31 [jan____]: benoitc: I don’t feel comfortable shipping plugins as a long-term feature without having run a test version through a umber of users
13:39:31 [djc]: we need more ideas about what/how to work this stuff
13:39:40 [jan____]: regardless of how long we work on it unreleased
13:39:58 [strmpnk]: benoitc: I agree on the worry about how it might cause problems but this is why it should be released as experimental, so those his are explored.
13:40:55 [benoitc]: i would expect they land in master for a release or two before going directly in a release anyway
13:41:09 [benoitc]: at least I wouldn't expect them for 1.5
13:41:18 [djc]: benoitc: that's not how we work anymore, master means releasable
13:41:33 [benoitc]: yes
13:41:33 [benoitc]: so it is not in master
13:41:55 [djc]: yes, but there's also no "bake-time" on master
13:42:09 [jan____]: benoitc: I can merge it into master within the next 24 hours and then it is relesable
13:42:09 [djc]: they bake in releases, need users to mature anyway
13:42:18 [jan____]: the question is are we happy with the current state
13:42:43 [jan____]: I think I can be happy with the current + minor fixes state
13:42:49 [djc]: I have no answer to that, but am happy to defer to Jan & Jason
13:43:35 [jan____]: right, again, will look into this after the meeting, but before tonight
13:43:55 [benoitc]: i don't see the point to release a thing in 24h that have never landed in master for a while.
13:44:18 [benoitc]: this is not how a quality software should work imo but this is out of topic
13:44:33 [jan____]: benoitc: we don’t do baking in master anymore. branches are ready to ship or they are not
13:44:47 [djc]: okay, I'm ready for the next topic
13:44:55 [JasonSmith]: Ready
13:44:55 [garren]: great
13:44:56 [jan____]: benoitc: and especially with new stuff, we mark it as experimental, so people can play with it without expecting it to all work
# 4. node view server #
13:45:18 [garren]: jan____: Can you start us off or is it JasonSmith?
13:45:18 [jan____]: I also don’t quite see why we have to discuss the how of releases that we had agreed upon again
13:45:20 [jan____]: ready.
13:45:28 [JasonSmith]: I am done, plugins look good
13:45:33 [jan____]: I got it
13:45:34 [JasonSmith]: fdmanana says hi
13:46:16 [jan____]: as far as I am concerned the nodejs viewserver works well enough to ship as an experimental release. There are some obvious todos, but they can be done later.
13:46:29 [benoitc]: i don't remember to agree on such thing but anyway it wasn't the point
13:46:36 [jan____]: the goal of the release is to get this into people’s hands so they can play and try to break it
13:46:36 [benoitc]: i was speaking on a technical level.
13:46:52 [benoitc]: let's go to the other topic
13:47:00 [garren]: jan____: is there documentation on how to get it up and running. Eg I install 1.5 how do I activate the nodejs view server?
13:47:30 [djc]: the nodejs view server doesn't add any dependencies for non-users, right?
13:48:14 [jan____]: djc: correct
13:48:39 [jan____]: garren: one sec
13:48:46 [garren]: sure
13:49:24 [JasonSmith]: jan____: +1
13:49:40 [jan____]: garren: https://github.com/apache/couchdb/blob/1894-feature-experimental-nodejs-couchjs/share/doc/src/experimental.rst
13:49:49 [jan____]: e.g. this would show up on docs.couchdb.org
13:50:32 [djc]: I like the looks of this
13:50:42 [garren]: jan____: perfect thanks.
13:51:02 [jan____]: :D I made a poinnt of adding docs to get djc approval :D
13:51:33 [jan____]: it is a little bare-bones, but we can update the doc on the go
13:51:33 [djc]: and you shall have it
13:51:40 [jan____]: (love the new docs immediate publish setup)
13:51:55 [garren]: Excellent.
13:52:10 [jan____]: nice
13:52:17 [jan____]: djc: I’ll get that merged in time
13:52:40 [garren]: Great any other topics someone wants to add?
13:53:02 [jan____]: CouchDB Conf Vancouver
13:53:17 [deathbear]: who is going?
# 5. Couchdb Conf Vancouver #
13:53:24 [jan____]: <
13:53:26 [deathbear]: I am still thinking about it
13:53:54 [jan____]: deathbear: would be nice to meet you finally :)
13:53:54 [nslater]: Yuriy should post an announcement about the tickets to both public couchdb lists
13:53:54 [garren]: Unfortunately I can't make it.
13:54:25 [nslater]: ACTION wished he flew
13:54:27 [jan____]: It would also be cool if everyone here could use their social media outreach to get people aware of it
13:54:32 [benoitc]: i probably can't make it happen. my assistant forgot to book the flight
13:54:32 [jan____]: s/get/make
13:54:41 [deathbear]: nslater are you scared of planes? cause ME TOO.
13:54:41 [benoitc]: and cascadiajs don't interrest me at all
13:54:48 [jan____]: benoitc: Doh :(
13:54:55 [nslater]: idea: hook up skype to a projector that covers one of the walls. and i can have an omni-tele-presence
13:55:04 [nslater]: silently watching and judging you all
13:55:05 [jan____]: heh, cascadia is optional :)
13:55:20 [jan____]: nslater: sounds good :)
13:55:27 [nslater]: benoitc: time to get a new assistant! ;)
13:55:36 [benoitc]: yup but was trying myself to still come even if a flight is 1700 euros
13:55:37 [nslater]: deathbear: yes
13:55:49 [jan____]: #task everyone tell everyone about http://conf.couchdb.org
13:55:58 [nslater]: is it not #action ?
13:56:07 [jan____]: benoitc: get in touch if price becomes an issue, we might be able to help
13:56:22 [jan____]: #action everyone tell everyone about http://conf.couchdb.org
13:56:37 [benoitc]: yuup was about to do it thx
13:56:45 [benoitc]: can we have an ad on the site ?
13:56:54 [benoitc]: like banner or sort of ?
13:56:59 [jan____]: yeah great idea
13:57:09 [nslater]: +1
13:57:15 [jan____]: benoitc: excellent idea, I’mma look after that
13:57:30 [garren]: Any idea who could do that for us?
13:57:52 [jan____]: garren: I pinged Yuriy in email
13:58:00 [nslater]: do we have any designers in da house?
13:58:14 [garren]: cool.
13:58:59 [nslater]: ait
13:59:00 [nslater]: wait
13:59:08 [nslater]: you've pinged yuriy about the website banner?
13:59:22 [jan____]: yes
13:59:29 [nslater]: #action put a banner on the website for couchdb conf
13:59:38 [nslater]: #info jan____ has spoken to Yuriy about the banner
13:59:38 [nslater]: okie dokie
13:59:39 [nslater]: thx
13:59:45 [jan____]: :)
13:59:56 [garren]: ok great.
14:00:01 [nslater]: me and jan____ are in the same room together. this adds a new dimension to the meeting
14:00:02 [garren]: ASFBot: meeting end
Re: Summary of IRC meeting in #couchdb-meeting, Wed Oct 2 13:01:16 2013
Posted by Noah Slater <ns...@apache.org>.
+1
On 2 October 2013 19:48, Jan Lehnardt <ja...@apache.org> wrote:
>
> On Oct 2, 2013, at 16:05 , Jan Lehnardt <ja...@apache.org> wrote:
>
> >
> > On Oct 2, 2013, at 16:01 , ASF IRC Services <
> asfbot@wilderness.apache.org> wrote:
> >
> >> Members present: djc, deathbear, nslater, JasonSmith, garren, benoitc,
> dch, jan____, strmpnk
> >>
> >> ----------------
> >> Meeting summary:
> >> ----------------
> >>
> >> 1. Preface
> >>
> >> 2. Fauxton deploy for 1.5
> >> a. garren and deathbear to prepare compiled Fauxton in _utils/next
> (garren, 2)
> >>
> >> 3. plugins 1.5
> >>
> >> 4. node view server
> >>
> >> 5. Couchdb Conf Vancouver
> >> a. everyone tell everyone about http://conf.couchdb.org (jan____, 5)
> >> b. put a banner on the website for couchdb conf (nslater, 5)
> >> c. jan____ has spoken to Yuriy about the banner (nslater, 5)
> >>
> >>
> >> --------
> >> Actions:
> >> --------
> >> - garren and deathbear to prepare compiled Fauxton in _utils/next
> (garren, 13:27:15)
> >> - everyone tell everyone about http://conf.couchdb.org (jan____,
> 13:56:22)
> >> - put a banner on the website for couchdb conf (nslater, 13:59:29)
> >
> > missed this one in the meeting:
> > - jan to report on plugins state before the end of the day
>
> And here we go:
>
> I think it is still a bit raw, especially my idea of having users install
> plugins with one click. It all works and the hooks we have in CouchDB do
> all what they are supposed to, but I’d not feel right to start advertising
> that CouchDB has plugins now.
>
> However, I’d like to get at least the mechanics out, so we and outside
> devs get to play with it. I know at least two that are going to be using
> this and I am sure we can make a nice install procedure for GeoCouch that
> isn’t the current custom compilation. I think that is already a win and
> worth shipping.
>
> What I did on the branch for now is not link the plugin pages from Futon
> and Fauxton, so we don’t confuse users. But the pages are still there for
> people to play with and to hack around.
>
> The main code changes are:
>
> - addition of src/couch_plugins that doesn’t interfere with anything.
> - addition of loading config files as part of bin/couchdb.tpl.in that’s a
> NOP in the default case.
> - addition of a Futon and a Fauxton page to install plugins with one
> click, not linked to from anywhere yet.
>
> I say this is un-intrusive enough to let us get out into the field without
> much risk.
>
> How does everyone feel about getting this in?
>
> Best
> Jan
> --
>
> >
> >>
> >> IRC log follows:
> >>
> >>
> >> # 1. Preface #
> >> 13:01:45 [garren]: ASFBot: #topic Fauxton deploy for 1.5
> >>
> >>
> >> # 2. Fauxton deploy for 1.5 #
> >> 13:02:24 [garren]: Ok for Fauxton release.
> >> 13:02:46 [garren]: We can either release Fauxton as a couchapp or we
> can do a compile and deploy it to share/www
> >> 13:03:10 [JasonSmith]: IMO I like how Futon builds as part of CouchDB
> >> 13:03:10 [garren]: I like the idea of the share/www and make it similar
> to the _util for futon.
> >> 13:03:24 [JasonSmith]: I personally, and for CouchDB hosting, I like to
> compile once and it is installed for all users
> >> 13:03:32 [JasonSmith]: garren: +1
> >> 13:03:40 [jan____]: garren: yeah, could we make it /_utils/next/ or
> something?
> >> 13:03:41 [garren]: JasonSmith: great, to compile Fauxton we would need
> node integrated into the couchdb build process.
> >> 13:04:20 [garren]: Or should one of the fauxton team members rather
> just compile beforehand and commit the compiled Fauxton into git?
> >> 13:04:51 [strmpnk]: +1 maybe we should have a _contrib/
> >> 13:05:37 [garren]: jan____: which is easier at this stage, compiling
> Fauxton in the build process or compile it beforehand?
> >> 13:05:39 [JasonSmith]: The way I always imagined it would work was
> ./configure would detect if you could build it (you have Node and maybe
> Grunt)
> >> 13:05:52 [JasonSmith]: Checking for Node.js.....ok
> >> 13:06:25 [garren]: JasonSmith: yeah that makes a lot of sense.
> >> 13:06:40 [garren]: who is the most capable bash-fu expert to help us
> with that?
> >> 13:06:47 [strmpnk]: I don't see why the artifacts should be committed.
> >> 13:06:47 [JasonSmith]: To me the thing I am not sure about is, npm
> installs at build time? I kind of don't personally like that
> >> 13:06:57 [jan____]: garren: either is possible, I think doing it as
> part of the build (like Jason says) makes the most sense, but it would mean
> some autofoo work needing to be done
> >> 13:07:02 [JasonSmith]: to me your npm packages should be a build-time
> dependency, like libicu or libmozjs
> >> 13:07:43 [JasonSmith]: Correct me if I'm wrong, but I really want to
> roll it out on Iris Couch and then overnight anybody can just try it out on
> their account
> >> 13:07:50 [jan____]: nslater to the rescue!
> >> 13:07:57 [garren]: JasonSmith: that would be great.
> >> 13:08:29 [jan____]: garren: can you sum up the question for nslater ?
> >> 13:09:01 [garren]: nslater: we trying to find the best way of deploying
> Fauxton for the next release. Should we commit the compiled artifacts of
> Fauxton into git or..
> >> 13:09:31 [garren]: should the build process do all that for us. Bearing
> in mind that we would then require node plus some npm packages as
> dependancies of Couchdb.
> >> 13:10:09 [garren]: It might be easier for this first release just to
> commit the compiled artifacts and later we look to integrate Fauxton into
> the build process.
> >> 13:10:49 [nslater]: "compiled"?
> >> 13:11:40 [garren]: nslater: We compile all the css, html templates and
> javascript and compile it into 3 files. Instead of the 50 or so files we
> have in development.
> >> 13:12:09 [nslater]: i think we should do it in make
> >> 13:12:18 [nslater]: note that this doesn't introduce a user dependancy
> on node
> >> 13:12:42 [nslater]: we could do it so that we ship the pre-compiled
> files along with the source
> >> 13:12:47 [garren]: nslater: could you explain a little more.
> >> 13:12:56 [nslater]: sure
> >> 13:13:28 [nslater]: in autotools it is possible to set it up so that
> during the "make dist" step of preparing the release tarball, some targets
> are built from the sources, and shipped along with the rest of the source,
> so that end users don't need to remake them
> >> 13:13:38 [nslater]: the manpages are one example of this (we can't
> expect users to have help2man installed)
> >> 13:13:44 [nslater]: the entire docs are another example
> >> 13:13:51 [deathbear]: hi :)
> >> 13:14:00 [garren]: hey deathbear.
> >> 13:14:38 [dch]: hey, late but made it
> >> 13:14:38 [garren]: nslater: that sounds good. Would that mean that the
> release manager would then be the only one needing the node dependancies?
> >> 13:14:45 [garren]: hey dch
> >> 13:14:54 [nslater]: garren: yes. or anyone trying to built from a git
> checkout
> >> 13:15:07 [nslater]: but if you're trying to build from a git checkout
> then you need everything else too
> >> 13:15:17 [garren]: ok great.
> >> 13:15:19 [nslater]: i am talking autotools, autoconf, help2man, sphinx,
> etc, etc
> >> 13:15:33 [garren]: nslater: would you have time to help us set this up
> in make?
> >> 13:15:34 [nslater]: we call these developer dependancies in the root
> doc files
> >> 13:15:55 [nslater]: garren: how much help do you folks need? are you
> comfortable setting up the default targets?
> >> 13:16:11 [nslater]: (which i could then tweak)
> >> 13:16:19 [nslater]: or do you need help with the whole thing?
> >> 13:16:35 [garren]: nslater: to be honest I'm rubbish with make. I could
> take a look. Our whole build process is run via grunt which is similar to
> make.
> >> 13:16:51 [jan____]: I’m happy to land a hand, too, but I will need some
> guidance
> >> 13:17:02 [nslater]: don't worry about it. i am happy to pair with
> garren on it. it sounds simple enough
> >> 13:17:07 [garren]: So all we would need to do is possibly do a check
> that node is installed, install npm dependancies and run grunt release task.
> >> 13:17:07 [nslater]: but thanks for the offer
> >> 13:17:18 [nslater]: garren, we wouldn't install npm stuff from make
> >> 13:17:29 [nslater]: we'd just bail out of configure unless the modules
> were detected
> >> 13:17:38 [garren]: ok great.
> >> 13:17:53 [nslater]: jan____ corrects me on this
> >> 13:17:54 [JasonSmith]: To me the most complex and error-prone part is
> the rather large npm install
> >> 13:17:55 [garren]: nslater can I follow up with you after this meeting
> and we can set a time we both around in the next 24 hrs our so to do this.
> >> 13:17:55 [nslater]: but we'll see when we get to it
> >> 13:18:07 [nslater]: next 24 hours? woo jeez
> >> 13:18:07 [deathbear]: hi, we have a make file for deploying
> >> 13:18:07 [deathbear]: if that helps
> >> 13:18:30 [nslater]: what is "grunt" and do we need to continue using it?
> >> 13:18:39 [jan____]: garren: deathbear: a broader question before we set
> times, is Fauxton ready to be shown off in 1.5.0?
> >> 13:18:48 [garren]: deathbear: that could help. Maybe you and I can take
> a stab at this today and then get nslater and jan____ to check it and apply
> any tweaks.
> >> 13:18:55 [deathbear]: I think it is, as experimental
> >> 13:19:03 [garren]: yeah definitely as experimental.
> >> 13:19:10 [nslater]: when are we pulling the trigger on 1.5.0?
> >> 13:19:11 [deathbear]: we've been working really hard on it since the
> redesign
> >> 13:19:33 [jan____]: nslater: grunt is a make for JS projects. we
> definitely want to keep using it
> >> 13:19:34 [JasonSmith]: nslater: grunt is a build tool, to a first
> approximation it is Node.js's make
> >> 13:19:41 [jan____]: nslater: djc wants to cut in ~24 hrs.
> >> 13:19:49 [nslater]: i am wary of including a build tool inside a build
> tool
> >> 13:19:50 [garren]: nslater: djc sent an email saying he is cutting the
> release in the next 24 hrs or so.
> >> 13:19:55 [nslater]: but i guess we did it for sphinx
> >> 13:20:03 [nslater]: jan____: okay then fauxton isn't going to go in
> >> 13:20:17 [jan____]: nslater: why not?
> >> 13:20:24 [nslater]: because i can't commit to getting this working in
> 24 hours
> >> 13:20:42 [jan____]: tomorrow is a holiday in .de ;)
> >> 13:20:49 [garren]: nslater: can we not rather do a precompiled artifact
> for this release? And then after 1.5 integrat into the build procedure
> >> 13:20:57 [jan____]: I can give it a shot.
> >> 13:20:58 [JasonSmith]: nslater: This is what I was saying earlier. I
> would say call Grunt a build dpeendnecy
> >> 13:21:06 [jan____]: garren: that’s a decent shortcut
> >> 13:21:08 [JasonSmith]: so you need Grunt the same way you need
> libicu-dev
> >> 13:21:13 [nslater]: jan____: disagree
> >> 13:21:19 [jan____]: JasonSmith: nslater wasn’t around then
> >> 13:21:28 [nslater]: i think it would run afoul of asf principals
> >> 13:21:44 [jan____]: which one?
> >> 13:22:07 [djc]: (sorry I'm late)
> >> 13:22:15 [nslater]: our source releases should be source releases. they
> should contain everything you need to modify and run the product. i don't
> think we're allowed, and i don't think we should, ship compiled files
> >> 13:22:53 [garren]: nslater: when we talk compiled files its just a html
> file, a javascript file, a css file, a image file and 1 font file.
> >> 13:23:00 [jan____]: our docs are compiled
> >> 13:23:08 [nslater]: jan____: but we also ship the source for them with
> the compilation
> >> 13:23:24 [jan____]: we can also ship the fauxton source
> >> 13:23:33 [garren]: yes
> >> 13:23:42 [nslater]: this seems very 11th hour
> >> 13:23:49 [jan____]: plus, it is a preview, not a final release, so I
> think we have some leeway for shortcuts
> >> 13:23:56 [nslater]: part of the rolling release schedule is that we
> don't panic about this stuff
> >> 13:23:59 [djc]: I think shipping source + "compiled" is fine
> >> 13:24:05 [jan____]: nslater: I think this is a simple issue.
> >> 13:24:05 [nslater]: they'll be another release in a month
> >> 13:24:06 [jan____]: nobody panics
> >> 13:24:08 [nslater]: jan____: i don't feel comfortable doing this
> >> 13:24:20 [nslater]: and i would prefer about 1w to work on the build
> system for it
> >> 13:24:44 [nslater]: and even then, i would prefer a bit longer, because
> i would have to stop working on everything else couchdb related
> >> 13:24:46 [nslater]: and i have some other pressing items that need my
> attention
> >> 13:24:54 [jan____]: src/fauxton/README.md explains how to build from
> source, and we also ship share/www/next/ (or whatever) with the compiled
> version of fauxton. End of story
> >> 13:25:08 [jan____]: then let’s not integrate that into hte build today
> but ship a compiled version
> >> 13:25:33 [nslater]: src/fauxton/ with instructions, and a compiled
> share/www/next is not ideal, but i agree it doesn't violate our principals
> >> 13:25:40 [garren]: awesome.
> >> 13:25:48 [deathbear]: :)
> >> 13:26:03 [jan____]: I agree it is not ideal, but it would allow us to
> ship a fauxton preview tomorrow :)
> >> 13:26:05 [nslater]: i would like to work on it so that in the next
> release we have it properly wired up to the build system
> >> 13:26:11 [jan____]: plus, it is not a dirty hack
> >> 13:26:18 [garren]: deathbear and I can work on getting fauxton working
> on _utils/next url.
> >> 13:26:26 [nslater]: (With garren or deathbear or whomever)
> >> 13:26:34 [deathbear]: in the next release fauxton will be even more
> awesome.
> >> 13:26:43 [jan____]: yeah, I consider it a blocker for a proper fauxton
> release that it is integrated into the build system
> >> 13:26:45 [garren]: nslater: I would definintely be happy to help
> integrate into the build tools. I do think thats the best option long term.
> >> 13:26:50 [nslater]: okay cool
> >> 13:27:07 [djc]: consensus \o/
> >> 13:27:15 [garren]: #action garren and deathbear to prepare compiled
> Fauxton in _utils/next
> >> 13:27:29 [garren]: everyone happy ready for the next topic?
> >> 13:27:29 [deathbear]: woo
> >> 13:27:38 [djc]: bikeshedding: does _utils-ng/ or something make more
> sense?
> >> 13:27:38 [jan____]: ^5
> >> 13:27:54 [deathbear]: ^5
> >> 13:27:56 [jan____]: djc: literally don’t care
> >>
> >>
> >> # 3. plugins 1.5 #
> >> 13:28:24 [nslater]: wait wait
> >> 13:28:33 [nslater]: is _utils-nx the new X-feature?
> >> 13:28:35 [nslater]: *_utils-ng
> >> 13:28:48 [nslater]: i.e. we're not going to be lumbered with this url
> choice are we?
> >> 13:29:02 [djc]: nslater: no
> >> 13:29:19 [djc]: just while it's experimental
> >> 13:29:34 [garren]: djc yea I agree.
> >> 13:30:05 [dch]: ACTION then call it _experimental and make it crystal
> clear. But as djc said "don't care" lets pick one.
> >> 13:30:29 [garren]: dch: I can send an email with suggestions and people
> can vote on one?
> >> 13:30:52 [JasonSmith]: yeah xylophone
> >> 13:30:52 [jan____]: hell no, just pick one
> >> 13:30:55 [djc]: xylophone
> >> 13:30:59 [dch]: lets not, pick one now.
> >> 13:31:08 [dch]: ding ding
> >> 13:31:15 [garren]: ok we will pick one.
> >> 13:31:23 [garren]: Okay next topic?
> >> 13:31:24 [djc]: yeah
> >> 13:31:32 [jan____]: aye
> >> 13:31:32 [garren]: JasonSmith: can you start up off on plugins for 1.5
> >> 13:31:32 [djc]: I think jan____ killed plugins for 1.5
> >> 13:31:47 [JasonSmith]: really?
> >> 13:32:03 [jan____]: soo, I wanted to spend a minute today to see what’s
> missing for plugins
> >> 13:32:05 [jan____]: I haven’t managed to do that yet
> >> 13:32:19 [djc]: JasonSmith: if you have round tuits to make it happen,
> I'm all for it!
> >> 13:32:22 [jan____]: I think I can frame it shippable, but I only will
> know later today
> >> 13:32:27 [djc]: just that jan____ didn't have time, I think
> >> 13:32:42 [jan____]: yeah, I found some time under the carpet
> >> 13:32:49 [jan____]: but not before the meeting
> >> 13:32:59 [JasonSmith]: jan____: I think I am happy with plugins, but
> just my definition of "plugins" may be different from yours
> >> 13:32:59 [jan____]: I will update the 1.5 thread on dev@ later today
> >> 13:33:38 [jan____]: JasonSmith: well, you rip out /_plugins and
> /_utils/plugins.html
> >> 13:33:40 [jan____]: which is all that I did
> >> 13:34:10 [jan____]: e.g the binary installer &
> one-click-install-registry page
> >> 13:34:33 [jan____]: the rest were just minimal changes in how CouchDB
> operates, but that’s all that you neede
> >> 13:34:33 [jan____]: d
> >> 13:34:57 [benoitc]: one thing to consider is how the pluging would work
> in a system where you do live upgrade of a node
> >> 13:35:12 [jan____]: so far the things I am not too happy about are the
> barren look of /_utils/plugins.html / same for the fauxton version
> >> 13:35:13 [benoitc]: they won't be part of the release which may be
> problematic
> >> 13:35:28 [jan____]: benoitc: yeah, totally, but for this release that
> is out of scope and won’t work
> >> 13:35:53 [jan____]: e.g. if you do live upgrades you will want to make
> the plugins you need part of your source distribution
> >> 13:36:15 [benoitc]: well if we ship it , we make a promise to the user
> that it will stay for a long time
> >> 13:36:38 [benoitc]: so we need to make sure it can really exists with a
> release system
> >> 13:36:40 [jan____]: benoitc: no, we ship it as “this will change a lot”
> >> 13:36:53 [jan____]: as a preview, this isn’t a commitment yet
> >> 13:37:44 [benoitc]: in the head of people it can be
> >> 13:38:00 [nslater]: well then we need to properly set expectations
> >> 13:38:14 [jan____]: yeah, but we can’t win that. we need to embrace
> experimntal features
> >> 13:38:15 [JasonSmith]: I am happy regrading plugins
> >> 13:38:17 [JasonSmith]: regarding plugins
> >> 13:38:22 [benoitc]: why would they care to try a feature that could
> change a lot tomorrow
> >> 13:38:30 [JasonSmith]: 1.5 as-is, I myself am happy
> >> 13:38:30 [benoitc]: this is not that i am happy or not
> >> 13:38:38 [benoitc]: i like the idea of having plugins
> >> 13:38:54 [djc]: benoitc: if we document it clearly as changing, then
> there's nothing else we can do
> >> 13:38:59 [benoitc]: but i wonder how it can really work with an erlang
> program
> >> 13:39:08 [djc]: if it changes out from under people, it's their fault
> for relying on it
> >> 13:39:24 [djc]: and experimental stuff leads to experimentation, which
> is good
> >> 13:39:31 [jan____]: benoitc: I don’t feel comfortable shipping plugins
> as a long-term feature without having run a test version through a umber of
> users
> >> 13:39:31 [djc]: we need more ideas about what/how to work this stuff
> >> 13:39:40 [jan____]: regardless of how long we work on it unreleased
> >> 13:39:58 [strmpnk]: benoitc: I agree on the worry about how it might
> cause problems but this is why it should be released as experimental, so
> those his are explored.
> >> 13:40:55 [benoitc]: i would expect they land in master for a release or
> two before going directly in a release anyway
> >> 13:41:09 [benoitc]: at least I wouldn't expect them for 1.5
> >> 13:41:18 [djc]: benoitc: that's not how we work anymore, master means
> releasable
> >> 13:41:33 [benoitc]: yes
> >> 13:41:33 [benoitc]: so it is not in master
> >> 13:41:55 [djc]: yes, but there's also no "bake-time" on master
> >> 13:42:09 [jan____]: benoitc: I can merge it into master within the next
> 24 hours and then it is relesable
> >> 13:42:09 [djc]: they bake in releases, need users to mature anyway
> >> 13:42:18 [jan____]: the question is are we happy with the current state
> >> 13:42:43 [jan____]: I think I can be happy with the current + minor
> fixes state
> >> 13:42:49 [djc]: I have no answer to that, but am happy to defer to Jan
> & Jason
> >> 13:43:35 [jan____]: right, again, will look into this after the
> meeting, but before tonight
> >> 13:43:55 [benoitc]: i don't see the point to release a thing in 24h
> that have never landed in master for a while.
> >> 13:44:18 [benoitc]: this is not how a quality software should work imo
> but this is out of topic
> >> 13:44:33 [jan____]: benoitc: we don’t do baking in master anymore.
> branches are ready to ship or they are not
> >> 13:44:47 [djc]: okay, I'm ready for the next topic
> >> 13:44:55 [JasonSmith]: Ready
> >> 13:44:55 [garren]: great
> >> 13:44:56 [jan____]: benoitc: and especially with new stuff, we mark it
> as experimental, so people can play with it without expecting it to all work
> >>
> >>
> >> # 4. node view server #
> >> 13:45:18 [garren]: jan____: Can you start us off or is it JasonSmith?
> >> 13:45:18 [jan____]: I also don’t quite see why we have to discuss the
> how of releases that we had agreed upon again
> >> 13:45:20 [jan____]: ready.
> >> 13:45:28 [JasonSmith]: I am done, plugins look good
> >> 13:45:33 [jan____]: I got it
> >> 13:45:34 [JasonSmith]: fdmanana says hi
> >> 13:46:16 [jan____]: as far as I am concerned the nodejs viewserver
> works well enough to ship as an experimental release. There are some
> obvious todos, but they can be done later.
> >> 13:46:29 [benoitc]: i don't remember to agree on such thing but anyway
> it wasn't the point
> >> 13:46:36 [jan____]: the goal of the release is to get this into
> people’s hands so they can play and try to break it
> >> 13:46:36 [benoitc]: i was speaking on a technical level.
> >> 13:46:52 [benoitc]: let's go to the other topic
> >> 13:47:00 [garren]: jan____: is there documentation on how to get it up
> and running. Eg I install 1.5 how do I activate the nodejs view server?
> >> 13:47:30 [djc]: the nodejs view server doesn't add any dependencies for
> non-users, right?
> >> 13:48:14 [jan____]: djc: correct
> >> 13:48:39 [jan____]: garren: one sec
> >> 13:48:46 [garren]: sure
> >> 13:49:24 [JasonSmith]: jan____: +1
> >> 13:49:40 [jan____]: garren:
> https://github.com/apache/couchdb/blob/1894-feature-experimental-nodejs-couchjs/share/doc/src/experimental.rst
> >> 13:49:49 [jan____]: e.g. this would show up on docs.couchdb.org
> >> 13:50:32 [djc]: I like the looks of this
> >> 13:50:42 [garren]: jan____: perfect thanks.
> >> 13:51:02 [jan____]: :D I made a poinnt of adding docs to get djc
> approval :D
> >> 13:51:33 [jan____]: it is a little bare-bones, but we can update the
> doc on the go
> >> 13:51:33 [djc]: and you shall have it
> >> 13:51:40 [jan____]: (love the new docs immediate publish setup)
> >> 13:51:55 [garren]: Excellent.
> >> 13:52:10 [jan____]: nice
> >> 13:52:17 [jan____]: djc: I’ll get that merged in time
> >> 13:52:40 [garren]: Great any other topics someone wants to add?
> >> 13:53:02 [jan____]: CouchDB Conf Vancouver
> >> 13:53:17 [deathbear]: who is going?
> >>
> >>
> >> # 5. Couchdb Conf Vancouver #
> >> 13:53:24 [jan____]: <
> >> 13:53:26 [deathbear]: I am still thinking about it
> >> 13:53:54 [jan____]: deathbear: would be nice to meet you finally :)
> >> 13:53:54 [nslater]: Yuriy should post an announcement about the tickets
> to both public couchdb lists
> >> 13:53:54 [garren]: Unfortunately I can't make it.
> >> 13:54:25 [nslater]: ACTION wished he flew
> >> 13:54:27 [jan____]: It would also be cool if everyone here could use
> their social media outreach to get people aware of it
> >> 13:54:32 [benoitc]: i probably can't make it happen. my assistant
> forgot to book the flight
> >> 13:54:32 [jan____]: s/get/make
> >> 13:54:41 [deathbear]: nslater are you scared of planes? cause ME TOO.
> >> 13:54:41 [benoitc]: and cascadiajs don't interrest me at all
> >> 13:54:48 [jan____]: benoitc: Doh :(
> >> 13:54:55 [nslater]: idea: hook up skype to a projector that covers one
> of the walls. and i can have an omni-tele-presence
> >> 13:55:04 [nslater]: silently watching and judging you all
> >> 13:55:05 [jan____]: heh, cascadia is optional :)
> >> 13:55:20 [jan____]: nslater: sounds good :)
> >> 13:55:27 [nslater]: benoitc: time to get a new assistant! ;)
> >> 13:55:36 [benoitc]: yup but was trying myself to still come even if a
> flight is 1700 euros
> >> 13:55:37 [nslater]: deathbear: yes
> >> 13:55:49 [jan____]: #task everyone tell everyone about
> http://conf.couchdb.org
> >> 13:55:58 [nslater]: is it not #action ?
> >> 13:56:07 [jan____]: benoitc: get in touch if price becomes an issue, we
> might be able to help
> >> 13:56:22 [jan____]: #action everyone tell everyone about
> http://conf.couchdb.org
> >> 13:56:37 [benoitc]: yuup was about to do it thx
> >> 13:56:45 [benoitc]: can we have an ad on the site ?
> >> 13:56:54 [benoitc]: like banner or sort of ?
> >> 13:56:59 [jan____]: yeah great idea
> >> 13:57:09 [nslater]: +1
> >> 13:57:15 [jan____]: benoitc: excellent idea, I’mma look after that
> >> 13:57:30 [garren]: Any idea who could do that for us?
> >> 13:57:52 [jan____]: garren: I pinged Yuriy in email
> >> 13:58:00 [nslater]: do we have any designers in da house?
> >> 13:58:14 [garren]: cool.
> >> 13:58:59 [nslater]: ait
> >> 13:59:00 [nslater]: wait
> >> 13:59:08 [nslater]: you've pinged yuriy about the website banner?
> >> 13:59:22 [jan____]: yes
> >> 13:59:29 [nslater]: #action put a banner on the website for couchdb conf
> >> 13:59:38 [nslater]: #info jan____ has spoken to Yuriy about the banner
> >> 13:59:38 [nslater]: okie dokie
> >> 13:59:39 [nslater]: thx
> >> 13:59:45 [jan____]: :)
> >> 13:59:56 [garren]: ok great.
> >> 14:00:01 [nslater]: me and jan____ are in the same room together. this
> adds a new dimension to the meeting
> >> 14:00:02 [garren]: ASFBot: meeting end
> >>
> >
>
>
--
Noah Slater
https://twitter.com/nslater
Re: Summary of IRC meeting in #couchdb-meeting, Wed Oct 2 13:01:16 2013
Posted by Dirkjan Ochtman <di...@ochtman.nl>.
On Wed, Oct 2, 2013 at 7:48 PM, Jan Lehnardt <ja...@apache.org> wrote:
> How does everyone feel about getting this in?
+1 SHIP MOAR AWESOME.
Re: Summary of IRC meeting in #couchdb-meeting, Wed Oct 2 13:01:16 2013
Posted by Alexander Shorin <kx...@gmail.com>.
On Wed, Oct 2, 2013 at 9:48 PM, Jan Lehnardt <ja...@apache.org> wrote:
>
> On Oct 2, 2013, at 16:05 , Jan Lehnardt <ja...@apache.org> wrote:
>
>>
>> On Oct 2, 2013, at 16:01 , ASF IRC Services <as...@wilderness.apache.org> wrote:
>>
>>> Members present: djc, deathbear, nslater, JasonSmith, garren, benoitc, dch, jan____, strmpnk
>>>
>>> ----------------
>>> Meeting summary:
>>> ----------------
>>>
>>> 1. Preface
>>>
>>> 2. Fauxton deploy for 1.5
>>> a. garren and deathbear to prepare compiled Fauxton in _utils/next (garren, 2)
>>>
>>> 3. plugins 1.5
>>>
>>> 4. node view server
>>>
>>> 5. Couchdb Conf Vancouver
>>> a. everyone tell everyone about http://conf.couchdb.org (jan____, 5)
>>> b. put a banner on the website for couchdb conf (nslater, 5)
>>> c. jan____ has spoken to Yuriy about the banner (nslater, 5)
>>>
>>>
>>> --------
>>> Actions:
>>> --------
>>> - garren and deathbear to prepare compiled Fauxton in _utils/next (garren, 13:27:15)
>>> - everyone tell everyone about http://conf.couchdb.org (jan____, 13:56:22)
>>> - put a banner on the website for couchdb conf (nslater, 13:59:29)
>>
>> missed this one in the meeting:
>> - jan to report on plugins state before the end of the day
>
> And here we go:
>
> I think it is still a bit raw, especially my idea of having users install plugins with one click. It all works and the hooks we have in CouchDB do all what they are supposed to, but I’d not feel right to start advertising that CouchDB has plugins now.
>
> However, I’d like to get at least the mechanics out, so we and outside devs get to play with it. I know at least two that are going to be using this and I am sure we can make a nice install procedure for GeoCouch that isn’t the current custom compilation. I think that is already a win and worth shipping.
>
> What I did on the branch for now is not link the plugin pages from Futon and Fauxton, so we don’t confuse users. But the pages are still there for people to play with and to hack around.
>
> The main code changes are:
>
> - addition of src/couch_plugins that doesn’t interfere with anything.
> - addition of loading config files as part of bin/couchdb.tpl.in that’s a NOP in the default case.
> - addition of a Futon and a Fauxton page to install plugins with one click, not linked to from anywhere yet.
>
> I say this is un-intrusive enough to let us get out into the field without much risk.
>
> How does everyone feel about getting this in?
I think that it is wise decision. This will give developers some time
till 1.6 release to update their extensions to use the plugins api and
provide any feedback about. In case of success even one this feature
will make 1.6 release awesome both for users and developers.
Re: Summary of IRC meeting in #couchdb-meeting, Wed Oct 2 13:01:16 2013
Posted by Jan Lehnardt <ja...@apache.org>.
On Oct 2, 2013, at 16:05 , Jan Lehnardt <ja...@apache.org> wrote:
>
> On Oct 2, 2013, at 16:01 , ASF IRC Services <as...@wilderness.apache.org> wrote:
>
>> Members present: djc, deathbear, nslater, JasonSmith, garren, benoitc, dch, jan____, strmpnk
>>
>> ----------------
>> Meeting summary:
>> ----------------
>>
>> 1. Preface
>>
>> 2. Fauxton deploy for 1.5
>> a. garren and deathbear to prepare compiled Fauxton in _utils/next (garren, 2)
>>
>> 3. plugins 1.5
>>
>> 4. node view server
>>
>> 5. Couchdb Conf Vancouver
>> a. everyone tell everyone about http://conf.couchdb.org (jan____, 5)
>> b. put a banner on the website for couchdb conf (nslater, 5)
>> c. jan____ has spoken to Yuriy about the banner (nslater, 5)
>>
>>
>> --------
>> Actions:
>> --------
>> - garren and deathbear to prepare compiled Fauxton in _utils/next (garren, 13:27:15)
>> - everyone tell everyone about http://conf.couchdb.org (jan____, 13:56:22)
>> - put a banner on the website for couchdb conf (nslater, 13:59:29)
>
> missed this one in the meeting:
> - jan to report on plugins state before the end of the day
And here we go:
I think it is still a bit raw, especially my idea of having users install plugins with one click. It all works and the hooks we have in CouchDB do all what they are supposed to, but I’d not feel right to start advertising that CouchDB has plugins now.
However, I’d like to get at least the mechanics out, so we and outside devs get to play with it. I know at least two that are going to be using this and I am sure we can make a nice install procedure for GeoCouch that isn’t the current custom compilation. I think that is already a win and worth shipping.
What I did on the branch for now is not link the plugin pages from Futon and Fauxton, so we don’t confuse users. But the pages are still there for people to play with and to hack around.
The main code changes are:
- addition of src/couch_plugins that doesn’t interfere with anything.
- addition of loading config files as part of bin/couchdb.tpl.in that’s a NOP in the default case.
- addition of a Futon and a Fauxton page to install plugins with one click, not linked to from anywhere yet.
I say this is un-intrusive enough to let us get out into the field without much risk.
How does everyone feel about getting this in?
Best
Jan
--
>
>>
>> IRC log follows:
>>
>>
>> # 1. Preface #
>> 13:01:45 [garren]: ASFBot: #topic Fauxton deploy for 1.5
>>
>>
>> # 2. Fauxton deploy for 1.5 #
>> 13:02:24 [garren]: Ok for Fauxton release.
>> 13:02:46 [garren]: We can either release Fauxton as a couchapp or we can do a compile and deploy it to share/www
>> 13:03:10 [JasonSmith]: IMO I like how Futon builds as part of CouchDB
>> 13:03:10 [garren]: I like the idea of the share/www and make it similar to the _util for futon.
>> 13:03:24 [JasonSmith]: I personally, and for CouchDB hosting, I like to compile once and it is installed for all users
>> 13:03:32 [JasonSmith]: garren: +1
>> 13:03:40 [jan____]: garren: yeah, could we make it /_utils/next/ or something?
>> 13:03:41 [garren]: JasonSmith: great, to compile Fauxton we would need node integrated into the couchdb build process.
>> 13:04:20 [garren]: Or should one of the fauxton team members rather just compile beforehand and commit the compiled Fauxton into git?
>> 13:04:51 [strmpnk]: +1 maybe we should have a _contrib/
>> 13:05:37 [garren]: jan____: which is easier at this stage, compiling Fauxton in the build process or compile it beforehand?
>> 13:05:39 [JasonSmith]: The way I always imagined it would work was ./configure would detect if you could build it (you have Node and maybe Grunt)
>> 13:05:52 [JasonSmith]: Checking for Node.js.....ok
>> 13:06:25 [garren]: JasonSmith: yeah that makes a lot of sense.
>> 13:06:40 [garren]: who is the most capable bash-fu expert to help us with that?
>> 13:06:47 [strmpnk]: I don't see why the artifacts should be committed.
>> 13:06:47 [JasonSmith]: To me the thing I am not sure about is, npm installs at build time? I kind of don't personally like that
>> 13:06:57 [jan____]: garren: either is possible, I think doing it as part of the build (like Jason says) makes the most sense, but it would mean some autofoo work needing to be done
>> 13:07:02 [JasonSmith]: to me your npm packages should be a build-time dependency, like libicu or libmozjs
>> 13:07:43 [JasonSmith]: Correct me if I'm wrong, but I really want to roll it out on Iris Couch and then overnight anybody can just try it out on their account
>> 13:07:50 [jan____]: nslater to the rescue!
>> 13:07:57 [garren]: JasonSmith: that would be great.
>> 13:08:29 [jan____]: garren: can you sum up the question for nslater ?
>> 13:09:01 [garren]: nslater: we trying to find the best way of deploying Fauxton for the next release. Should we commit the compiled artifacts of Fauxton into git or..
>> 13:09:31 [garren]: should the build process do all that for us. Bearing in mind that we would then require node plus some npm packages as dependancies of Couchdb.
>> 13:10:09 [garren]: It might be easier for this first release just to commit the compiled artifacts and later we look to integrate Fauxton into the build process.
>> 13:10:49 [nslater]: "compiled"?
>> 13:11:40 [garren]: nslater: We compile all the css, html templates and javascript and compile it into 3 files. Instead of the 50 or so files we have in development.
>> 13:12:09 [nslater]: i think we should do it in make
>> 13:12:18 [nslater]: note that this doesn't introduce a user dependancy on node
>> 13:12:42 [nslater]: we could do it so that we ship the pre-compiled files along with the source
>> 13:12:47 [garren]: nslater: could you explain a little more.
>> 13:12:56 [nslater]: sure
>> 13:13:28 [nslater]: in autotools it is possible to set it up so that during the "make dist" step of preparing the release tarball, some targets are built from the sources, and shipped along with the rest of the source, so that end users don't need to remake them
>> 13:13:38 [nslater]: the manpages are one example of this (we can't expect users to have help2man installed)
>> 13:13:44 [nslater]: the entire docs are another example
>> 13:13:51 [deathbear]: hi :)
>> 13:14:00 [garren]: hey deathbear.
>> 13:14:38 [dch]: hey, late but made it
>> 13:14:38 [garren]: nslater: that sounds good. Would that mean that the release manager would then be the only one needing the node dependancies?
>> 13:14:45 [garren]: hey dch
>> 13:14:54 [nslater]: garren: yes. or anyone trying to built from a git checkout
>> 13:15:07 [nslater]: but if you're trying to build from a git checkout then you need everything else too
>> 13:15:17 [garren]: ok great.
>> 13:15:19 [nslater]: i am talking autotools, autoconf, help2man, sphinx, etc, etc
>> 13:15:33 [garren]: nslater: would you have time to help us set this up in make?
>> 13:15:34 [nslater]: we call these developer dependancies in the root doc files
>> 13:15:55 [nslater]: garren: how much help do you folks need? are you comfortable setting up the default targets?
>> 13:16:11 [nslater]: (which i could then tweak)
>> 13:16:19 [nslater]: or do you need help with the whole thing?
>> 13:16:35 [garren]: nslater: to be honest I'm rubbish with make. I could take a look. Our whole build process is run via grunt which is similar to make.
>> 13:16:51 [jan____]: I’m happy to land a hand, too, but I will need some guidance
>> 13:17:02 [nslater]: don't worry about it. i am happy to pair with garren on it. it sounds simple enough
>> 13:17:07 [garren]: So all we would need to do is possibly do a check that node is installed, install npm dependancies and run grunt release task.
>> 13:17:07 [nslater]: but thanks for the offer
>> 13:17:18 [nslater]: garren, we wouldn't install npm stuff from make
>> 13:17:29 [nslater]: we'd just bail out of configure unless the modules were detected
>> 13:17:38 [garren]: ok great.
>> 13:17:53 [nslater]: jan____ corrects me on this
>> 13:17:54 [JasonSmith]: To me the most complex and error-prone part is the rather large npm install
>> 13:17:55 [garren]: nslater can I follow up with you after this meeting and we can set a time we both around in the next 24 hrs our so to do this.
>> 13:17:55 [nslater]: but we'll see when we get to it
>> 13:18:07 [nslater]: next 24 hours? woo jeez
>> 13:18:07 [deathbear]: hi, we have a make file for deploying
>> 13:18:07 [deathbear]: if that helps
>> 13:18:30 [nslater]: what is "grunt" and do we need to continue using it?
>> 13:18:39 [jan____]: garren: deathbear: a broader question before we set times, is Fauxton ready to be shown off in 1.5.0?
>> 13:18:48 [garren]: deathbear: that could help. Maybe you and I can take a stab at this today and then get nslater and jan____ to check it and apply any tweaks.
>> 13:18:55 [deathbear]: I think it is, as experimental
>> 13:19:03 [garren]: yeah definitely as experimental.
>> 13:19:10 [nslater]: when are we pulling the trigger on 1.5.0?
>> 13:19:11 [deathbear]: we've been working really hard on it since the redesign
>> 13:19:33 [jan____]: nslater: grunt is a make for JS projects. we definitely want to keep using it
>> 13:19:34 [JasonSmith]: nslater: grunt is a build tool, to a first approximation it is Node.js's make
>> 13:19:41 [jan____]: nslater: djc wants to cut in ~24 hrs.
>> 13:19:49 [nslater]: i am wary of including a build tool inside a build tool
>> 13:19:50 [garren]: nslater: djc sent an email saying he is cutting the release in the next 24 hrs or so.
>> 13:19:55 [nslater]: but i guess we did it for sphinx
>> 13:20:03 [nslater]: jan____: okay then fauxton isn't going to go in
>> 13:20:17 [jan____]: nslater: why not?
>> 13:20:24 [nslater]: because i can't commit to getting this working in 24 hours
>> 13:20:42 [jan____]: tomorrow is a holiday in .de ;)
>> 13:20:49 [garren]: nslater: can we not rather do a precompiled artifact for this release? And then after 1.5 integrat into the build procedure
>> 13:20:57 [jan____]: I can give it a shot.
>> 13:20:58 [JasonSmith]: nslater: This is what I was saying earlier. I would say call Grunt a build dpeendnecy
>> 13:21:06 [jan____]: garren: that’s a decent shortcut
>> 13:21:08 [JasonSmith]: so you need Grunt the same way you need libicu-dev
>> 13:21:13 [nslater]: jan____: disagree
>> 13:21:19 [jan____]: JasonSmith: nslater wasn’t around then
>> 13:21:28 [nslater]: i think it would run afoul of asf principals
>> 13:21:44 [jan____]: which one?
>> 13:22:07 [djc]: (sorry I'm late)
>> 13:22:15 [nslater]: our source releases should be source releases. they should contain everything you need to modify and run the product. i don't think we're allowed, and i don't think we should, ship compiled files
>> 13:22:53 [garren]: nslater: when we talk compiled files its just a html file, a javascript file, a css file, a image file and 1 font file.
>> 13:23:00 [jan____]: our docs are compiled
>> 13:23:08 [nslater]: jan____: but we also ship the source for them with the compilation
>> 13:23:24 [jan____]: we can also ship the fauxton source
>> 13:23:33 [garren]: yes
>> 13:23:42 [nslater]: this seems very 11th hour
>> 13:23:49 [jan____]: plus, it is a preview, not a final release, so I think we have some leeway for shortcuts
>> 13:23:56 [nslater]: part of the rolling release schedule is that we don't panic about this stuff
>> 13:23:59 [djc]: I think shipping source + "compiled" is fine
>> 13:24:05 [jan____]: nslater: I think this is a simple issue.
>> 13:24:05 [nslater]: they'll be another release in a month
>> 13:24:06 [jan____]: nobody panics
>> 13:24:08 [nslater]: jan____: i don't feel comfortable doing this
>> 13:24:20 [nslater]: and i would prefer about 1w to work on the build system for it
>> 13:24:44 [nslater]: and even then, i would prefer a bit longer, because i would have to stop working on everything else couchdb related
>> 13:24:46 [nslater]: and i have some other pressing items that need my attention
>> 13:24:54 [jan____]: src/fauxton/README.md explains how to build from source, and we also ship share/www/next/ (or whatever) with the compiled version of fauxton. End of story
>> 13:25:08 [jan____]: then let’s not integrate that into hte build today but ship a compiled version
>> 13:25:33 [nslater]: src/fauxton/ with instructions, and a compiled share/www/next is not ideal, but i agree it doesn't violate our principals
>> 13:25:40 [garren]: awesome.
>> 13:25:48 [deathbear]: :)
>> 13:26:03 [jan____]: I agree it is not ideal, but it would allow us to ship a fauxton preview tomorrow :)
>> 13:26:05 [nslater]: i would like to work on it so that in the next release we have it properly wired up to the build system
>> 13:26:11 [jan____]: plus, it is not a dirty hack
>> 13:26:18 [garren]: deathbear and I can work on getting fauxton working on _utils/next url.
>> 13:26:26 [nslater]: (With garren or deathbear or whomever)
>> 13:26:34 [deathbear]: in the next release fauxton will be even more awesome.
>> 13:26:43 [jan____]: yeah, I consider it a blocker for a proper fauxton release that it is integrated into the build system
>> 13:26:45 [garren]: nslater: I would definintely be happy to help integrate into the build tools. I do think thats the best option long term.
>> 13:26:50 [nslater]: okay cool
>> 13:27:07 [djc]: consensus \o/
>> 13:27:15 [garren]: #action garren and deathbear to prepare compiled Fauxton in _utils/next
>> 13:27:29 [garren]: everyone happy ready for the next topic?
>> 13:27:29 [deathbear]: woo
>> 13:27:38 [djc]: bikeshedding: does _utils-ng/ or something make more sense?
>> 13:27:38 [jan____]: ^5
>> 13:27:54 [deathbear]: ^5
>> 13:27:56 [jan____]: djc: literally don’t care
>>
>>
>> # 3. plugins 1.5 #
>> 13:28:24 [nslater]: wait wait
>> 13:28:33 [nslater]: is _utils-nx the new X-feature?
>> 13:28:35 [nslater]: *_utils-ng
>> 13:28:48 [nslater]: i.e. we're not going to be lumbered with this url choice are we?
>> 13:29:02 [djc]: nslater: no
>> 13:29:19 [djc]: just while it's experimental
>> 13:29:34 [garren]: djc yea I agree.
>> 13:30:05 [dch]: ACTION then call it _experimental and make it crystal clear. But as djc said "don't care" lets pick one.
>> 13:30:29 [garren]: dch: I can send an email with suggestions and people can vote on one?
>> 13:30:52 [JasonSmith]: yeah xylophone
>> 13:30:52 [jan____]: hell no, just pick one
>> 13:30:55 [djc]: xylophone
>> 13:30:59 [dch]: lets not, pick one now.
>> 13:31:08 [dch]: ding ding
>> 13:31:15 [garren]: ok we will pick one.
>> 13:31:23 [garren]: Okay next topic?
>> 13:31:24 [djc]: yeah
>> 13:31:32 [jan____]: aye
>> 13:31:32 [garren]: JasonSmith: can you start up off on plugins for 1.5
>> 13:31:32 [djc]: I think jan____ killed plugins for 1.5
>> 13:31:47 [JasonSmith]: really?
>> 13:32:03 [jan____]: soo, I wanted to spend a minute today to see what’s missing for plugins
>> 13:32:05 [jan____]: I haven’t managed to do that yet
>> 13:32:19 [djc]: JasonSmith: if you have round tuits to make it happen, I'm all for it!
>> 13:32:22 [jan____]: I think I can frame it shippable, but I only will know later today
>> 13:32:27 [djc]: just that jan____ didn't have time, I think
>> 13:32:42 [jan____]: yeah, I found some time under the carpet
>> 13:32:49 [jan____]: but not before the meeting
>> 13:32:59 [JasonSmith]: jan____: I think I am happy with plugins, but just my definition of "plugins" may be different from yours
>> 13:32:59 [jan____]: I will update the 1.5 thread on dev@ later today
>> 13:33:38 [jan____]: JasonSmith: well, you rip out /_plugins and /_utils/plugins.html
>> 13:33:40 [jan____]: which is all that I did
>> 13:34:10 [jan____]: e.g the binary installer & one-click-install-registry page
>> 13:34:33 [jan____]: the rest were just minimal changes in how CouchDB operates, but that’s all that you neede
>> 13:34:33 [jan____]: d
>> 13:34:57 [benoitc]: one thing to consider is how the pluging would work in a system where you do live upgrade of a node
>> 13:35:12 [jan____]: so far the things I am not too happy about are the barren look of /_utils/plugins.html / same for the fauxton version
>> 13:35:13 [benoitc]: they won't be part of the release which may be problematic
>> 13:35:28 [jan____]: benoitc: yeah, totally, but for this release that is out of scope and won’t work
>> 13:35:53 [jan____]: e.g. if you do live upgrades you will want to make the plugins you need part of your source distribution
>> 13:36:15 [benoitc]: well if we ship it , we make a promise to the user that it will stay for a long time
>> 13:36:38 [benoitc]: so we need to make sure it can really exists with a release system
>> 13:36:40 [jan____]: benoitc: no, we ship it as “this will change a lot”
>> 13:36:53 [jan____]: as a preview, this isn’t a commitment yet
>> 13:37:44 [benoitc]: in the head of people it can be
>> 13:38:00 [nslater]: well then we need to properly set expectations
>> 13:38:14 [jan____]: yeah, but we can’t win that. we need to embrace experimntal features
>> 13:38:15 [JasonSmith]: I am happy regrading plugins
>> 13:38:17 [JasonSmith]: regarding plugins
>> 13:38:22 [benoitc]: why would they care to try a feature that could change a lot tomorrow
>> 13:38:30 [JasonSmith]: 1.5 as-is, I myself am happy
>> 13:38:30 [benoitc]: this is not that i am happy or not
>> 13:38:38 [benoitc]: i like the idea of having plugins
>> 13:38:54 [djc]: benoitc: if we document it clearly as changing, then there's nothing else we can do
>> 13:38:59 [benoitc]: but i wonder how it can really work with an erlang program
>> 13:39:08 [djc]: if it changes out from under people, it's their fault for relying on it
>> 13:39:24 [djc]: and experimental stuff leads to experimentation, which is good
>> 13:39:31 [jan____]: benoitc: I don’t feel comfortable shipping plugins as a long-term feature without having run a test version through a umber of users
>> 13:39:31 [djc]: we need more ideas about what/how to work this stuff
>> 13:39:40 [jan____]: regardless of how long we work on it unreleased
>> 13:39:58 [strmpnk]: benoitc: I agree on the worry about how it might cause problems but this is why it should be released as experimental, so those his are explored.
>> 13:40:55 [benoitc]: i would expect they land in master for a release or two before going directly in a release anyway
>> 13:41:09 [benoitc]: at least I wouldn't expect them for 1.5
>> 13:41:18 [djc]: benoitc: that's not how we work anymore, master means releasable
>> 13:41:33 [benoitc]: yes
>> 13:41:33 [benoitc]: so it is not in master
>> 13:41:55 [djc]: yes, but there's also no "bake-time" on master
>> 13:42:09 [jan____]: benoitc: I can merge it into master within the next 24 hours and then it is relesable
>> 13:42:09 [djc]: they bake in releases, need users to mature anyway
>> 13:42:18 [jan____]: the question is are we happy with the current state
>> 13:42:43 [jan____]: I think I can be happy with the current + minor fixes state
>> 13:42:49 [djc]: I have no answer to that, but am happy to defer to Jan & Jason
>> 13:43:35 [jan____]: right, again, will look into this after the meeting, but before tonight
>> 13:43:55 [benoitc]: i don't see the point to release a thing in 24h that have never landed in master for a while.
>> 13:44:18 [benoitc]: this is not how a quality software should work imo but this is out of topic
>> 13:44:33 [jan____]: benoitc: we don’t do baking in master anymore. branches are ready to ship or they are not
>> 13:44:47 [djc]: okay, I'm ready for the next topic
>> 13:44:55 [JasonSmith]: Ready
>> 13:44:55 [garren]: great
>> 13:44:56 [jan____]: benoitc: and especially with new stuff, we mark it as experimental, so people can play with it without expecting it to all work
>>
>>
>> # 4. node view server #
>> 13:45:18 [garren]: jan____: Can you start us off or is it JasonSmith?
>> 13:45:18 [jan____]: I also don’t quite see why we have to discuss the how of releases that we had agreed upon again
>> 13:45:20 [jan____]: ready.
>> 13:45:28 [JasonSmith]: I am done, plugins look good
>> 13:45:33 [jan____]: I got it
>> 13:45:34 [JasonSmith]: fdmanana says hi
>> 13:46:16 [jan____]: as far as I am concerned the nodejs viewserver works well enough to ship as an experimental release. There are some obvious todos, but they can be done later.
>> 13:46:29 [benoitc]: i don't remember to agree on such thing but anyway it wasn't the point
>> 13:46:36 [jan____]: the goal of the release is to get this into people’s hands so they can play and try to break it
>> 13:46:36 [benoitc]: i was speaking on a technical level.
>> 13:46:52 [benoitc]: let's go to the other topic
>> 13:47:00 [garren]: jan____: is there documentation on how to get it up and running. Eg I install 1.5 how do I activate the nodejs view server?
>> 13:47:30 [djc]: the nodejs view server doesn't add any dependencies for non-users, right?
>> 13:48:14 [jan____]: djc: correct
>> 13:48:39 [jan____]: garren: one sec
>> 13:48:46 [garren]: sure
>> 13:49:24 [JasonSmith]: jan____: +1
>> 13:49:40 [jan____]: garren: https://github.com/apache/couchdb/blob/1894-feature-experimental-nodejs-couchjs/share/doc/src/experimental.rst
>> 13:49:49 [jan____]: e.g. this would show up on docs.couchdb.org
>> 13:50:32 [djc]: I like the looks of this
>> 13:50:42 [garren]: jan____: perfect thanks.
>> 13:51:02 [jan____]: :D I made a poinnt of adding docs to get djc approval :D
>> 13:51:33 [jan____]: it is a little bare-bones, but we can update the doc on the go
>> 13:51:33 [djc]: and you shall have it
>> 13:51:40 [jan____]: (love the new docs immediate publish setup)
>> 13:51:55 [garren]: Excellent.
>> 13:52:10 [jan____]: nice
>> 13:52:17 [jan____]: djc: I’ll get that merged in time
>> 13:52:40 [garren]: Great any other topics someone wants to add?
>> 13:53:02 [jan____]: CouchDB Conf Vancouver
>> 13:53:17 [deathbear]: who is going?
>>
>>
>> # 5. Couchdb Conf Vancouver #
>> 13:53:24 [jan____]: <
>> 13:53:26 [deathbear]: I am still thinking about it
>> 13:53:54 [jan____]: deathbear: would be nice to meet you finally :)
>> 13:53:54 [nslater]: Yuriy should post an announcement about the tickets to both public couchdb lists
>> 13:53:54 [garren]: Unfortunately I can't make it.
>> 13:54:25 [nslater]: ACTION wished he flew
>> 13:54:27 [jan____]: It would also be cool if everyone here could use their social media outreach to get people aware of it
>> 13:54:32 [benoitc]: i probably can't make it happen. my assistant forgot to book the flight
>> 13:54:32 [jan____]: s/get/make
>> 13:54:41 [deathbear]: nslater are you scared of planes? cause ME TOO.
>> 13:54:41 [benoitc]: and cascadiajs don't interrest me at all
>> 13:54:48 [jan____]: benoitc: Doh :(
>> 13:54:55 [nslater]: idea: hook up skype to a projector that covers one of the walls. and i can have an omni-tele-presence
>> 13:55:04 [nslater]: silently watching and judging you all
>> 13:55:05 [jan____]: heh, cascadia is optional :)
>> 13:55:20 [jan____]: nslater: sounds good :)
>> 13:55:27 [nslater]: benoitc: time to get a new assistant! ;)
>> 13:55:36 [benoitc]: yup but was trying myself to still come even if a flight is 1700 euros
>> 13:55:37 [nslater]: deathbear: yes
>> 13:55:49 [jan____]: #task everyone tell everyone about http://conf.couchdb.org
>> 13:55:58 [nslater]: is it not #action ?
>> 13:56:07 [jan____]: benoitc: get in touch if price becomes an issue, we might be able to help
>> 13:56:22 [jan____]: #action everyone tell everyone about http://conf.couchdb.org
>> 13:56:37 [benoitc]: yuup was about to do it thx
>> 13:56:45 [benoitc]: can we have an ad on the site ?
>> 13:56:54 [benoitc]: like banner or sort of ?
>> 13:56:59 [jan____]: yeah great idea
>> 13:57:09 [nslater]: +1
>> 13:57:15 [jan____]: benoitc: excellent idea, I’mma look after that
>> 13:57:30 [garren]: Any idea who could do that for us?
>> 13:57:52 [jan____]: garren: I pinged Yuriy in email
>> 13:58:00 [nslater]: do we have any designers in da house?
>> 13:58:14 [garren]: cool.
>> 13:58:59 [nslater]: ait
>> 13:59:00 [nslater]: wait
>> 13:59:08 [nslater]: you've pinged yuriy about the website banner?
>> 13:59:22 [jan____]: yes
>> 13:59:29 [nslater]: #action put a banner on the website for couchdb conf
>> 13:59:38 [nslater]: #info jan____ has spoken to Yuriy about the banner
>> 13:59:38 [nslater]: okie dokie
>> 13:59:39 [nslater]: thx
>> 13:59:45 [jan____]: :)
>> 13:59:56 [garren]: ok great.
>> 14:00:01 [nslater]: me and jan____ are in the same room together. this adds a new dimension to the meeting
>> 14:00:02 [garren]: ASFBot: meeting end
>>
>
Re: Summary of IRC meeting in #couchdb-meeting, Wed Oct 2 13:01:16 2013
Posted by Jan Lehnardt <ja...@apache.org>.
On Oct 2, 2013, at 16:01 , ASF IRC Services <as...@wilderness.apache.org> wrote:
> Members present: djc, deathbear, nslater, JasonSmith, garren, benoitc, dch, jan____, strmpnk
>
> ----------------
> Meeting summary:
> ----------------
>
> 1. Preface
>
> 2. Fauxton deploy for 1.5
> a. garren and deathbear to prepare compiled Fauxton in _utils/next (garren, 2)
>
> 3. plugins 1.5
>
> 4. node view server
>
> 5. Couchdb Conf Vancouver
> a. everyone tell everyone about http://conf.couchdb.org (jan____, 5)
> b. put a banner on the website for couchdb conf (nslater, 5)
> c. jan____ has spoken to Yuriy about the banner (nslater, 5)
>
>
> --------
> Actions:
> --------
> - garren and deathbear to prepare compiled Fauxton in _utils/next (garren, 13:27:15)
> - everyone tell everyone about http://conf.couchdb.org (jan____, 13:56:22)
> - put a banner on the website for couchdb conf (nslater, 13:59:29)
missed this one in the meeting:
- jan to report on plugins state before the end of the day
>
> IRC log follows:
>
>
> # 1. Preface #
> 13:01:45 [garren]: ASFBot: #topic Fauxton deploy for 1.5
>
>
> # 2. Fauxton deploy for 1.5 #
> 13:02:24 [garren]: Ok for Fauxton release.
> 13:02:46 [garren]: We can either release Fauxton as a couchapp or we can do a compile and deploy it to share/www
> 13:03:10 [JasonSmith]: IMO I like how Futon builds as part of CouchDB
> 13:03:10 [garren]: I like the idea of the share/www and make it similar to the _util for futon.
> 13:03:24 [JasonSmith]: I personally, and for CouchDB hosting, I like to compile once and it is installed for all users
> 13:03:32 [JasonSmith]: garren: +1
> 13:03:40 [jan____]: garren: yeah, could we make it /_utils/next/ or something?
> 13:03:41 [garren]: JasonSmith: great, to compile Fauxton we would need node integrated into the couchdb build process.
> 13:04:20 [garren]: Or should one of the fauxton team members rather just compile beforehand and commit the compiled Fauxton into git?
> 13:04:51 [strmpnk]: +1 maybe we should have a _contrib/
> 13:05:37 [garren]: jan____: which is easier at this stage, compiling Fauxton in the build process or compile it beforehand?
> 13:05:39 [JasonSmith]: The way I always imagined it would work was ./configure would detect if you could build it (you have Node and maybe Grunt)
> 13:05:52 [JasonSmith]: Checking for Node.js.....ok
> 13:06:25 [garren]: JasonSmith: yeah that makes a lot of sense.
> 13:06:40 [garren]: who is the most capable bash-fu expert to help us with that?
> 13:06:47 [strmpnk]: I don't see why the artifacts should be committed.
> 13:06:47 [JasonSmith]: To me the thing I am not sure about is, npm installs at build time? I kind of don't personally like that
> 13:06:57 [jan____]: garren: either is possible, I think doing it as part of the build (like Jason says) makes the most sense, but it would mean some autofoo work needing to be done
> 13:07:02 [JasonSmith]: to me your npm packages should be a build-time dependency, like libicu or libmozjs
> 13:07:43 [JasonSmith]: Correct me if I'm wrong, but I really want to roll it out on Iris Couch and then overnight anybody can just try it out on their account
> 13:07:50 [jan____]: nslater to the rescue!
> 13:07:57 [garren]: JasonSmith: that would be great.
> 13:08:29 [jan____]: garren: can you sum up the question for nslater ?
> 13:09:01 [garren]: nslater: we trying to find the best way of deploying Fauxton for the next release. Should we commit the compiled artifacts of Fauxton into git or..
> 13:09:31 [garren]: should the build process do all that for us. Bearing in mind that we would then require node plus some npm packages as dependancies of Couchdb.
> 13:10:09 [garren]: It might be easier for this first release just to commit the compiled artifacts and later we look to integrate Fauxton into the build process.
> 13:10:49 [nslater]: "compiled"?
> 13:11:40 [garren]: nslater: We compile all the css, html templates and javascript and compile it into 3 files. Instead of the 50 or so files we have in development.
> 13:12:09 [nslater]: i think we should do it in make
> 13:12:18 [nslater]: note that this doesn't introduce a user dependancy on node
> 13:12:42 [nslater]: we could do it so that we ship the pre-compiled files along with the source
> 13:12:47 [garren]: nslater: could you explain a little more.
> 13:12:56 [nslater]: sure
> 13:13:28 [nslater]: in autotools it is possible to set it up so that during the "make dist" step of preparing the release tarball, some targets are built from the sources, and shipped along with the rest of the source, so that end users don't need to remake them
> 13:13:38 [nslater]: the manpages are one example of this (we can't expect users to have help2man installed)
> 13:13:44 [nslater]: the entire docs are another example
> 13:13:51 [deathbear]: hi :)
> 13:14:00 [garren]: hey deathbear.
> 13:14:38 [dch]: hey, late but made it
> 13:14:38 [garren]: nslater: that sounds good. Would that mean that the release manager would then be the only one needing the node dependancies?
> 13:14:45 [garren]: hey dch
> 13:14:54 [nslater]: garren: yes. or anyone trying to built from a git checkout
> 13:15:07 [nslater]: but if you're trying to build from a git checkout then you need everything else too
> 13:15:17 [garren]: ok great.
> 13:15:19 [nslater]: i am talking autotools, autoconf, help2man, sphinx, etc, etc
> 13:15:33 [garren]: nslater: would you have time to help us set this up in make?
> 13:15:34 [nslater]: we call these developer dependancies in the root doc files
> 13:15:55 [nslater]: garren: how much help do you folks need? are you comfortable setting up the default targets?
> 13:16:11 [nslater]: (which i could then tweak)
> 13:16:19 [nslater]: or do you need help with the whole thing?
> 13:16:35 [garren]: nslater: to be honest I'm rubbish with make. I could take a look. Our whole build process is run via grunt which is similar to make.
> 13:16:51 [jan____]: I’m happy to land a hand, too, but I will need some guidance
> 13:17:02 [nslater]: don't worry about it. i am happy to pair with garren on it. it sounds simple enough
> 13:17:07 [garren]: So all we would need to do is possibly do a check that node is installed, install npm dependancies and run grunt release task.
> 13:17:07 [nslater]: but thanks for the offer
> 13:17:18 [nslater]: garren, we wouldn't install npm stuff from make
> 13:17:29 [nslater]: we'd just bail out of configure unless the modules were detected
> 13:17:38 [garren]: ok great.
> 13:17:53 [nslater]: jan____ corrects me on this
> 13:17:54 [JasonSmith]: To me the most complex and error-prone part is the rather large npm install
> 13:17:55 [garren]: nslater can I follow up with you after this meeting and we can set a time we both around in the next 24 hrs our so to do this.
> 13:17:55 [nslater]: but we'll see when we get to it
> 13:18:07 [nslater]: next 24 hours? woo jeez
> 13:18:07 [deathbear]: hi, we have a make file for deploying
> 13:18:07 [deathbear]: if that helps
> 13:18:30 [nslater]: what is "grunt" and do we need to continue using it?
> 13:18:39 [jan____]: garren: deathbear: a broader question before we set times, is Fauxton ready to be shown off in 1.5.0?
> 13:18:48 [garren]: deathbear: that could help. Maybe you and I can take a stab at this today and then get nslater and jan____ to check it and apply any tweaks.
> 13:18:55 [deathbear]: I think it is, as experimental
> 13:19:03 [garren]: yeah definitely as experimental.
> 13:19:10 [nslater]: when are we pulling the trigger on 1.5.0?
> 13:19:11 [deathbear]: we've been working really hard on it since the redesign
> 13:19:33 [jan____]: nslater: grunt is a make for JS projects. we definitely want to keep using it
> 13:19:34 [JasonSmith]: nslater: grunt is a build tool, to a first approximation it is Node.js's make
> 13:19:41 [jan____]: nslater: djc wants to cut in ~24 hrs.
> 13:19:49 [nslater]: i am wary of including a build tool inside a build tool
> 13:19:50 [garren]: nslater: djc sent an email saying he is cutting the release in the next 24 hrs or so.
> 13:19:55 [nslater]: but i guess we did it for sphinx
> 13:20:03 [nslater]: jan____: okay then fauxton isn't going to go in
> 13:20:17 [jan____]: nslater: why not?
> 13:20:24 [nslater]: because i can't commit to getting this working in 24 hours
> 13:20:42 [jan____]: tomorrow is a holiday in .de ;)
> 13:20:49 [garren]: nslater: can we not rather do a precompiled artifact for this release? And then after 1.5 integrat into the build procedure
> 13:20:57 [jan____]: I can give it a shot.
> 13:20:58 [JasonSmith]: nslater: This is what I was saying earlier. I would say call Grunt a build dpeendnecy
> 13:21:06 [jan____]: garren: that’s a decent shortcut
> 13:21:08 [JasonSmith]: so you need Grunt the same way you need libicu-dev
> 13:21:13 [nslater]: jan____: disagree
> 13:21:19 [jan____]: JasonSmith: nslater wasn’t around then
> 13:21:28 [nslater]: i think it would run afoul of asf principals
> 13:21:44 [jan____]: which one?
> 13:22:07 [djc]: (sorry I'm late)
> 13:22:15 [nslater]: our source releases should be source releases. they should contain everything you need to modify and run the product. i don't think we're allowed, and i don't think we should, ship compiled files
> 13:22:53 [garren]: nslater: when we talk compiled files its just a html file, a javascript file, a css file, a image file and 1 font file.
> 13:23:00 [jan____]: our docs are compiled
> 13:23:08 [nslater]: jan____: but we also ship the source for them with the compilation
> 13:23:24 [jan____]: we can also ship the fauxton source
> 13:23:33 [garren]: yes
> 13:23:42 [nslater]: this seems very 11th hour
> 13:23:49 [jan____]: plus, it is a preview, not a final release, so I think we have some leeway for shortcuts
> 13:23:56 [nslater]: part of the rolling release schedule is that we don't panic about this stuff
> 13:23:59 [djc]: I think shipping source + "compiled" is fine
> 13:24:05 [jan____]: nslater: I think this is a simple issue.
> 13:24:05 [nslater]: they'll be another release in a month
> 13:24:06 [jan____]: nobody panics
> 13:24:08 [nslater]: jan____: i don't feel comfortable doing this
> 13:24:20 [nslater]: and i would prefer about 1w to work on the build system for it
> 13:24:44 [nslater]: and even then, i would prefer a bit longer, because i would have to stop working on everything else couchdb related
> 13:24:46 [nslater]: and i have some other pressing items that need my attention
> 13:24:54 [jan____]: src/fauxton/README.md explains how to build from source, and we also ship share/www/next/ (or whatever) with the compiled version of fauxton. End of story
> 13:25:08 [jan____]: then let’s not integrate that into hte build today but ship a compiled version
> 13:25:33 [nslater]: src/fauxton/ with instructions, and a compiled share/www/next is not ideal, but i agree it doesn't violate our principals
> 13:25:40 [garren]: awesome.
> 13:25:48 [deathbear]: :)
> 13:26:03 [jan____]: I agree it is not ideal, but it would allow us to ship a fauxton preview tomorrow :)
> 13:26:05 [nslater]: i would like to work on it so that in the next release we have it properly wired up to the build system
> 13:26:11 [jan____]: plus, it is not a dirty hack
> 13:26:18 [garren]: deathbear and I can work on getting fauxton working on _utils/next url.
> 13:26:26 [nslater]: (With garren or deathbear or whomever)
> 13:26:34 [deathbear]: in the next release fauxton will be even more awesome.
> 13:26:43 [jan____]: yeah, I consider it a blocker for a proper fauxton release that it is integrated into the build system
> 13:26:45 [garren]: nslater: I would definintely be happy to help integrate into the build tools. I do think thats the best option long term.
> 13:26:50 [nslater]: okay cool
> 13:27:07 [djc]: consensus \o/
> 13:27:15 [garren]: #action garren and deathbear to prepare compiled Fauxton in _utils/next
> 13:27:29 [garren]: everyone happy ready for the next topic?
> 13:27:29 [deathbear]: woo
> 13:27:38 [djc]: bikeshedding: does _utils-ng/ or something make more sense?
> 13:27:38 [jan____]: ^5
> 13:27:54 [deathbear]: ^5
> 13:27:56 [jan____]: djc: literally don’t care
>
>
> # 3. plugins 1.5 #
> 13:28:24 [nslater]: wait wait
> 13:28:33 [nslater]: is _utils-nx the new X-feature?
> 13:28:35 [nslater]: *_utils-ng
> 13:28:48 [nslater]: i.e. we're not going to be lumbered with this url choice are we?
> 13:29:02 [djc]: nslater: no
> 13:29:19 [djc]: just while it's experimental
> 13:29:34 [garren]: djc yea I agree.
> 13:30:05 [dch]: ACTION then call it _experimental and make it crystal clear. But as djc said "don't care" lets pick one.
> 13:30:29 [garren]: dch: I can send an email with suggestions and people can vote on one?
> 13:30:52 [JasonSmith]: yeah xylophone
> 13:30:52 [jan____]: hell no, just pick one
> 13:30:55 [djc]: xylophone
> 13:30:59 [dch]: lets not, pick one now.
> 13:31:08 [dch]: ding ding
> 13:31:15 [garren]: ok we will pick one.
> 13:31:23 [garren]: Okay next topic?
> 13:31:24 [djc]: yeah
> 13:31:32 [jan____]: aye
> 13:31:32 [garren]: JasonSmith: can you start up off on plugins for 1.5
> 13:31:32 [djc]: I think jan____ killed plugins for 1.5
> 13:31:47 [JasonSmith]: really?
> 13:32:03 [jan____]: soo, I wanted to spend a minute today to see what’s missing for plugins
> 13:32:05 [jan____]: I haven’t managed to do that yet
> 13:32:19 [djc]: JasonSmith: if you have round tuits to make it happen, I'm all for it!
> 13:32:22 [jan____]: I think I can frame it shippable, but I only will know later today
> 13:32:27 [djc]: just that jan____ didn't have time, I think
> 13:32:42 [jan____]: yeah, I found some time under the carpet
> 13:32:49 [jan____]: but not before the meeting
> 13:32:59 [JasonSmith]: jan____: I think I am happy with plugins, but just my definition of "plugins" may be different from yours
> 13:32:59 [jan____]: I will update the 1.5 thread on dev@ later today
> 13:33:38 [jan____]: JasonSmith: well, you rip out /_plugins and /_utils/plugins.html
> 13:33:40 [jan____]: which is all that I did
> 13:34:10 [jan____]: e.g the binary installer & one-click-install-registry page
> 13:34:33 [jan____]: the rest were just minimal changes in how CouchDB operates, but that’s all that you neede
> 13:34:33 [jan____]: d
> 13:34:57 [benoitc]: one thing to consider is how the pluging would work in a system where you do live upgrade of a node
> 13:35:12 [jan____]: so far the things I am not too happy about are the barren look of /_utils/plugins.html / same for the fauxton version
> 13:35:13 [benoitc]: they won't be part of the release which may be problematic
> 13:35:28 [jan____]: benoitc: yeah, totally, but for this release that is out of scope and won’t work
> 13:35:53 [jan____]: e.g. if you do live upgrades you will want to make the plugins you need part of your source distribution
> 13:36:15 [benoitc]: well if we ship it , we make a promise to the user that it will stay for a long time
> 13:36:38 [benoitc]: so we need to make sure it can really exists with a release system
> 13:36:40 [jan____]: benoitc: no, we ship it as “this will change a lot”
> 13:36:53 [jan____]: as a preview, this isn’t a commitment yet
> 13:37:44 [benoitc]: in the head of people it can be
> 13:38:00 [nslater]: well then we need to properly set expectations
> 13:38:14 [jan____]: yeah, but we can’t win that. we need to embrace experimntal features
> 13:38:15 [JasonSmith]: I am happy regrading plugins
> 13:38:17 [JasonSmith]: regarding plugins
> 13:38:22 [benoitc]: why would they care to try a feature that could change a lot tomorrow
> 13:38:30 [JasonSmith]: 1.5 as-is, I myself am happy
> 13:38:30 [benoitc]: this is not that i am happy or not
> 13:38:38 [benoitc]: i like the idea of having plugins
> 13:38:54 [djc]: benoitc: if we document it clearly as changing, then there's nothing else we can do
> 13:38:59 [benoitc]: but i wonder how it can really work with an erlang program
> 13:39:08 [djc]: if it changes out from under people, it's their fault for relying on it
> 13:39:24 [djc]: and experimental stuff leads to experimentation, which is good
> 13:39:31 [jan____]: benoitc: I don’t feel comfortable shipping plugins as a long-term feature without having run a test version through a umber of users
> 13:39:31 [djc]: we need more ideas about what/how to work this stuff
> 13:39:40 [jan____]: regardless of how long we work on it unreleased
> 13:39:58 [strmpnk]: benoitc: I agree on the worry about how it might cause problems but this is why it should be released as experimental, so those his are explored.
> 13:40:55 [benoitc]: i would expect they land in master for a release or two before going directly in a release anyway
> 13:41:09 [benoitc]: at least I wouldn't expect them for 1.5
> 13:41:18 [djc]: benoitc: that's not how we work anymore, master means releasable
> 13:41:33 [benoitc]: yes
> 13:41:33 [benoitc]: so it is not in master
> 13:41:55 [djc]: yes, but there's also no "bake-time" on master
> 13:42:09 [jan____]: benoitc: I can merge it into master within the next 24 hours and then it is relesable
> 13:42:09 [djc]: they bake in releases, need users to mature anyway
> 13:42:18 [jan____]: the question is are we happy with the current state
> 13:42:43 [jan____]: I think I can be happy with the current + minor fixes state
> 13:42:49 [djc]: I have no answer to that, but am happy to defer to Jan & Jason
> 13:43:35 [jan____]: right, again, will look into this after the meeting, but before tonight
> 13:43:55 [benoitc]: i don't see the point to release a thing in 24h that have never landed in master for a while.
> 13:44:18 [benoitc]: this is not how a quality software should work imo but this is out of topic
> 13:44:33 [jan____]: benoitc: we don’t do baking in master anymore. branches are ready to ship or they are not
> 13:44:47 [djc]: okay, I'm ready for the next topic
> 13:44:55 [JasonSmith]: Ready
> 13:44:55 [garren]: great
> 13:44:56 [jan____]: benoitc: and especially with new stuff, we mark it as experimental, so people can play with it without expecting it to all work
>
>
> # 4. node view server #
> 13:45:18 [garren]: jan____: Can you start us off or is it JasonSmith?
> 13:45:18 [jan____]: I also don’t quite see why we have to discuss the how of releases that we had agreed upon again
> 13:45:20 [jan____]: ready.
> 13:45:28 [JasonSmith]: I am done, plugins look good
> 13:45:33 [jan____]: I got it
> 13:45:34 [JasonSmith]: fdmanana says hi
> 13:46:16 [jan____]: as far as I am concerned the nodejs viewserver works well enough to ship as an experimental release. There are some obvious todos, but they can be done later.
> 13:46:29 [benoitc]: i don't remember to agree on such thing but anyway it wasn't the point
> 13:46:36 [jan____]: the goal of the release is to get this into people’s hands so they can play and try to break it
> 13:46:36 [benoitc]: i was speaking on a technical level.
> 13:46:52 [benoitc]: let's go to the other topic
> 13:47:00 [garren]: jan____: is there documentation on how to get it up and running. Eg I install 1.5 how do I activate the nodejs view server?
> 13:47:30 [djc]: the nodejs view server doesn't add any dependencies for non-users, right?
> 13:48:14 [jan____]: djc: correct
> 13:48:39 [jan____]: garren: one sec
> 13:48:46 [garren]: sure
> 13:49:24 [JasonSmith]: jan____: +1
> 13:49:40 [jan____]: garren: https://github.com/apache/couchdb/blob/1894-feature-experimental-nodejs-couchjs/share/doc/src/experimental.rst
> 13:49:49 [jan____]: e.g. this would show up on docs.couchdb.org
> 13:50:32 [djc]: I like the looks of this
> 13:50:42 [garren]: jan____: perfect thanks.
> 13:51:02 [jan____]: :D I made a poinnt of adding docs to get djc approval :D
> 13:51:33 [jan____]: it is a little bare-bones, but we can update the doc on the go
> 13:51:33 [djc]: and you shall have it
> 13:51:40 [jan____]: (love the new docs immediate publish setup)
> 13:51:55 [garren]: Excellent.
> 13:52:10 [jan____]: nice
> 13:52:17 [jan____]: djc: I’ll get that merged in time
> 13:52:40 [garren]: Great any other topics someone wants to add?
> 13:53:02 [jan____]: CouchDB Conf Vancouver
> 13:53:17 [deathbear]: who is going?
>
>
> # 5. Couchdb Conf Vancouver #
> 13:53:24 [jan____]: <
> 13:53:26 [deathbear]: I am still thinking about it
> 13:53:54 [jan____]: deathbear: would be nice to meet you finally :)
> 13:53:54 [nslater]: Yuriy should post an announcement about the tickets to both public couchdb lists
> 13:53:54 [garren]: Unfortunately I can't make it.
> 13:54:25 [nslater]: ACTION wished he flew
> 13:54:27 [jan____]: It would also be cool if everyone here could use their social media outreach to get people aware of it
> 13:54:32 [benoitc]: i probably can't make it happen. my assistant forgot to book the flight
> 13:54:32 [jan____]: s/get/make
> 13:54:41 [deathbear]: nslater are you scared of planes? cause ME TOO.
> 13:54:41 [benoitc]: and cascadiajs don't interrest me at all
> 13:54:48 [jan____]: benoitc: Doh :(
> 13:54:55 [nslater]: idea: hook up skype to a projector that covers one of the walls. and i can have an omni-tele-presence
> 13:55:04 [nslater]: silently watching and judging you all
> 13:55:05 [jan____]: heh, cascadia is optional :)
> 13:55:20 [jan____]: nslater: sounds good :)
> 13:55:27 [nslater]: benoitc: time to get a new assistant! ;)
> 13:55:36 [benoitc]: yup but was trying myself to still come even if a flight is 1700 euros
> 13:55:37 [nslater]: deathbear: yes
> 13:55:49 [jan____]: #task everyone tell everyone about http://conf.couchdb.org
> 13:55:58 [nslater]: is it not #action ?
> 13:56:07 [jan____]: benoitc: get in touch if price becomes an issue, we might be able to help
> 13:56:22 [jan____]: #action everyone tell everyone about http://conf.couchdb.org
> 13:56:37 [benoitc]: yuup was about to do it thx
> 13:56:45 [benoitc]: can we have an ad on the site ?
> 13:56:54 [benoitc]: like banner or sort of ?
> 13:56:59 [jan____]: yeah great idea
> 13:57:09 [nslater]: +1
> 13:57:15 [jan____]: benoitc: excellent idea, I’mma look after that
> 13:57:30 [garren]: Any idea who could do that for us?
> 13:57:52 [jan____]: garren: I pinged Yuriy in email
> 13:58:00 [nslater]: do we have any designers in da house?
> 13:58:14 [garren]: cool.
> 13:58:59 [nslater]: ait
> 13:59:00 [nslater]: wait
> 13:59:08 [nslater]: you've pinged yuriy about the website banner?
> 13:59:22 [jan____]: yes
> 13:59:29 [nslater]: #action put a banner on the website for couchdb conf
> 13:59:38 [nslater]: #info jan____ has spoken to Yuriy about the banner
> 13:59:38 [nslater]: okie dokie
> 13:59:39 [nslater]: thx
> 13:59:45 [jan____]: :)
> 13:59:56 [garren]: ok great.
> 14:00:01 [nslater]: me and jan____ are in the same room together. this adds a new dimension to the meeting
> 14:00:02 [garren]: ASFBot: meeting end
>