Symfony Core Meeting May 21

logs.txt

[2015-05-21 10:58:10] <weaverryan> Hey everyone :) - we'll begin in exactly 2 minutes
[2015-05-21 10:58:51] <Iltar> Heya Ryan, welcome to those that are usually not lurking in this area :D
[2015-05-21 10:59:04] <WouterJ> afternoon everyone :)
[2015-05-21 10:59:34] → MaxVandervelde joined (~Maxwell@173-8-114-13-Minnesota.hfc.comcastbusiness.net)
[2015-05-21 11:00:13] <weaverryan> Ok! Welcome
[2015-05-21 11:00:22] <weaverryan> The format today will be 3 topics: 20 minutes each
[2015-05-21 11:00:24] <fabpot> Hi everyone!
[2015-05-21 11:00:36] <jakubzalas1> hi
[2015-05-21 11:00:38] <nicolasgrekas> Hello!
[2015-05-21 11:00:39] <ewgra> hi
[2015-05-21 11:00:42] <weaverryan> o/
[2015-05-21 11:00:44] <xabbuh> hi
[2015-05-21 11:00:52] <weaverryan> The topics are:
[2015-05-21 11:00:52] <weaverryan> A) core team organization (Fabien)
[2015-05-21 11:00:52] <weaverryan> B) issue tagging / organization / issue/PR triaging (Jakub and Nicolas)
[2015-05-21 11:00:52] <weaverryan> C) PSR-7 implementation plan (everyone)
[2015-05-21 11:01:01] <weaverryan> If we finish something early, we can move on to the next topic early.
[2015-05-21 11:01:10] <weaverryan> Try to keep too much noise down and stay focused on the topic - we're short on time! If someone is getting off-topic, as moderator, I may remind them to keep things on topic.
[2015-05-21 11:02:21] <Tobion> hey everybody
[2015-05-21 11:02:35] <weaverryan> I see most people I expected (except maybe Stof?)
[2015-05-21 11:02:40] <dunglas> Hi
[2015-05-21 11:02:54] → bestform joined (~Thunderbi@HSI-KBW-46-237-213-5.hsi.kabel-badenwuerttemberg.de)
[2015-05-21 11:03:00] → umulmrum joined (~umulmrum@HSI-KBW-46-237-213-5.hsi.kabel-badenwuerttemberg.de)
[2015-05-21 11:03:10] → Stof joined (~Stof@nautica.notk.org)
[2015-05-21 11:03:22] <Stof> hi
[2015-05-21 11:03:31] <umulmrum> hi
[2015-05-21 11:03:35] <bestform> o/
[2015-05-21 11:03:41] <weaverryan> I was just looking for you Stof ;)
[2015-05-21 11:04:02] <weaverryan> First topic: core team organization - fabpot - can you start?
[2015-05-21 11:04:11] <fabpot> sure
[2015-05-21 11:04:25] <fabpot> So, we re-introduced the notion of a core team some time ago now
[2015-05-21 11:04:40] <fabpot> the main goal was to scale Symfony
[2015-05-21 11:05:00] <fabpot> before the core team, I was the only one to be able to merge PRs (and I was the only one to have right access anyway on the repo)
[2015-05-21 11:05:04] <fabpot> and we have ~10 members today
[2015-05-21 11:05:09] ← jakubzalas left (uid88514@gateway/web/irccloud.com/x-rkyvxvpvwutaufcs)
[2015-05-21 11:05:23] * jakubzalas1 is now known as jakubzalas
[2015-05-21 11:05:25] ⇐ Pindabeer quit (~Pindabeer@81.83.15.74): Ping timeout: 250 seconds
[2015-05-21 11:05:28] <Stof> 13 members to be exact
[2015-05-21 11:05:37] <fabpot> The main idea is to give more "power" to the community (or at least to people who spend a lot of time on Symfony)
[2015-05-21 11:06:25] <fabpot> First, I want to know if the core team works well enough or if we can improve the way we are working
[2015-05-21 11:07:01] <fabpot> I have some ideas to improve our current way, but I will first let you give feedback
[2015-05-21 11:07:16] <fabpot> you == the current core team and anyone participating today :)
[2015-05-21 11:07:51] <dunglas> Maybe are we lacking of a public plan of what we want to implement (some kind of todo list) ?
[2015-05-21 11:08:15] <Iltar> I think it works well. It would be nice to be able to quickly glance quickly and see the ones working on that specific part, like you /cc'd my BC break a few days ago.
[2015-05-21 11:08:30] <weaverryan> dunglas: agreed - but that may be solved by these meetings where we can decide big direction
[2015-05-21 11:09:02] <nicolasgrekas> we are maybe too few to effectively merge PRs
[2015-05-21 11:09:02] → baptiste_ joined (58aec926@gateway/web/freenode/ip.88.174.201.38)
[2015-05-21 11:09:02] <jakubzalas> I lack visibility to the process and what's going to happen with specific issues (is it going to be considered for the next release? is it going to be accepted at all? etc)
[2015-05-21 11:09:07] <fabpot> truth is we don't need big plans, but mainly what to do next (4 months vs 2 years)
[2015-05-21 11:09:35] <nicolasgrekas> when fab is away, the number of PR growth
[2015-05-21 11:09:35] <jakubzalas> agreed
[2015-05-21 11:09:49] <weaverryan> reminder: the PR/issue triaging topic is next ;)
[2015-05-21 11:09:54] <fabpot> jakubzalas: we are working on a timed release, so whatever can be merged in the 4 months of dev for a release is in
[2015-05-21 11:09:58] <weaverryan> I think components that have non-fabpot mergers/maintainers are healthier because there is one person responsible for just a small part - like if there is a translation issue, there is one person quite responsible (aitboudad)
[2015-05-21 11:10:09] <fabpot> weaverryan: agreed
[2015-05-21 11:10:31] <WouterJ> as a concept, I think the core team works well. But I think it kind of overgrow the GitHub issue tracker, resulting in what jakub is saying: There is not a lot of overview for people if they open an issue or PR
[2015-05-21 11:10:33] <Iltar> Yup, that works very nicely
[2015-05-21 11:10:34] <fabpot> ideally, we should have one non-fabpot commiter for all components
[2015-05-21 11:10:45] <xabbuh> maybe we can find other mergers besides fabpot for some components
[2015-05-21 11:10:46] <Tobion> I think it works quite well. One thing that bothered me was the limited merging rights to certain components. It's somewhat unrealistic because often PRs cover several componts/bundles/briges.
[2015-05-21 11:10:47] <weaverryan> fabpot +1
[2015-05-21 11:11:41] <nicolasgrekas> agree with tobion also: I already merged (trivial) PRs on other components than mine
[2015-05-21 11:11:42] <fabpot> xabbuh: I'm all for it but who?
[2015-05-21 11:11:57] <nicolasgrekas> I need the law to chance so I'm not outlawed anymore :)
[2015-05-21 11:12:07] <nicolasgrekas> s/chance/change/
[2015-05-21 11:12:08] <fabpot> nicolasgrekas: that's something I want to change in the current official rules -> let everyone in the core team to merge trivial PRs or PRs with 2 +1s
[2015-05-21 11:12:42] <WouterJ> I also think there should be some "rules" for issues
[2015-05-21 11:12:44] <xabbuh> fabpot: not sure, which components don't have a dedicated merger right now?
[2015-05-21 11:12:45] <Stof> Tobion: changes in bridges/bundles are generally related to a given component anyway. In this case, the component merger is the right one to merge too
[2015-05-21 11:13:15] <weaverryan> +1 and if there is overlap, ping the maintainer from the other component
[2015-05-21 11:13:35] <Stof> weaverryan: yeah
[2015-05-21 11:13:40] <fabpot> and anyway, we need 2 +1s, if you have them, just merge
[2015-05-21 11:14:45] <fabpot> xabbuh: most of the components don't have a dedicated merger. I would say Routing, Translation, Serializer, Process, DomCrawler are taken care of pretty well (I might have missed one or two)
[2015-05-21 11:14:55] → lsmith joined (sid5594@gateway/web/irccloud.com/x-iwssvxynxbxbvneo)
[2015-05-21 11:15:01] <weaverryan> if we don't have people who can be a "merger" for a component, then set the goal lower: find someone who can be a "maintainer" (or something) - no merge rights (yet), but someone who commits to being accountable for issues/PR's - still not easy, but easier to find
[2015-05-21 11:15:18] <lsmith> sorry. thought it was 17:30
[2015-05-21 11:15:34] <weaverryan> no worries lsmith - but I was missing you :)
[2015-05-21 11:15:40] <fabpot> weaverryan: I think we cannot "find" people. They should already be contributing
[2015-05-21 11:16:06] ⇐ NoTriX quit (~vaidaslaz@88-119-193-69.static.zebra.lt): Ping timeout: 264 seconds
[2015-05-21 11:16:09] <fabpot> for instance, Iltar is someone who contribute often and regularly, so he is definitely a good "candidate"
[2015-05-21 11:16:24] <fabpot> contributing == code but also core review, comments, ...
[2015-05-21 11:16:43] <Stof> Components officially without a merger (in 2.8): Asset, ClassLoader, CssSelector, ExpressionLanguage, Filesystem, Finder, Security, Templating, Yaml
[2015-05-21 11:16:48] <weaverryan> (5 minute warning on this topic)
[2015-05-21 11:18:44] <weaverryan> So, do we like the idea of experimenting with this new role of maintainer (cooler word)? With a goal that all components have at least one non-fabpot merger / maintainer?
[2015-05-21 11:18:44] <Tobion> How about just saying that every Core member is allowed to merge. And rename the role merger to maintainer.
[2015-05-21 11:19:00] <dunglas> +1 for Iltar
[2015-05-21 11:19:17] <Tobion> thus maintainers have 2 votes (just as mergers now)
[2015-05-21 11:19:20] <fabpot> Tobion: agreed, if something has at least 2 +1s, any core team member can merge
[2015-05-21 11:19:23] <Stof> But I recognize that I'm much less active than 1 year ago (I'm not as regular at looking at issues/PR), so it does not help (given that I was not limiting myself to components where I'm merger)
[2015-05-21 11:20:08] <Stof> Tobion: if everyone gets 2 votes, it does not make sense to have a x2
[2015-05-21 11:20:11] <fabpot> weaverryan: looks lke a good idea but finding the right people is the hard thing
[2015-05-21 11:20:14] <WouterJ> doesn't it make more sense to be limited on the voting process instead of the merging process?
[2015-05-21 11:20:36] <WouterJ> as, unless I'm missing something, merging doesn
[2015-05-21 11:20:40] <fabpot> the more people with the +1 power, the better
[2015-05-21 11:20:41] <Tobion> no normal members have +1 and maintainers have +2 for their stuff
[2015-05-21 11:20:43] <fabpot> merging is the easy part
[2015-05-21 11:21:05] <aitboudad> can we reserve one day every week for voting, this can improve and simplify the workflow ?
[2015-05-21 11:21:09] <Stof> and in practice, I'm not sure we use this rule much. Most of the time, we are still getting 2 real +1s anyway
[2015-05-21 11:21:14] <weaverryan> workflow is next :)
[2015-05-21 11:21:41] <Stof> which is a good thing IMO as it means we got 2 different minds on the subject
[2015-05-21 11:21:46] <fabpot> weaverryan: I will propose some changes in the rules taking into account the discussion
[2015-05-21 11:21:48] ← DanielBadura left (~DanielBad@b2b-94-79-164-206.unitymedia.biz)
[2015-05-21 11:22:18] <weaverryan> fabpot: Perfect. Then should we move on? We can always visit future changes at a future meeting.
[2015-05-21 11:22:32] <fabpot> sure, let's move on
[2015-05-21 11:22:43] <fabpot> I'm sure the second topic will have an impact on the first one :)
[2015-05-21 11:22:56] <weaverryan> B) issue tagging / organization / issue/PR triaging (jakubzalas and nicolasgrekas)
[2015-05-21 11:23:19] <dunglas> Personally, I'm not confident in merging code without another +1 from a core team member (for my stuff or other). It's why some PR on the Serializer component are sometimes slow to be merged.
[2015-05-21 11:23:27] <weaverryan> jakubzalas Perhaps you can intro us since you are a very active "triager"?
[2015-05-21 11:23:51] <Stof> dunglas: for your own stuff, you need it anyway as you cannot vote on your own PRs
[2015-05-21 11:24:01] <fabpot> dunglas: for new features, the worst that can happen is that we reverse something, so be more confident ;)
[2015-05-21 11:24:34] <dunglas> fabpot: except is nobody take a look at it
[2015-05-21 11:24:34] <weaverryan> New features == potential for hard BC breaks later when things aren't right :)
[2015-05-21 11:24:42] <dunglas> (even after the merge)
[2015-05-21 11:25:07] ⇐ egabor quit (5665d868@gateway/web/freenode/ip.86.101.216.104): Quit: Page closed
[2015-05-21 11:25:11] <jakubzalas> Which brings us to the next topic ;)
[2015-05-21 11:25:11] <weaverryan> Well, that's as good as an intro to this topic as any, so let me summarize and get us started
[2015-05-21 11:25:15] <jakubzalas>  in order to help us to know which PRs are pending Nicolas introduce the "Ready" label
[2015-05-21 11:25:21] <weaverryan> Perfect :)
[2015-05-21 11:25:21] <jakubzalas> do you find it helpful?
[2015-05-21 11:25:45] <weaverryan> I am not as active in core as others, but I haven't used it yet
[2015-05-21 11:26:03] <jakubzalas> 'cause i found it to work better then pinging @symfony/deciders
[2015-05-21 11:26:17] <jakubzalas> as ping is a one off trigger, while i can always go to github and filter by "Ready"
[2015-05-21 11:26:20] <fabpot> jakubzalas: the problem is that you don't get notifications for a tag, you do with a ping
[2015-05-21 11:26:37] <fabpot> filtering is indeed a great way to know what to merge
[2015-05-21 11:26:44] <fabpot> and I used it lately to merge pending PRs
[2015-05-21 11:26:56] <nicolasgrekas> doing both ping+tag is better than only one of them
[2015-05-21 11:27:10] <fabpot> but we need to remove the tag when it's not ready anymore (comments from a core team member asking for changes)
[2015-05-21 11:27:11] <weaverryan> +1
[2015-05-21 11:27:19] <Iltar> As someone who likes to check PRs and review them, I like the Ready label, just to look through again or omit checking at Al.
[2015-05-21 11:27:20] ⇐ Spartan- quit (51ad713e@gateway/web/freenode/ip.81.173.113.62): Quit: Page closed
[2015-05-21 11:27:23] <nicolasgrekas> and reviewing the list of pending pr is easier now, for me at least
[2015-05-21 11:27:33] <WouterJ> we use it for about a year or so in the docs and it has helped us a lot. Does it makes sense to also add labels for the voting process, so deciders can also quickly see which PRs need their opinion?
[2015-05-21 11:27:36] <dunglas> Maybe a the ping can be used in last resort when the PR lack reviews
[2015-05-21 11:27:48] <lsmith> i am using waffle.io to better track whats going on in the various projects i am involved in .. since github email notifications are an utter fail. for example https://waffle.io/friendsofsymfony/friendsofsymfony.github.com
[2015-05-21 11:28:04] <lsmith> but waffle sucks for collaboration .. because they do not really honor github rights
[2015-05-21 11:28:18] <jakubzalas> WouterJ: that's what i was about to suggest. learn from the docs team experience
[2015-05-21 11:28:34] <fabpot> a little off-topic but we have another problem with the current process: old PRs have almost no chance to be merged
[2015-05-21 11:28:37] <jakubzalas> would be good to think of the workflow and introduce proper labels
[2015-05-21 11:28:41] <WouterJ> (waffle does honor github rights, github rights are the one making collaboration difficult)
[2015-05-21 11:28:42] <fabpot> as there are so many new PRs coming every day
[2015-05-21 11:28:50] <jakubzalas> or perhaps milestones for major releases
[2015-05-21 11:28:53] <fabpot> so, we tend to favor (at least for me) easy PRs
[2015-05-21 11:29:17] <lsmith> WouterJ: what I mean is .. nobody can use “my” waffle boards to move things around. even if they have the right to add tags
[2015-05-21 11:29:25] <jakubzalas> fabpot: that's why i think the workflow needs to be more visible
[2015-05-21 11:29:46] <jakubzalas> so PR's author would know we're not considering his PR for next release
[2015-05-21 11:29:51] <jakubzalas> and he can complain
[2015-05-21 11:30:06] <romainneutron>  that’s something we need to address yes
[2015-05-21 11:30:11] <Iltar> Personally I like the kanban board style, waffle.IO comes close to that from what I saw
[2015-05-21 11:30:56] <Stof> there is also an issue about the review of issues. Previously, I was reviewing new issues quite fast so it was OK, but I recently found a 4 months old issue without any comment on it for instance
[2015-05-21 11:31:15] <Stof> We should be alerted faster than that about such cases
[2015-05-21 11:31:42] <MaxVandervelde> is there a point that a PR becomes too "stale" to merge? I assume there's a line that if there hasn't been an update on it in x months, it's as good as dead.
[2015-05-21 11:32:07] ⇐ baptiste_ quit (58aec926@gateway/web/freenode/ip.88.174.201.38): Ping timeout: 246 seconds
[2015-05-21 11:32:17] <Iltar> With a list of who is on what component, I could check those and ping the right person if I can't help nor point them in the right direction
[2015-05-21 11:32:19] <Stof> I even talked about that with Grégoire Pineau about this as he played with the github API to build some reporting
[2015-05-21 11:32:42] <fabpot> MaxVandervelde: not really, sometimes, I'm merging some PRs that are very old, just because we missed them
[2015-05-21 11:32:48] <fabpot> missed == forgot about
[2015-05-21 11:33:04] <jakubzalas> Iltar: if we could filter easily by what's ready to merge  / what's ready to review / what's blocked etc
[2015-05-21 11:33:09] <jakubzalas> pinging wouldn't be needed
[2015-05-21 11:33:42] <nicolasgrekas> what about using milestones ?
[2015-05-21 11:33:45] <Stof> jakubzalas: this assumes that PRs are labelled properly though, which is also an issue for forgotten PRs :)
[2015-05-21 11:33:50] <nicolasgrekas> 2.7 2.8 etc?
[2015-05-21 11:34:23] <fabpot> nicolasgrekas: that does not really make sense
[2015-05-21 11:34:27] <nicolasgrekas> a pr being in a milestone meaning that a core member thinks this should be in the next release of this branch ?
[2015-05-21 11:34:32] <fabpot> it's part of the release based on when it's merged
[2015-05-21 11:34:33] <xabbuh> nicolasgrekas: I recently wanted to do that as I am used to add milestones in the docs and I was wondering if there was a particular reason that the only existing milestone is 3.0
[2015-05-21 11:34:35] <jakubzalas> Stof: yes, but than a person interested in that PR being merged can ping :)
[2015-05-21 11:34:44] <romainneutron> I’m not sre it would work nicolasgrekas , what’s in 2.8 is what’s been produced after 2.7 :)
[2015-05-21 11:34:49] <romainneutron> it’s not what has been planned
[2015-05-21 11:34:50] <WouterJ> btw, the problem with both adding labels/milestones and pinging is that only core team members can do it. So forgotten PRs/issues aren't solved this way
[2015-05-21 11:35:00] <jakubzalas> nicolasgrekas: i was thinking the same. However, a "NExt Release" label might work just as well
[2015-05-21 11:35:02] <weaverryan> xabbuh: It's easier in the docs, because the code feature is already merged into a version
[2015-05-21 11:35:18] <Tobion> Is it possible to filter issues in github where I participated? I can filter where I was mentioned, but not where I commented myself?
[2015-05-21 11:35:43] <Stof> Tobion: add commenter:Tobion in the search field
[2015-05-21 11:35:51] <Tobion> because I sometimes like to work off issues that are waiting feedback or staled for some reason but I already participated in
[2015-05-21 11:36:05] <fabpot> jakubzalas: but all PRs are for the next release if this is a new feature
[2015-05-21 11:36:05] <Stof> WouterJ: pinging is possible with anyone allowed to comment (i.e. everyone)
[2015-05-21 11:36:18] <fabpot> so, we might add "bug fix" and "new feature" tags?
[2015-05-21 11:36:22] <WouterJ> Stof: this does not apply to groups, I can't ping @symfony/deciders
[2015-05-21 11:36:32] <WouterJ> you have to be part of that group to do it
[2015-05-21 11:36:33] <romainneutron> +1 on this fabpot
[2015-05-21 11:36:46] <romainneutron> and minor
[2015-05-21 11:36:52] <Stof> WouterJ: really ? Maybe you just don't get autocompletion, but I think you still mention them
[2015-05-21 11:36:52] <romainneutron> as well as for commit messages
[2015-05-21 11:37:00] <jakubzalas> fabpot: yes, but that doesn't mean it'll go for the next release. by labeling an issue we communicate our intent is to include it
[2015-05-21 11:37:16] <fabpot> nope, I don't want to communicate an intent
[2015-05-21 11:37:23] <weaverryan> To keep us focused: the problem is that PR's get lost or stall because of lack of commenting, etc
[2015-05-21 11:37:25] <nicolasgrekas> a wish ?
[2015-05-21 11:37:28] <fabpot> again, our releases are time based, not feature based
[2015-05-21 11:37:29] <lsmith> agree we should add tags for bugs, enhancement
[2015-05-21 11:37:34] <weaverryan> (and we have about 5 minutes left)
[2015-05-21 11:37:42] <jakubzalas> we already have those tags i think
[2015-05-21 11:37:48] <Stof> jakubzalas: if it is not merged before the feature freeze, it won't go in it. We won't delay a release
[2015-05-21 11:37:54] <lsmith> or rather use those tags :)
[2015-05-21 11:37:55] <fabpot> the problem is that we don't have enough people reviewing complex PRs
[2015-05-21 11:38:05] <fabpot> and core team members are not confident enough to merge them (me included)
[2015-05-21 11:38:17] <Stof> we also don't have enough people reviewing issues btw
[2015-05-21 11:38:27] <fabpot> Stof: exactly
[2015-05-21 11:38:28] <MaxVandervelde> Would it help to have better labels around priority, complexity, and severity?
[2015-05-21 11:38:36] <weaverryan> Agreed. Having a maintainer for each component could help this - you can focus on the issues that you are responsible for - and triagers can ping the right person
[2015-05-21 11:38:50] <Stof> and I recognize I spend less time than before on open-source, meaning it could take time before I review things
[2015-05-21 11:38:52] <romainneutron> minor / bug / feature tags would be nice
[2015-05-21 11:38:56] ← Xatenev left (~Xatenev@pd907f4d2.dip0.t-ipconnect.de)
[2015-05-21 11:39:11] <jakubzalas> we already have "Bug" and "Feature" tags
[2015-05-21 11:39:25] <fabpot> so, basically, we move the qualification from the header we have to a tag, looks good to me
[2015-05-21 11:39:41] ⇐ tystr quit (~tystr@do1.tylerstroud.com): Quit: ZNC - http://tylerstroud.com
[2015-05-21 11:39:46] <Stof> weaverryan: but we need to have other people than the maintainer looking at components too. The maintainer should not be left alone on the review
[2015-05-21 11:40:03] <Stof> it is always better to have several people reviewing as they might catch different things
[2015-05-21 11:40:04] <xabbuh> weaverryan: agreed, if it were more about being "responsible" for a component instead of being a merger, I would step forward to be responsible for one or two of them
[2015-05-21 11:40:12] <weaverryan> Yes, you're right - but sometimes it feels like *nobody* is responsible at all
[2015-05-21 11:40:23] <weaverryan> xabbuh: that's cool :)
[2015-05-21 11:40:33] → tystr joined (~tystr@do1.tylerstroud.com)
[2015-05-21 11:41:39] <weaverryan> Ok, we are just about out of time on this topic
[2015-05-21 11:41:59] <weaverryan> Though I'm not sure if we really feel satisfied with solutions?
[2015-05-21 11:42:31] <fabpot> it's really a question of time
[2015-05-21 11:42:53] <fabpot> for instance, if we had all had a look at PRs and tickets during the last 20 minutes, it would have been really helpful :)
[2015-05-21 11:43:00] <nicolasgrekas> we also have prs that are dying but nobody closes
[2015-05-21 11:43:20] → Spartan-- joined (51ccd795@gateway/web/freenode/ip.81.204.215.149)
[2015-05-21 11:43:22] <Tobion> I think the Form component has most issues (alone 150 with form label), but only Berhard is confident enough to resolve them
[2015-05-21 11:43:23] <weaverryan> ha, agreed on both points :)
[2015-05-21 11:43:24] <nicolasgrekas> it's hard to say to someone thaks but no
[2015-05-21 11:43:36] <xabbuh> nicolasgrekas: who will make the decision that a PR should be closed?
[2015-05-21 11:43:41] <Tobion> so they just build up
[2015-05-21 11:43:47] <nicolasgrekas> that's the question :)
[2015-05-21 11:43:49] <weaverryan> Yes, saying "no" is quite difficult
[2015-05-21 11:43:58] <weaverryan> What about 2 -1's from core team?
[2015-05-21 11:44:10] <weaverryan> Then it's not "one" person's "no"
[2015-05-21 11:44:18] <jakubzalas> i think we should think of questions people working (or willing to work) on symfony might want to ask, and than try to answer them (most likely by providing proper labels)
[2015-05-21 11:44:31] <Stof> weaverryan: that's what happened already. But we have very few cases where we actually gave -1
[2015-05-21 11:44:35] <jakubzalas> example: what are the issues I could try to reproduce? Here's the "Unconfirmed" label
[2015-05-21 11:44:38] <nicolasgrekas> we can try with two -1
[2015-05-21 11:44:53] <jakubzalas> why's one -1 not enough?
[2015-05-21 11:45:02] <weaverryan> Ok, I have to stop us - we're totally out of time on this :)
[2015-05-21 11:45:17] <weaverryan> But if needed, we can have this same topic (the next evolution) next meeting
[2015-05-21 11:45:38] <MaxVandervelde> If no solutions yet, being more aware of the problems is progress, at the very least. We should definitely revisit this issue.
[2015-05-21 11:45:40] <Stof> jakubzalas: we are allowed to change our vote based on discussion. So the first -1 cannot automatically be the rejection of the PR
[2015-05-21 11:46:02] <weaverryan> So, to a more technical topic?
[2015-05-21 11:46:04] <weaverryan> C) PSR-7 implementation plan (everyone)
[2015-05-21 11:46:34] <weaverryan> The goal here would be to make sure we agree on the general direction and identify a team/plan to implement it
[2015-05-21 11:46:53] <Stof> OK, I will summarize the current state of the discussion on thethe core team mailing-list
[2015-05-21 11:48:27] <Stof> The goal is to ship some PSR-7 compatibility, but without doing it the ZF-way (rewriting everything in HttpFoundation and HttpKernel) because we decided a long time ago that Sf3 would be an easy upgrade from 2.x (BC for anyone using only non-deprecated features of 2.8 being the goal)
[2015-05-21 11:49:07] <Stof> Adopting PSR-7 at the core is not compatible with this goal because of the different architecture (mutable vs immutable Request and Response)
[2015-05-21 11:49:36] → Druid joined (~smuxi@ip-176-199-16-188.hsi06.unitymediagroup.de)
[2015-05-21 11:49:40] <Stof> My proposal was to ship converters between HttpFoundation and PSR-7 (both ways and for Request and Response)
[2015-05-21 11:50:20] <lsmith> +1
[2015-05-21 11:50:27] <Stof> this way, all the Symfony code would continue to be BC, but we could be compatible with middleware-based setups based on PSR-7 (ZF3 for instance)
[2015-05-21 11:50:46] ⇐ tmporary quit (~textual@194.8.215.34): Quit: My Mac has gone to sleep. ZZZzzz…
[2015-05-21 11:50:50] <fabpot> I agree with Stof and keep in mind that PSR-7 is a really small common denominator anyway, so interoperability will be minimal anyway
[2015-05-21 11:50:53] <lsmith> i think the main benefit for the Symfony ecosystem initially is middleware interoperability which the converters enable
[2015-05-21 11:50:55] <Nicofuma> that make sense
[2015-05-21 11:51:01] <Tobion> Why would symfony need to ship these converters, if symfony doesn't work with psr-7?
[2015-05-21 11:51:06] <Stof> this would allow to have a ZF3 middleware wrapping an HttpKernelInterface and the opposite
[2015-05-21 11:51:13] <Tobion> these converters could be provided by anyone
[2015-05-21 11:51:18] → timg__ joined (~timg__@p4FF27114.dip0.t-ipconnect.de)
[2015-05-21 11:51:23] <lsmith> Tobion: imho they can be a component .. that is separate of symfony/symfony
[2015-05-21 11:51:35] <fabpot> I don't really care aboutZF3 middleware specifically, PSR-7 is about interoperability with the whole ecosystem, that's what matters
[2015-05-21 11:51:37] <lsmith> but we need to make sure this converter component exists
[2015-05-21 11:52:05] <fabpot> I think people will want an "official" Symfony version of these converters/adapters, they should be part of symfony/symfony
[2015-05-21 11:52:09] <lsmith> put imho it should be official
[2015-05-21 11:52:15] <lsmith> fabpot: yeah
[2015-05-21 11:52:18] <Stof> fabpot: agreed. The converter is the prerequisite to build middlewares switching from PSR-7 to HttpFoundation
[2015-05-21 11:52:20] → Iltar_ joined (~Iltar@h46216.upc-h.chello.nl)
[2015-05-21 11:52:31] <weaverryan> agreed - people are already asking for it on Twitter, as if Symfony hasn't noticed PSR-7 happened :)
[2015-05-21 11:52:33] <Stof> the middleware themselves should probably be left to the StackPHP prokect
[2015-05-21 11:52:44] <romainneutron> definitely, if we vote +1 on this PSR, we should provide what’s going with it
[2015-05-21 11:53:02] <Stof> regarding the converters, they can either be in a new component or in a separate repository entirely
[2015-05-21 11:53:09] → dupuchba joined (58aec926@gateway/web/freenode/ip.88.174.201.38)
[2015-05-21 11:53:30] — lsmith nods
[2015-05-21 11:54:09] <Stof> https://github.com/Sam-Burns/psr7-symfony-httpfoundation is trying to implement PSR-7 around HttpFoundation, but I think a converter will end up being much simpler (no need to reimplement the spec)
[2015-05-21 11:54:10] <fabpot> a new component part of symfony/symfony seems like a good idea
[2015-05-21 11:54:12] <xabbuh> imho they don't necessarily have to come with symfony/symfony, they can be a completely separated package, but maintained by the Symfony community, though that's a small detail
[2015-05-21 11:54:13] <Iltar_> Request could be build based on an immutable request from psr7 and an immutable response can be generated based on the response object
[2015-05-21 11:54:20] <Stof> and it would work both ways, which is a requirement for middlewares
[2015-05-21 11:54:43] → egabor joined (598488e5@gateway/web/freenode/ip.89.132.136.229)
[2015-05-21 11:54:43] <weaverryan> So, I think we're agreed that it will be a converter and it will be a new component
[2015-05-21 11:54:45] <lsmith> fabpot: I would put it into a separate repo
[2015-05-21 11:54:52] <lsmith> to make a separate release cycle possible
[2015-05-21 11:55:03] <weaverryan> (added advantage, someone on Symfony 2.3 could bring in the new component)
[2015-05-21 11:55:28] ⇐ Iltar_ quit (~Iltar@h46216.upc-h.chello.nl): Client Quit
[2015-05-21 11:55:29] <Stof> weaverryan: he can already (once we have the subtree) as it will be compatible with older versions of HttpFoundation
[2015-05-21 11:55:43] <fabpot> lsmith: I disagree. One of the strength of the Symfony release cycle is the predictability, having something elsewhere won't be maintained in the same way
[2015-05-21 11:55:44] <Stof> the drawback is that we won't have stable releases until November for this component
[2015-05-21 11:55:57] → Iltar_ joined (~Iltar@h46216.upc-h.chello.nl)
[2015-05-21 11:56:03] ← Nicofuma left (~nicofuma@phpbb/developer/nicofuma)
[2015-05-21 11:56:04] <fabpot> we are doing a lot of changes across the board and everything outside symfony/symfony is never taken into account
[2015-05-21 11:56:07] → Nicofuma joined (~nicofuma@phpbb/developer/nicofuma)
[2015-05-21 11:56:12] ← Nicofuma left (~nicofuma@phpbb/developer/nicofuma)
[2015-05-21 11:56:15] → Nicofuma joined (~nicofuma@phpbb/developer/nicofuma)
[2015-05-21 11:56:27] <Iltar_> What about the SensioFrameworkExtraBundle?
[2015-05-21 11:56:37] <lsmith> but this should not really be affected by “changes across the board"
[2015-05-21 11:56:39] ⇐ Iltar quit (~Iltar@92.69.237.108): Ping timeout: 276 seconds
[2015-05-21 11:56:40] <Stof> Iltar_: this is a SensioLabs bundle, not a Symfony one
[2015-05-21 11:56:47] ⇐ dupuchba quit (58aec926@gateway/web/freenode/ip.88.174.201.38): Client Quit
[2015-05-21 11:56:52] <weaverryan> Btw, it's political/marketing, but Zf3 comes out Q3 this year - our converters should be quite close to this date
[2015-05-21 11:56:54] ⇐ colinodell quit (ad4303ca@gateway/web/freenode/ip.173.67.3.202): Quit: Page closed
[2015-05-21 11:57:06] <Iltar_> But it does feature certain things suggested in the best practices
[2015-05-21 11:57:09] * Iltar_ is now known as Iltar
[2015-05-21 11:57:11] <weaverryan> (5 minute warning)
[2015-05-21 11:57:41] ⇐ umpirsky quit (~umpirsky@cable-178-149-87-209.dynamic.sbb.rs): Quit: umpirsky
[2015-05-21 11:57:42] <weaverryan> Iltar: it can't be in a bundle anyways - it's needed by other projects not using the framework
[2015-05-21 11:57:43] <Stof> I already started thinking about this converter component. I can work on the implementation if you want
[2015-05-21 11:57:48] <fabpot> it really depends on what message we want to convey. If we create an external repo, people will think it is not part of Symfony
[2015-05-21 11:58:10] <Iltar> weaverryan, I was more thinking that it should just be merged into symfony :)
[2015-05-21 11:58:13] <lsmith> symfony/psr7 will be sufficiently official
[2015-05-21 11:58:14] <fabpot> if we want to embrace PSR-7, it needs to be part of the main Symfony repo
[2015-05-21 11:58:14] <Stof> Do we have a name for the new component ?
[2015-05-21 11:58:23] <romainneutron> +1 lsmith
[2015-05-21 11:58:34] <lsmith> i think time to market is more important
[2015-05-21 11:58:47] <lsmith> and we are infact no fully embracing psr-7
[2015-05-21 11:58:50] <weaverryan> I think internal repository - really because it's what we do now for everything else - consistency, let's not make 2 decisions/changes at once
[2015-05-21 11:59:02] <romainneutron> I misunderstood you lsmith I think, I mean a symfony component
[2015-05-21 11:59:32] — Iltar is missing some conversation, ignore what I said
[2015-05-21 11:59:34] → tmporary joined (~textual@194.8.215.34)
[2015-05-21 11:59:47] <fabpot> keeping our BC promise is of course more important than providing PSR-7 support and trying to be as fast as possible, there is really no rush
[2015-05-21 11:59:48] <weaverryan> Could we release a totally new component on a patch release? That's not semver... but it's totally new, and timing is important...
[2015-05-21 12:00:04] <fabpot> why is timing important?
[2015-05-21 12:00:26] <lsmith> because people do want to explore what PSR-7 enables
[2015-05-21 12:00:28] <Stof> weaverryan: this seems bad to me. Semver is one of our pre-requisite too
[2015-05-21 12:00:29] <lsmith> sooner rather than later
[2015-05-21 12:00:31] <weaverryan> Because when Symfony2 beat ZF2 to market, that was quite important - though we're talking months now, not years like then
[2015-05-21 12:00:38] <fabpot> lsmith: I can answer that question: nothing :)
[2015-05-21 12:00:42] <Iltar> Timing isn't as important as the way symfony can market how it follows compatibility
[2015-05-21 12:00:44] ⇐ aRn0D quit (~arnaud@LPoitiers-656-1-122-95.w80-15.abo.wanadoo.fr): Quit: Leaving.
[2015-05-21 12:01:19] <weaverryan> Ok, then Stof will start to work on the (nameless) converter component for a 2.8 release
[2015-05-21 12:01:22] <romainneutron> I don’t think we’re in a hurry for releasing this psr7 component
[2015-05-21 12:01:26] <nicolasgrekas> if timing is that important, we could release a standalone component then merge it when 2.8 is out
[2015-05-21 12:01:32] <fabpot> I think we can deal with timing by showing we are working on something and talk about that openly on our blog
[2015-05-21 12:01:41] <romainneutron> nicolasgrekas proposition is nice
[2015-05-21 12:01:42] <lsmith> fabpot: even if that is the case .. its important to let people find that out sooner .. rather than make them feel like they are behind hindered to try it out
[2015-05-21 12:01:58] <Stof> lsmith: how fast can dev have a project compatible with PSR-7 middlewares: SF, as soon as we release this component; ZF, as soon as they rewrite their project based on ZF3
[2015-05-21 12:02:01] <Stof> => we win
[2015-05-21 12:02:03] <Tobion> Stof: what PSR-7 implementation would be used as converter?
[2015-05-21 12:02:16] <fabpot> nicolasgrekas: +1
[2015-05-21 12:02:16] <fabpot> Stof agreed
[2015-05-21 12:02:23] <lsmith> but given your lack luster excitement about psr-7 .. why do you think it should be in symfony/symfony?
[2015-05-21 12:02:36] <lsmith> Stof: there are already 2 PSR-7 implementations
[2015-05-21 12:02:41] <weaverryan> fabpot +1 - and to lsmith's point, we should announce that there will be a new component in 2.8 as soon as is feasible
[2015-05-21 12:02:49] <Stof> Tobion: for the side PSR-7 -> HttpFoundation, any (depend only on the interface)
[2015-05-21 12:02:53] <fabpot> because we either embrace it fully (by keeping BC) or we don't do anything
[2015-05-21 12:03:03] <fabpot> have a look at the "admin gen" situation for Symfony 2
[2015-05-21 12:03:06] ⇐ akovalyov quit (~akovalyov@cable-178-149-87-209.dynamic.sbb.rs): Ping timeout: 272 seconds
[2015-05-21 12:03:18] <Stof> For the side HttpFoundation -> PSR7, I will use phly/http
[2015-05-21 12:03:21] <fabpot> we have a strong project, Sonata, but a lot of people are relunctant to use it because it's not official
[2015-05-21 12:03:25] <Stof> it is the only complete implementation
[2015-05-21 12:03:25] <Tobion> Stof: and for HttpFoudnation -> PSR-7?
[2015-05-21 12:03:26] ⇐ ruFog quit (~rufog@h37-122-63-35.dyn.bashtel.ru): Remote host closed the connection
[2015-05-21 12:03:38] <Tobion> too late
[2015-05-21 12:03:47] <Stof> guzzlehttp/psr7 does not implement yet the parts specific to the server-side
[2015-05-21 12:03:56] <Stof> because they don't need it for themselves
[2015-05-21 12:04:02] <lsmith> fabpot: but sonata is not on the symfony github organization
[2015-05-21 12:04:10] <lsmith> so its a totally different thing
[2015-05-21 12:04:26] <lsmith> sonata-project/admin-bundle vs. symfony/psr-7
[2015-05-21 12:05:20] <Nicofuma> I'm not really sure that people will see a symfony/psr-7 repo unless there is a lot of activity
[2015-05-21 12:05:20] <fabpot> nicolasgrekas proposal seems like a good start: we create a new repo and we can decide later to integrate it back into symfony/symfony
[2015-05-21 12:05:21] <lsmith> nobody has any doubts that AsseticBundle is official
[2015-05-21 12:05:23] <weaverryan> I think this is a conversation about whether we should split the big repo into little repos - that's a very different conversation
[2015-05-21 12:05:28] <Tobion> what do you think of providing a PSR-7 implementation in smyfony?
[2015-05-21 12:05:31] <Stof> Anyone having an idea about the name ?
[2015-05-21 12:05:35] <fabpot> but being the one who makes the releases, I think it would be much easier to have it in Symfony
[2015-05-21 12:05:59] ⇐ ewgra quit (~ewgra@gchq1.acdm.de): Quit: Leaving.
[2015-05-21 12:06:09] ⇐ woutersioen quit (~woutersio@81.83.29.89): Ping timeout: 240 seconds
[2015-05-21 12:06:11] <nicolasgrekas> agree with fabpot on the release process, and with ryan about this not being the topic :)
[2015-05-21 12:06:18] <lsmith> ok .. that is a different argument .. and obviously one i can hardly say anything about :)
[2015-05-21 12:06:40] <Stof> Tobion: makes no sense IMO. We would only duplicate existing work
[2015-05-21 12:06:40] <weaverryan> Ok, I think we have a plan - but not a name yet!
[2015-05-21 12:06:53] <lsmith> but +1 to a new symfony repo and then deciding later if to put it into symfony/symfony
[2015-05-21 12:07:10] <weaverryan> And also, when could we announce that a component is a WIP? I think a blog post from fabpot would be meaningful - and I hear he has a lot of free time these days
[2015-05-21 12:07:11] <fabpot> name is important as it will be part of the namespace
[2015-05-21 12:07:22] <fabpot> weaverryan: lol
[2015-05-21 12:07:34] <fabpot> Stof is the lead here :)
[2015-05-21 12:07:36] <Stof> Anyone with a idea for the name ?
[2015-05-21 12:07:47] <jakubzalas> Stof: symfony/http-message ? I think it's called Http Message in the spec
[2015-05-21 12:07:53] <WouterJ> (not having followed anything about PSR-7), HttpMessage ?
[2015-05-21 12:07:56] <Stof> I would prefer if I don't need to rename the code namespace
[2015-05-21 12:08:10] <romainneutron> symfony/psr7 is good because it’s explicit
[2015-05-21 12:08:13] <fabpot> symfony/http-message and Symfony\Component\HttpMessage
[2015-05-21 12:08:18] <fabpot> or Symfony\Bridge\PSR7?
[2015-05-21 12:08:26] <lsmith> fabpot: +1 for Bridge
[2015-05-21 12:08:26] <weaverryan> We're out of time - but let's decide the name so we don't delay that
[2015-05-21 12:08:35] <romainneutron> symfony/http-message would be confusing for newcomers alongside symfony/http-foundation or symfony/http-kernel
[2015-05-21 12:08:46] <fabpot> weaverryan: let's take 5 more minutes to agree on a name
[2015-05-21 12:08:47] <Stof> jakubzalas: our component will not represent HTTP messages (this is what HttpFoundation does). It converts  HTTP messages between different representations
[2015-05-21 12:08:49] <jakubzalas> psr7 is not a good name imo
[2015-05-21 12:08:50] <xabbuh> symfony/psr7-bridge?
[2015-05-21 12:08:55] <Iltar> +1 for bridge, that's exactly what it is in my eyes
[2015-05-21 12:09:04] <Stof> and +1 for being in the Bridge namespace rather than in Component
[2015-05-21 12:09:09] <jakubzalas> but you're right it's not what it's about
[2015-05-21 12:09:18] <aitboudad> +1 for bridge
[2015-05-21 12:09:19] <weaverryan> jakubzalas - but the real name is "message interface" which is also very abstract :/
[2015-05-21 12:09:42] <WouterJ> as it's just a bridge, +1 for Symfony\Bridge\Psr7
[2015-05-21 12:09:46] <fabpot> httpmessage or http interface does not convey the fact that it's a bridge between HttpFoundation and PSR7
[2015-05-21 12:09:57] <Stof> I think we all agree in the Bridge part. Can we get ideas on the bridge name now ?
[2015-05-21 12:10:00] <weaverryan> and there is precedence (like in composer.json) to occasionally refer to PSR-0, PSR-4 kind of stuff
[2015-05-21 12:10:05] <jakubzalas> true, it is in fact a bridge to psr7
[2015-05-21 12:10:21] <lsmith> so Symfony\Bridge\PSR7 seems best to me symfony/PSR7Bridge
[2015-05-21 12:10:27] <jakubzalas> so my second thought is Symfony\Bridge\Psr7
[2015-05-21 12:10:33] <lsmith> along the lines of https://github.com/symfony/TwigBridge
[2015-05-21 12:10:49] <fabpot> the repo would be symfony/psr7-bridge (to follow our current/new conventions for components/bridges)
[2015-05-21 12:10:55] <romainneutron> +1
[2015-05-21 12:11:04] <weaverryan> (it is a bride to Psr\Http\Message or psr/http-message)
[2015-05-21 12:11:40] ⇐ dunglas quit (6dbebb8f@gateway/web/freenode/ip.109.190.187.143): Ping timeout: 246 seconds
[2015-05-21 12:11:41] <Iltar> symfony/psr-http-message-bridge?
[2015-05-21 12:11:42] <weaverryan> sorry - but what if psr12 ends up being an evolution of this?
[2015-05-21 12:11:42] <WouterJ> considering the implemented package is called psr/http-message, doesn't it make more sense to do Symfony\Bridge\HttpMessage ? (just like twig/twig has a TwigBridge and doctrine/doctrine a DoctrineBridge)
[2015-05-21 12:12:04] <Stof> fabpot: what would be the process to work on it. Should we create a repo with just a readme and then a PR for the initial implementation ?
[2015-05-21 12:12:16] <fabpot> or what about Symfony\Bridge\FigHttpMessage?
[2015-05-21 12:12:25] <fabpot> Stof: sound like a good plan
[2015-05-21 12:12:33] <Stof> This has not yet happened as the Asset component was created in symfony/symfony directly
[2015-05-21 12:12:41] <weaverryan> fabpot: Symfony\Bridge\PsrHttpMessage since Psr is in the interface namespace?
[2015-05-21 12:12:45] <WouterJ> fabpot: other bridges don't use vendor names
[2015-05-21 12:12:58] <Stof> I would prefer Psr over Fig actually
[2015-05-21 12:13:05] <lsmith> me too
[2015-05-21 12:13:06] <fabpot> PsrHttpMessage sounds good
[2015-05-21 12:13:16] <fabpot> that does not solve the PSR-12 issue
[2015-05-21 12:13:18] <WouterJ> (e.g. proxy-manager-bridge isn't called ocramius-proxy-manager-bridge)
[2015-05-21 12:13:20] <xabbuh> yes, it's better than FigHttpMessage
[2015-05-21 12:13:45] <fabpot> WouterJ: because nobody would be crazy enough to create a competitor to the proxy manager :)
[2015-05-21 12:13:46] <Iltar> psr numbers might change, best to leave them out of the name
[2015-05-21 12:13:47] <xabbuh> WouterJ: but we have a Doctrine bridge
[2015-05-21 12:14:03] <WouterJ> xabbuh, yes but no DoctrineDoctrineBridge.
[2015-05-21 12:14:12] <Stof> OK, anyone against using Symfony\Bridge\PsrHttpMessage then ?
[2015-05-21 12:14:20] <jakubzalas> nope, i'm +1
[2015-05-21 12:14:27] <xabbuh> +1 too
[2015-05-21 12:14:34] <Stof> WouterJ: it is a bridge to the whole Doctrine project (there is no Doctrine\Doctrine btw)
[2015-05-21 12:14:37] <Iltar> Why not split Psr into its own namespace?
[2015-05-21 12:14:49] <Iltar> Who knows what other Psr might need implementations
[2015-05-21 12:14:58] <jakubzalas> Symfony\Bridge\Psr\HttpMessage
[2015-05-21 12:15:02] <Iltar> jakubzalas, exactly
[2015-05-21 12:15:03] <WouterJ> -0.3 (I can't see why there has to be a vendor in the name, but I don't care that much about the naming)
[2015-05-21 12:15:13] <Stof> Iltar: but they would have to be separate bridges, not a single PSR bridge IMO
[2015-05-21 12:15:30] <jakubzalas> Stof: yes, but we're talking namespace only
[2015-05-21 12:15:37] <Stof> WouterJ: have a look at the number of HttpMessage libraries on packagist :)
[2015-05-21 12:15:49] <fabpot> Symfony\Bridge\PsrHttpMessage for me
[2015-05-21 12:16:00] <Stof> jakubzalas: but then, it would be inconsistent with the way bridges are splitted from the main repo
[2015-05-21 12:16:26] <Stof> I also vote for Symfony\Bridge\PsrHttpMessage
[2015-05-21 12:16:28] <WouterJ> Stof, same applies to event-dispatcher :)
[2015-05-21 12:16:33] <jakubzalas> +1
[2015-05-21 12:16:39] <Stof> WouterJ: ?
[2015-05-21 12:16:41] <romainneutron> +1 for Symfony\Bridge\PsrHttpMessage
[2015-05-21 12:16:47] <nicolasgrekas> +1
[2015-05-21 12:16:52] <weaverryan> +1 for Symfony\Bridge\PsrHttpMessage
[2015-05-21 12:17:02] <Iltar> Either way is fine for me, Psr\HttpMessage or PsrHttpMessage
[2015-05-21 12:17:08] <Stof> the only inconsistent split is security (and we also have the consistent one)
[2015-05-21 12:17:29] <Tobion> +1 for Psr\HttpMessage
[2015-05-21 12:17:30] <Iltar> Security\Core you mean?
[2015-05-21 12:17:35] <WouterJ> Stof, sorry was talking about amount of packages on packagist with the same name
[2015-05-21 12:17:36] <Tobion> nope
[2015-05-21 12:17:38] ⇐ talus` quit (~talus@89.225.199.34): Quit: WeeChat 1.1.1
[2015-05-21 12:17:53] <Tobion> +1 for Symfony\Bridge\HttpMessage
[2015-05-21 12:18:02] <jakubzalas> weaverryan: mr Moderator, where are you? ;)
[2015-05-21 12:18:03] <Stof> WouterJ: we don't have any bridge named eventDispatcher though
[2015-05-21 12:18:21] <weaverryan> I'm here :) .... but we're trying to name something, so it's chaos :)
[2015-05-21 12:18:23] <Tobion> since its a converter it converts httpFoundation <-> psr
[2015-05-21 12:18:26] <fabpot> I think Symfony\Bridge\PsrHttpMessage is the one
[2015-05-21 12:18:36] <Tobion> so it makes no sense to me to only put PSR in name
[2015-05-21 12:18:36] <weaverryan> So, we're way over time, and Symfony\Bridge\PsrHttpMessage looks to have the most votes
[2015-05-21 12:18:38] <fabpot> based on votes of course
[2015-05-21 12:18:51] <WouterJ> Stof, good point
[2015-05-21 12:18:57] <weaverryan> So, I'm sorry we went WAY over today - let's close this
[2015-05-21 12:19:03] <Stof> Tobion: the bridges are always related to Symfony too
[2015-05-21 12:19:08] <weaverryan> Next Meeting: Thursday, June 4th
[2015-05-21 12:19:23] <nicolasgrekas> thanks everyone
[2015-05-21 12:19:23] <weaverryan> I will follow-up after this with summary/logs stuff and details about future meetings/topics etc
[2015-05-21 12:19:24] ⇐ tmporary quit (~textual@194.8.215.34): Ping timeout: 276 seconds
[2015-05-21 12:19:28] <fabpot> thanks
[2015-05-21 12:19:32] → aRn0D joined (~arnaud@2a01:e35:2420:b2d0:2cc6:b25c:8d32:1af0)
[2015-05-21 12:19:36] <jakubzalas> cheers
[2015-05-21 12:19:43] <fabpot> weaverryan: thank you
[2015-05-21 12:19:44] <weaverryan> Thanks everyone for coming - nice to "see" so many smart people again
[2015-05-21 12:19:45] <lsmith> yeah .. thanks for setting this up and running the show weaverryan
[2015-05-21 12:19:49] <Stof> fabpot: can you create the repository then (with a first commit in it to be able to send PRs, it could be the readme file)
[2015-05-21 12:19:57] <fabpot> Stof: yes doing that now
[2015-05-21 12:20:01] <Iltar> Thanks for the meeting, it was really nice to see this and be part of it
[2015-05-21 12:20:06] <weaverryan> lsmith: just tried to use your platform from before (though I don't think you ever let us go over by 20 mins)
[2015-05-21 12:20:09] <WouterJ> weaverryan, will the topic list for June 4th be available for public somewhere?
[2015-05-21 12:20:21] <lsmith> weaverryan: can’t remember .. too long ago :)
[2015-05-21 12:20:34] <weaverryan> WouterJ: totally tbd right now honestly
[2015-05-21 12:20:41] <Tobion> cya
[2015-05-21 12:20:45] <weaverryan> o/
[2015-05-21 12:20:53] ⇐ nicolasgrekas quit (47ca7bd9@gateway/web/freenode/ip.71.202.123.217):