On Oct 2, 2013, at 16:05 , Jan Lehnardt <j...@apache.org> wrote: > > On Oct 2, 2013, at 16:01 , ASF IRC Services <asf...@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 >> >
signature.asc
Description: Message signed with OpenPGP using GPGMail
