couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@apache.org>
Subject Re: Summary of IRC meeting in #couchdb-meeting, Wed Oct 2 13:01:16 2013
Date Wed, 02 Oct 2013 18:45:16 GMT
+1


On 2 October 2013 19:48, Jan Lehnardt <jan@apache.org> wrote:

>
> On Oct 2, 2013, at 16:05 , Jan Lehnardt <jan@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message