Differences
This shows you the differences between two versions of the page.
— |
irc:1436911200 [2017/05/27 13:44] (current) |
||
---|---|---|---|
Line 1: | Line 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 https://github.com/vert-x3/vertx-examples/tree/master/jdbc-examples 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 https://github.com/vert-x3/vertx-examples/blob/master/jdbc-examples/src/main/groovy/io/vertx/example/jdbc/query_params/jdbc_example.groovy | ||
+ | |||
+ | [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 https://github.com/vert-x3/wiki/wiki/Vert.x-3-Official-stack-and-component-maintainers 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_> https://github.com/vert-x3/wiki/wiki/Vert.x-Roadmap | ||
+ | |||
+ | [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 https://github.com/vert-x3/wiki/wiki/Vert.x-3-Official-stack-and-component-maintainers 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 https://github.com/vert-x3/vertx-web/pull/130 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 context.data and does heavy stuff | ||
+ | |||
+ | [12:18:24] <aesteve> and obviously, context.data() 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? https://github.com/vert-x3/vertx-web/issues/137 | ||
+ | |||
+ | [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 https://github.com/vert-x3/vertx-web/blob/master/src/main/java/io/vertx/ext/web/impl/RouteImpl.java#L132 | ||
+ | |||
+ | [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 | ||