This version (2017/05/27 13:44) is a draft.
Approvals: 0/1

[01:07:41] <DP2015> whats the differnece between vertx-mysql-postgresql-client, SQL common and JDBC client

[08:16:39] <jac_> The JDBC examples at all lead to broken links.

[08:22:36] <millrossjez> they seem to work for me

[08:23:19] <millrossjez> eg I just navigated from the url you gave to

[08:29:14] <jac_> Yes, the source is there only the links lower on the page lead to 404's for me.

[08:43:50] <purplefox_> jac_: please could you add a github issue?

[08:43:56] <purplefox_> i trust you can navigate manually for now

[09:18:20] <jac_> purplefox - sure thing, I'll make sure it's done sometime today.

[10:11:42] <purplefox_> temporalfox: cescoffier: cescoffier: hi folks did you get a chance to look at yet?

[10:11:56] <temporalfox> wasn't aware of it :-)

[10:12:07] <purplefox_> i posted on the google group yesterday about it

[10:12:23] <temporalfox> I'm genboy !!!!

[10:12:32] <temporalfox> catching up :-)

[10:13:50] <purplefox_> i've put down some initial assignments but these are just guesses

[10:14:08] <purplefox_> yeah, genboy, but this is just because you've done most of the work in that area :)

[10:14:50] <purplefox_> temporalfox: pmlopes cescoffier: also some feedback/discussion on the actual document would be good

[10:14:55] <temporalfox> ok

[10:15:05] <purplefox_> do you agree? disagree? (with the idea)

[10:15:15] <purplefox_> can it be improved etc

[10:16:40] <temporalfox> at first look it makes sense to me

[10:19:04] <purplefox_> so it's really just formalising what is already true - the independent nature of Vert.x

[10:19:22] <cescoffier> I'm the hype guy : just the hype thingy for me :-)

[10:19:22] <cescoffier> I definitely agree, we need referals for all components (point of contact)

[10:20:36] <purplefox_> +1

[10:20:46] <purplefox_> I'd also like to actively try and get more non red hat people involved

[10:21:02] <purplefox_> as we are quite “skewed” towards RH at the moment

[10:21:28] <pmlopes> i agree

[10:24:00] <purplefox_> if you guys have a preference for any particular component (or don't want to do one) just say

[10:24:12] <purplefox_> like i say, what i have put down there for now is just an initial guess

[10:24:16] <purplefox_> there are plenty of slots to fill

[10:24:51] <pmlopes> i was thinking that i can take care of sql and/or auth

[10:26:05] <purplefox_> sounds good to me

[10:26:17] <purplefox_> that goes together well with web stuff too

[10:26:45] <pmlopes> yes

[10:28:39] <purplefox_> but also we need to leave some stuff for clement too :)

[10:28:47] <purplefox_> cescoffier: do you have any preferences?

[10:28:57] <pmlopes> only hip stuff, mongodb :)

[10:29:06] <pmlopes> just kidding :)

[10:29:27] <cescoffier> the services

[10:29:28] <cescoffier> I already looked into them

[10:29:37] <cescoffier> (mongo is not hype anymore ;-))

[10:30:22] <cescoffier> having the same lead for data access make sense as things need to be homogeneous

[10:32:28] <cescoffier> there are 'transversal' stuff that could be mentioned too

[10:33:28] <cescoffier> such as build, examples ….

[10:33:55] <purplefox_> +1

[10:34:05] <purplefox_> actually i just added examples and added you as maintainer ;)

[10:34:27] <purplefox_> build stuff, you mean as in managing the vertx-parent, vertx-ext-parent stuff?

[10:34:50] <cescoffier> yes, + CI and automatisation

[10:35:07] <cescoffier> and stack

[10:35:08] <purplefox_> i think CI should be the responsibility of the individual component maointainer to make sure the component is on CI

[10:35:29] <purplefox_> stack i have on the list already under “distributions”

[10:35:54] <cescoffier> Missed it sorry

[10:36:08] <purplefox_> i've assigned julien but if you want it…

[10:36:58] <purplefox_> up til now Julien has been our in house “Maven guru”, but maybe you want to take over the role, considering you have a lot of skills in this area :)

[10:38:48] <cescoffier> Up to you, I can do it.

[10:40:09] <purplefox_> don't feel compelled to say yes, it's totally up to you. i can leave it with julien too :)

[10:40:21] <purplefox_> maybe you have a fight amongst yourselves ;)

[10:41:29] <cescoffier> no no, Maven is fine

[10:41:39] <cescoffier> I will do it

[10:42:05] <cescoffier> except if Julien want to keep it ;-)

[10:42:12] <temporalfox> I think we can share it :-)

[10:42:42] <purplefox_> ok so let's just keep julien as maintainer for now, but you can help out if you like

[10:42:55] <cescoffier> ok

[10:43:06] <purplefox_> one key thing about maintainership is you don't have to do all the work yourself, delegation is fine. it's just the responsibility for delivery is on the maintainer

[10:44:10] <temporalfox> I would rather for now keep “maintainership” and hand it to clement over time, as he seems more active than me on the subject

[10:44:19] <purplefox_> cescoffier: I'm not sure if michael will be able to take maintainership of the website, but if not maybe that's something you would like too?

[10:44:29] <purplefox_> considering you know it pretty well now, after your work with blogs etc

[10:44:41] <cescoffier> definitely, I'm now able to maintain the web site

[10:44:43] <purplefox_> temporalfox: +1

[10:46:43] <cescoffier> right now, I'm more looking at things on almost any project than focusing a one

[10:47:32] <purplefox_> right and it's fine to continue doing that

[10:47:53] <purplefox_> i think we should continue to fix bugs / do stuff in other projects

[10:48:18] <purplefox_> this is really more about ownership which is less of an issue for us as full time employees but more important when it comes to community maintainers

[10:48:46] <purplefox_> so don't feel that just because you're not maintainer you can't do stuff in a component :)

[10:49:06] <cescoffier> So I can still break things everywhere :-)

[10:49:56] <purplefox_> yes :)

[10:49:59] <purplefox_> (me too)_

[10:51:01] <cescoffier> and ownerships is going to evolve with time

[10:51:17] <cescoffier> as new components are going to appear and work load too

[10:52:18] <purplefox_> another related thing we should discuss is assignment of 3.1 tasks

[10:52:55] <pmlopes> yes when should we do that?

[10:52:59] <cescoffier> Was thinking doing that on Friday during the meeting

[10:53:35] <cescoffier> we could add a column in the spreadsheet and say what we would like to do

[10:54:41] <purplefox_> some of the stuff is pretty obvious - like Ceylon - julien ;)

[10:54:49] <purplefox_> other stuff is not us

[10:54:51] <cescoffier> I would like to do the Starter class

[10:55:16] <purplefox_> sounds good to me

[10:55:33] <purplefox_> let me just add names by the obvious stuff for now…

[10:56:27] <temporalfox> I've been sharing my time between ceylon and shell recently

[10:56:56] <purplefox_> ok i've added some names, could you take a look?

[10:57:57] <cescoffier> where ?

[10:58:06] <purplefox_>

[10:58:08] <purplefox_> scroll down

[10:58:31] <purplefox_> redeploy is up for grabs

[10:58:55] <cescoffier> the redeploy is part of the starter class refactoring

[10:58:57] <temporalfox> I believe clement would be fine with it :-)

[10:59:02] <purplefox_> ok fine

[10:59:23] <purplefox_> dns based discovery

[10:59:24] <temporalfox> I would mind working on event bus transport plugable at some point

[10:59:30] <cescoffier> I will also do the DNS based discovery as it's mainly for docker / openshift

[10:59:52] <purplefox_> ha, i just grabbed the event bus one.. but maybe we can work together on it :)

[10:59:59] <temporalfox> but maybe purplefox_ you prefer to do it :-)

[11:00:09] <temporalfox> purplefox_ no problem

[11:00:17] <temporalfox> I spent some time on event bus internal and bug fixes

[11:00:22] <temporalfox> I just feel familiar with it

[11:00:29] <purplefox_> my slight concern with you julien is we only have you partially, and ceylon is you're “official” focus ;)

[11:00:30] <temporalfox> we'll do like the worker

[11:00:31] <pmlopes> i can try to look at the tcp socket bridge

[11:00:39] <temporalfox> you do the impl and I find the bugs :-)

[11:00:42] <purplefox_> lol

[11:00:58] <purplefox_> so i write the bugs, then you make it usable? seems like a fair deal ;)

[11:00:58] <temporalfox> yes you are right

[11:01:13] <temporalfox> given that I also want to do some metrics SPI improvements for shell

[11:01:22] <temporalfox> to expose more internals interactively

[11:01:24] <cescoffier> they are tasks not listed here around the eventbus.js (Node.JS compatibility, API update)

[11:01:51] <temporalfox> one non official task I would actually claim

[11:01:57] <temporalfox> (like eventbus that clement said)

[11:02:09] <temporalfox> is codegen usability / improvements

[11:02:19] <purplefox_> right, so the roadmap list is just the larger high level tasks

[11:02:19] <temporalfox> to have other use it

[11:02:24] <temporalfox> but it's implicit

[11:02:26] <purplefox_> there are a bunch of other smaller tasks and fixes to do

[11:02:33] <purplefox_> maybe we should capture *everything* as issues?

[11:03:27] <cescoffier> yes, we should

[11:03:45] <cescoffier> I was even thinking opening mirror issues on vertx-3/issues for issues on BZ

[11:03:54] <cescoffier> just to visualize them in waffle

[11:04:01] <temporalfox> I think we should capture ideas but not go in the trap to have too many fine grained issues

[11:04:02] <pmlopes> yes i agree otherwise we loose track

[11:05:23] <cescoffier> Most of these tasks are going to be umbrellas anyway

[11:06:25] <purplefox_> sounds reasonable

[11:06:36] <purplefox_> i think we should also consider using milestone tags in GH issues

[11:06:38] <cescoffier> So we should create the high level task and each implementor can refer to these issues when doing some work

[11:06:42] <purplefox_> so we can say which release they are due on

[11:07:01] <purplefox_> cescoffier: +1

[11:07:34] <purplefox_> and then we also go through all other issues and tag them with milestone 3.1 if they are going in 3.1 (?)

[11:07:54] <cescoffier> ok

[11:08:06] <cescoffier> I can create the issues if you want

[11:08:52] <purplefox_> sounds good

[11:08:53] <purplefox_> thanks

[11:09:15] <purplefox_> bugzilla is still a pain, of course. I hate having to also manage issues there :(

[11:09:27] <cescoffier> will do that today (once I finish the vertx-web exampels automation)

[11:09:35] <purplefox_> hmm, i wonder if we can mirror bz core issues

[11:10:04] <purplefox_> i.e. every time we enter a BZ for vertx-core (as eclipse mandates) we can also open a corresponding issue in vertx-core github issues

[11:10:11] <purplefox_> then we can see everything nicely in waffle

[11:10:12] <cescoffier> I can have a look, I've seen a web site doing the mirroring

[11:10:29] <purplefox_> ah if it's automatic even better :)

[11:10:40] <purplefox_> that would be a killer

[11:12:37] <cescoffier> I let you know today

[11:22:06] <purplefox_> temporalfox: could you ask thomas segismont if he is happy to be the official maintainer for the hawkular metrics, and point him in the direction of so he knows the expectations and responsibilities?

[11:22:22] <temporalfox> yes I will ask him

[11:22:31] <purplefox_> thanks

[11:22:43] <temporalfox> he's maybe on holidays now so don't expect an quick answer :-)

[11:26:00] <cescoffier> pmlopes: are you around ?

[11:28:05] <cescoffier> purplefox_ did you have time to have a quick look to the introduction to Vert.x post series ?

[11:32:38] <pmlopes> yes i am

[11:32:58] <cescoffier> pmlopes: in the realtime angular js example, we have quite some JS libraries

[11:33:13] <cescoffier> in the js3rdparty directory

[11:33:23] <cescoffier> other examples don't have this and use CDN

[11:33:32] <cescoffier> is it on purpose ?

[11:33:34] <pmlopes> no

[11:34:12] <pmlopes> i think it can be refactored to use only CDNs

[11:37:27] <cescoffier> ok, so I don't have to test that files are served ;-)

[11:38:11] <cescoffier> I just have cors to do and I cover all web examples

[11:41:52] <purplefox_> pmlopes: cescoffier: temporalfox: i think we should also consider having a periodic “vert.x committer” Bluejeans (?) meeting every so often, to discuss roadmap with the other vert.x committers who aren't all going to be Red Hat folks

[11:42:09] <purplefox_> i.e. it wouldn't be an internal meeting

[11:42:16] <temporalfox> some open source projects do that with google hangouts

[11:42:26] <temporalfox> I remember I did a couple with jenkins team

[11:42:28] <purplefox_> +1

[11:42:31] <temporalfox> just to see how it was

[11:42:44] <pmlopes> in that case shouldn't we use google hanghouts? or can anyone join bluejeans

[11:42:48] <purplefox_> i'm thinking maybe we could do that once per month

[11:42:58] <cescoffier> yes, that would be good to do them periodically

[11:43:17] <cescoffier> anyone can join bluejean if they have an invitation BUT people prefer hangout

[11:43:37] <purplefox_> both bj and google hangouts has pros and cons:

[11:43:43] <purplefox_> bluejeans: doesn't work on chrome on linux

[11:43:55] <purplefox_> google hangouts: requires google+ account

[11:44:24] <purplefox_> from a technical point of view i prefer google hangouts

[12:02:10] <purplefox_> pmlopes: would you like to be the maintainer for the JS Vert.x language implementation?

[12:02:44] <pmlopes> humm yes, i need to get acquainted with the code though

[12:03:22] <purplefox_> maybe this would be good for you as it would get you aquainted with the codegen stuff

[12:03:55] <purplefox_> temporalfox: And you julien the groovy lang impl too i guess, unless you can think of anyone else?

[12:05:47] <aesteve> hi everyone :)

[12:06:02] <purplefox_> hi

[12:06:18] <aesteve> pmlopes: since you're the vertx-web guru maintainer, maybe you could tell me if is OK ?

[12:10:08] <pmlopes> why does the renderTemplate needs to be run inside executeBlocking? template is already in memory i guess so theoretically no blocking operations should happen right?

[12:11:25] <purplefox_> pmlopes: i think it's because it just might take a long time, if the template / data is big

[12:11:32] <purplefox_> but i think the executeBlocking should be configurable

[12:11:42] <purplefox_> because in many cases it will be very quick

[12:12:15] <aesteve> yes I was concerned about rendering in case Context.Data() contains a lot of stuff, or the template loops on something huge

[12:12:38] <aesteve> more than configurable, adaptative would be awesome

[12:12:57] <purplefox_> I would default _not_ use executeBlocking but allow it as an option for those user where rendering is slow

[12:13:10] <purplefox_> adaptable would be great, but it's also hard to get it right

[12:13:26] <cescoffier> purplefox_ temporalfox pmlopes : All web examples have been automated…. Results soon.

[12:13:35] <pmlopes> cool!

[12:13:54] <aesteve> not sure if I dreamed it but didn't you tell someone on the user group that for template rendering you used some kind of adaptative blocking/non-blocking ?

[12:15:46] <purplefox_> that's in statichandler

[12:15:57] <purplefox_> but we should really make it general

[12:17:04] <aesteve> Anyway, how would you make it configurable ? Because it's rmore a template/template, or even worse, context/context

[12:17:58] <aesteve> eg : a template loops on and does heavy stuff

[12:18:24] <aesteve> and obviously, is fetched from database…

[12:18:48] <aesteve> in this case, there's no way the user can tell if it's gonna be slow when creating the template engine

[12:21:53] <aesteve> the only thing I'd see is like a “criteria API” like “boolean isBlocking(String templateFileName, RoutingContext context)” returning false by default, and the user would derive GroovyTemplateEngine if needed ?

[12:21:58] <aesteve> but that seems overkill

[12:23:27] <purplefox_> aesteve: just a boolean flag when creating the template engine i was thinking

[12:23:37] <purplefox_> or even in the template handler

[12:24:30] <aesteve> yeah maybe. I'm not sure that suits the use case well

[12:25:02] <aesteve> a templateHandler will potentially handle a lot of templates, most of them are simple but a single one is “dangerous”

[12:25:40] <aesteve> well I'm not sure but I'll do that. “When in doubt, go for the easy implementation”.

[12:30:41] <purplefox_> indeed. we can always do more sophisticated implementations later. and at least this allows a user to separate out their slow templates from their fast ones and use different template handlers if there is an issue

[12:32:16] <purplefox_> aesteve: hmm just a thought…

[12:32:46] <purplefox_> users can already make any template handler blocking by just setting it as blocking handler no?

[12:32:48] <purplefox_> route().blockingHandler(TemplateHandler.create(..));

[12:33:02] <purplefox_> so i guess a boolean flag is redundant

[12:34:47] <aesteve> indeed

[12:35:03] <aesteve> i thought I had written it

[12:35:12] <aesteve> I thought it out loud… maybe

[12:36:17] <aesteve> so, no boolean flag, no execute blocking on rendering, and let's keep in mind we could reuse the adaptative static handler in such situations

[12:36:26] <aesteve> are you fine with that ?

[12:36:58] <purplefox_> agreed

[12:37:23] <purplefox_> at some point in the future we should considering making blockingHandler more smart - i.e. adaptive

[12:37:34] <aesteve> ok I write it down in the PR and I'll fix it

[12:38:21] <purplefox_> but in any case, paulo is the maintainer here, this is just my suggestion :)

[12:39:33] <aesteve> I've added a note in the PR, and I'll see what Paole thinks after lunch

[12:39:42] <aesteve> Bon app[unknown:eacute]tit, and thanks

[12:42:11] <purplefox_> cescoffier: can this one be closed now?

[12:50:10] <purplefox_> temporalfox: cescoffier pmlopes: i'm thinking we should have another google group for vertx-committers

[12:50:16] <purplefox_> which only vertx-committers can post to

[12:50:41] <purplefox_> where we can discuss voting in new committers, new components etc, or roadmap discussions relating to the official stack

[13:05:00] <cescoffier> purplefox_: temporalfox wanted to look at the maven / npm stuff

[13:05:10] <cescoffier> that's why its not merged yet

[13:05:46] <purplefox_> ok, np

[23:51:32] <jtruelove> this code looks funny

[23:51:48] <jtruelove> why does last take this parameter it totally ignores

[23:52:18] <jtruelove> true or false it's going last it seems