couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: Summary of IRC meeting in #couchdb-meeting, Wed Oct 2 13:01:16 2013
Date Wed, 02 Oct 2013 17:48:39 GMT

On Oct 2, 2013, at 16:05 , Jan Lehnardt <> wrote:

> On Oct 2, 2013, at 16:01 , ASF IRC Services <> wrote:
>> Members present: djc, deathbear, nslater, JasonSmith, garren, benoitc, dch, jan____,
>> ----------------
>> 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 (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 (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/ that’s a NOP in the default
- 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?


>> 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
>> 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/ 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
>> 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
>> 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
>> 13:32:22 [jan____]: I think I can frame it shippable, but I only will know later
>> 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
>> 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
>> 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
>> 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,
>> 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:
>> 13:49:49 [jan____]: e.g. this would show up on
>> 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
>> 13:55:37 [nslater]: deathbear: yes
>> 13:55:49 [jan____]: #task everyone tell everyone about
>> 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
>> 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

View raw message