+1
On 2 October 2013 19:48, Jan Lehnardt <[email protected]> wrote: > > On Oct 2, 2013, at 16:05 , Jan Lehnardt <[email protected]> wrote: > > > > > On Oct 2, 2013, at 16:01 , ASF IRC Services < > [email protected]> 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
