Symfony Dev Meeting 2015-06-04

topic-1-http-foundation.irclog

[10:01] <weaverryan> Ok, let's get started! Thanks for coming everyone
[10:02] <romainneutron> thanks webmozart
[10:02] <weaverryan> Each topic will have 15 minutes and I'll try to keep us on time (more than 2 weeks ago)
[10:02] <weaverryan> Topics for today (one of them we may not need to discuss):
[10:02] <weaverryan> A) PSR and HttpFoundation planning (everyone)
[10:02] <weaverryan> B) (if needed) PSR DI response
[10:02] <weaverryan> C) Issue triaging and organization (we didn't get any real steps towards this last time)
[10:02] <weaverryan> D) Next meetings topics, meeting format, etc
[10:03] --> aitboudad (699da5dd@gateway/web/freenode/ip.105.157.165.221) has joined this channel.
[10:03] <weaverryan> Let's start the first topic - I don't have a "host" for that, but basically the idea is this: what is our plan with HttpFoundation and PSR-7. Should we move *towards* it?
[10:04] <fabpot> Two parts in that topic I think
[10:04] <fabpot> First, we now have the bridge, which should be re-included in Symfony 2.8
[10:04] <fabpot> then, what kind of changes we want to make to HttpFoundation in 2.8 to make it "more compatible" with PSR-7
[10:05] <fabpot> with deprecations, upgrade path, and no hard BC breaks
[10:05] <weaverryan> streams seem like one of the most incompatible pieces currently
[10:05] <dunglas> agree
[10:06] <Stof> yeah, finding a way to support streams in HttpFoundation for the content seems a good idea (not sure it is possible though)
[10:06] <dunglas> with mutability of course
[10:06] <xabbuh> this week, someone raised the concern that you can now inject a PSR request into a controller, but you will still have to convert it to make use of it with a form
[10:07] <-- ahmetkapikiran ([email protected]) has left this server (Quit: ahmetkapikiran).
[10:07] <dunglas> in form, in events, in many places in fact
[10:07] <Stof> well, we could implement a PSR7Handler for forms
[10:07] <fabpot> we are all aware that the current version of the bridge is just a first step
[10:07] <Stof> just as done for HttpFoundation
[10:07] <Iltar> This will be a lot of extra work
[10:07] <webmozart> a PSR-7 request handler should be quite simple
[10:07] <Stof> webmozart: can we register multiple handlers in the Form component ?
[10:08] <Stof> if no, we would need a PSR7+HttpFoundation handler for BC reasons
[10:08] <webmozart> not at the moment
[10:08] <webmozart> sounds good
[10:08] <dunglas> what’s the plan for Symfony 4? Moving to PSR-7 or stick with HttpFoundation?
[10:08] <weaverryan> a PSR-7 request handler just solves one problem, not the bigger idea that HttpFoundation is needed in several places
[10:09] <Stof> dunglas: I think it is too early to speak about Sf4. We don't even have Sf3 ready yet
[10:09] <Iltar> The easiest solution right now would be to create a psr request decorator which extends the Request
[10:09] <Tobion> in my ideal world we would get rid of http foundation request/response. there are many bugs/design issues which cannot be solved without BC break: https://github.com/symfony/symfony/issues/6406 https://github.com/symfony/symfony/issues/6634 etc
[10:10] <Stof> and moving to PSR-7 everywhere means a big BC break because of immutability, be it in 3.0 or 4.0
[10:10] <fabpot> Tobion: looks like a better idea to fix the bugs and somehow break BC instead of starting from scratch
[10:11] <Stof> going towards PSR-7, I think we need to extract a bunch of things outside the Request. Trusted proxies for instance
[10:11] <dunglas> Stof: maybe, but our strategy can depend of that. If we will move to PSR-7, doing minor enhancement to HttpFoundation and the bridge would be sufficient because our long terme strategy is to use PSR-7 everywhere. If not, we will need to add BC breaks (for stream and immutability) while moving HttpFoundation to PSR-7 during the life of Symfony 3
[10:11] <Stof> I think we have a PR starting that btw (though not ready for inclusion)
[10:11] <weaverryan> agree with fabpot - a lot of libraries rely on HttpFoundation, - they are looking to use to see how it will evolve (but not disappear)
[10:11] <fabpot> agree with Stof, that's the kind of "simple" things we can do now
[10:11] <Iltar> The request simply has too many responsibilities
[10:11] <Stof> Iltar: exactly
[10:11] <fabpot> Let's break the current Request class into smaller ones then
[10:11] <lsmith> hi .. just made it home
[10:12] <Iltar> +1 from me, I like breaking stuff
[10:12] <weaverryan> (5 minute warning, though we can eat into the next slot, which may not need discussion anyways - container PSR)
[10:12] <fabpot> splitting the Request class: everyone agrees?
[10:12] <Tobion> i mean we do not need to start from scratch but we could update components to use psr-7 step by step and use the psr-7-bridge for everything that is not based on psr-7 (yet)
[10:13] <fabpot> Tobion: splitting the Request is probably a nice first step for 2.8
[10:13] <Tobion> for the routing component i suggested https://github.com/symfony/symfony/issues/14723
[10:13] <weaverryan> Tobion: I think we're not ready to make people rely on the bridge yet - streams make converting back and forth still awkward, especially for large streams or uploads
[10:13] <dunglas> i’ve started to look how to refactor HttpFoundation to be an implementation of PSR-7 (for fun). Splitting the request is necessary, but I think that in any case it will be a huge BC break.
[10:14] <dunglas> (to support PSR-7, not to split the request)
[10:14] <weaverryan> fabpot: do we have a clear vision on what pieces would be split? And is the goal just to make the Request smaller so it's easier to deal with PSR-7 evolution?
[10:14] <Stof> dunglas: Httpfoundation cannot become a PSR-7 implementation, because of immutability vs mutability
[10:14] <fabpot> dunglas: not necesserily, we can at first proxy the new classes from th erequest and remove the old methods in 3.0
[10:14] <dunglas> Stof: yes i know, but what I started is to use some methods as a base (a fork of HttpFoundation)
[10:14] <Stof> IMO, the first parts to split are trusted proxies and the concept of base path, because they are not there in PSR-7
[10:14] <fabpot> weaverryan: I think that splitting the Requets class is a nice goal by itself, and if it makes it more compatible/easy to evolve for PSR-7, that's a nice bonus
[10:15] <Iltar> Maybe this could be a nice push to take a fresh look at the session
[10:15] <fabpot> At this point, we need someone who can think about how to split things and propose a plan for the next meeting
[10:15] <fabpot> Iltar: session is yet another issue :)
[10:15] <Stof> It could also allow to replace the logic to determine trusted proxies more easily
[10:15] <weaverryan> Iltar: keep the scope small please :)
[10:15] <Stof> and the Session should also not be in the Request object IMO, right
[10:16] <andrerom> deprecations in 2.8 and bc breaks in 3.0 should be ok (from eZ perspective), but maybe possible to provide a compat wrapper in 3.0 while the default request moves towards PSR-7?
[10:16] <Stof> how the Session itself works is indeed another topic
[10:16] <dunglas> trusted proxies, streams, cookie handling and base path would be a good start
[10:16] <Iltar> My point stof :) getSession ()
[10:16] <dunglas> (streams = request and response « content »)
[10:16] <fabpot> Who wants to lead that effort?
[10:17] <Stof> btw, thanks dunglas for your awesome work on the bridge
[10:17] <dunglas> thank you for ideas and review!
[10:18] <weaverryan> To be clear, fabpot, you're asking about someone to lead the effort of the *plan*, correct? I think we're all trying not to volunteer for something too big :)
[10:18] <weaverryan> andrerom: 2.8 is the same as 3.0, but with that compat layer - so I think what you're asking for is already planned
[10:18] <-- andrerom ([email protected]) has left this channel.
[10:18] --> andrerom ([email protected]) has joined this channel.
[10:19] <Tobion> I would be willing to work on making the routing component be based on PSR-7, i.e. issue 14723. Since the routing component doesn't need the request body but only consumes basic info like path, port, method etc, I don't see a problem to use psr-7-bridge in symfony framework for it.
[10:19] --> brensch ([email protected]) has joined this channel.
[10:19] <lsmith> weaverryan: usually plan = lead implementor applies to the symfony world
[10:19] <dunglas> Tolbion: performance is a problem
[10:19] <Stof> Tobion: I thnk this requires figuring the base path issues first though
[10:20] <Tobion> What base path issue?
[10:20] <Stof> lsmith: the guy planning may not be the one writing the code. See me and dunglas for the PSR7 bridge
[10:20] <Stof> Tobion: PSR-7 does not have a concept of base path
[10:20] --> fabpot_ (~fabpot@symfony/developer/fabpot) has joined this channel.
[10:20] <lsmith> Stof: which was most unusual :)
[10:20] <Tobion> Yes, that was one of the discussion  points why psr-7 was delayed
[10:21] <Stof> and the router needs the base path when generating, and the path without the base path when matching
[10:21] <Tobion> but we agreed on a solution there
[10:21] <Tobion> to make a new request that strips the base path
[10:21] <weaverryan> Let's stay on path - we need someone (or group) to prep a plan for splitting Request into small pieces
[10:21] <-- fabpot (~fabpot@symfony/developer/fabpot) has left this server (Ping timeout: 265 seconds).
[10:21] *** fabpot_ is now known as fabpot.
[10:21] <dunglas> if some main component such as routing start to use PSR-7 internally, it can be done everywhere (like in forms and HttpKernel)
[10:21] <Tobion> and the base path is then simply set on the router as context
[10:21] <webmozart> dunglas Stof what about the two of you? You seem to have quite a clear picture of what needs to be done
[10:21] <dunglas> the upgrade path will be: use the bridge from PSR-7 to HttpFoundation for old code (instead of the inverse)
[10:22] <Stof> dunglas: in HttpKernel, it will be very hard without BC break: interface is based on Httpfoundation, and events are based on mutability
[10:22] --> tslykhouse ([email protected]) has joined this channel.
[10:22] <dunglas> Stof: agree, it will be a BC break (it’s why I was speaking about Symfony 4)
[10:22] <Iltar> RequestBuilder which is xformed into a psr request object?
[10:22] <Stof> dunglas: we are making our plans for 2.8 right now
[10:23] <Tobion> stof: for events, why not simply have a method Event::setRequest that takes a psr-7 request
[10:23] <Iltar> RequestBuilder could extend the request
[10:23] <Tobion> so instead of mutability of the request, psr-7 requires to set the changed request on the event
[10:23] <Stof> Tobion: the issue is that this setter would have to mutate the *existing* Request object => hard
[10:23] <fabpot> Let's move on to the next topic
[10:23] <lsmith> I agree with dunglas that we should start on defining what symfony 4 will be and when it will come sooner rather than later .. given that symfony 3 will be evolutionary
[10:24] <lsmith> but it can also wait a few more weeks/months
[10:24] <weaverryan> Ok, I'm going to move us to the next topic
[10:24] <lsmith> but imho by this summer we should have an idea of the scope and timing of symfony 4
[10:24] <weaverryan> We have agreement on the immediate direction (splitting Request), but not any people responsible for it yet
[10:24] <dunglas> I’m motivated to start protyping some stuffes in this area (PSR-7 / HttpFoundation / HttpKernel) but I’m not sure to have the necessary time so i cannot be the lead
[10:25] <Iltar> Too many plans for me on Security, otherwise I'd love to help out
[10:25] <weaverryan> And as Stof said, let's try to keep these meetings planning for the somewhat immediate future - what we can do now (of course with the future in mind)

topic-2-psr-di-response.irclog

[10:25] <weaverryan> Topic B) (if needed) PSR DI response
[10:25] <weaverryan> Do we need to talk about this? Or is our -1 vote good for now?
[10:25] <webmozart> the only question I have is whether we should make some kind of public statement as dunglas proposed
[10:26] <Tobion> i dont think we have to discuss anything there, we voted -1 which I agree with
[10:26] <Stof> I think we already got quite an agreement on the mailing-list for that. I don't remember of anyone sayign +1 on the list
[10:26] <weaverryan> (and btw, I will summarize the meeting in an email, so even unfinished points will go there)
[10:26] <dunglas> maybe just a post on the FIG maling list explaning that we are -1
[10:26] <lsmith> i think the proposal has potential .. but likely more for lib authors than framework authors
[10:26] <Stof> webmozart: I think the mail giving our -1 vote should explain some of our reasons, yes
[10:26] <fabpot> No need to waste time with the DIC stuff, really
[10:27] <fabpot> Le'ts move on to the next topic
[10:27] <webmozart> it's just an entrance vote, so probably a public statement isn't needed (yet)
[10:27] <lsmith> i also do not think it needs a public statement .. but a post to the fig list about the -1 would be a nice touch
[10:27] <weaverryan> I think we're good - webmozart, if you feel there's something we should add to the -1 vote, then you can do it. Otherwise, it's settled for now
[10:27] <lsmith> although i am the only one that is somewhat positive about it .. i can draft an email and send it to the core list for review
[10:27] <webmozart> lsmith: I posted my concerns already (which match those of the core team), I think that's enough
[10:27] <lsmith> ok

topic-3-issue-triaging.irclog

[10:28] <weaverryan> Next! C) Issue triaging and organization (we didn't get any real steps towards this last time)
[10:28] <weaverryan> I want to keep this focused, but last time we didn't really get any conclusions
[10:28] <weaverryan> There were extra emails this week about using "hasPr" or "Unconfirmed" labels
[10:29] <Tobion> maybe we should define a goal? or a concrete problem?
[10:29] <weaverryan> Yes, of course
[10:29] <weaverryan> Goal/Problem: Don't let old issues/PR's get lost
[10:29] <weaverryan> Related: reduce time to response - e.g. if we reply 12 months later on a PR for the first time, that sucks :)
[10:30] <weaverryan> So, how can we improve these, knowing that we have too little resources
[10:30] <fabpot> I don't think we can do anything by ourselves, we need more people
[10:30] <fabpot> everyone in the core team does its best to comment, review, and merge
[10:31] <fabpot> I think it's really a scalability problem, how do we find and integrate more people in the process
[10:31] <Stof> it might be good to have a dashboard listing issues/PR with the time since the last comment on them, and also a list of issues without any comment on them
[10:31] <fabpot> how do we empower more people
[10:31] <Tobion> It would be easier, if the reports were actually more easy to understand/reproduce
[10:31] <webmozart> Drupal has an interesting approach there
[10:31] <Stof> this would help avoiding to let issues unanswered for weeks
[10:31] <lsmith> I think our efforts towards dashboards has improved things in the CMF project
[10:31] <MaxVandervelde> How can someone that is currently less-involved, like myself, start to help?
[10:31] <lsmith> but we still dont have any ideal dashboard setup
[10:31] <xabbuh> imho tagging should make life easier for us and for non core team members, the unconfirmed label is a good example, it let's others step in and try to build a reproducable example
[10:31] <lsmith> i think fabpot is right .. the core team is doing its best
[10:32] <webmozart> Drupal uses a two-stage approach that we could use too
[10:32] <webmozart> first stage, basic review with defined criteria, can be done by anyone
[10:32] <lsmith> the main goal would be to enable a "layer" of people around the core to do more stuff before the core team looks at stuf
[10:32] <Stof> but otherwise, we indeed need more people following issues to look at them
[10:32] <lsmith> but github is kind of limited there
[10:32] <webmozart> then the issue is tagged as "ready for core committer"
[10:32] <webmozart> if we define precisely what we are looking for in the first stage, we could encourage more people to do these basic checks
[10:33] <fabpot> webmozart: who is "anyone"? I don't think we have a process problem, but a manpower problem here
[10:33] <Stof> a way for people to be notified about new issues (without being notified for any comment) might also help people wanting to help here
[10:33] <Stof> github notifications are all-or-nothing there
[10:33] <webmozart> fabpot: anyone that wants to contribute even if they don't know all the internals
[10:33] <Stof> such notification system could be built with a webhook triggered for new issues and then notifying volunteers
[10:33] <lsmith> i think there is potential to improve the process for people feeding stuff to core people .. but i fear it requires tooling on top of github issues
[10:34] <fabpot> sorry guys, I need to go now, if someone can record the messages here, that would help me catch up later today
[10:34] <Stof> with a page on symfony.com to register for such notifications
[10:34] <-- fabpot (~fabpot@symfony/developer/fabpot) has left this server (Quit: fabpot).
[10:34] <dunglas> splitting components as suggested by Jordi can help here too
[10:34] <Stof> this would allow to build a list of people reviewing new issues (who don't need to be part of the core team)
[10:34] <dunglas> now you follow all Symfony component or none
[10:35] <-- dbu (~david@2a02:168:2004:42:a061:b372:c98d:bc7b) has left this server (Quit: Konversation terminated!).
[10:35] <dunglas> it’s not possible to follow issues on Security and Serializer for instance
[10:35] <weaverryan> dunglas: this assumes the world will be smart enough to find the right repository to open up issues on ;) - I would see a lot of "please close this and re-open it over there on that other repo"
[10:35] <dunglas> (we can at least split bug trackers - repo already exist, without splitting the code)
[10:35] <webmozart> dunglas: splitting could indeed help, but there's also the risk that "unpopular" components don't get attention anymore
[10:36] <xabbuh> the issue then will be that people actually would have to know where to post new issues (does it belong to the bundle? or to the component? or a bridge?)
[10:36] <weaverryan> splitting is a huge changea and fabpot is against it. Fxr now, let's focus on something more tangible
[10:36] <weaverryan> xabbuh: +1 :)
[10:36] <Stof> dunglas: in many cases, people reporting issues don't really know which is the affected component though
[10:36] <xabbuh> you were too fast Ryan
[10:36] <dunglas> true using the full stack framework (but already it can also be a doctrine, or monolog or assetic bug)
[10:37] <Stof> splitting the issue tracker is not the solution IMO, as it makes things harder to report issues
[10:37] <Stof> dunglas: and we already get a bunch of Doctrine or Assetic bugs in our issue tracker
[10:37] <lsmith> i agree .. splitting the issue tracker will create more work and confusion
[10:37] <webmozart> ok. then the issue boils down to: how can we encourage/enable more people to review issues/PRs
[10:37] <lsmith> i think fundamentally github notifications and permissions in the issue tracker are failing us
[10:37] <weaverryan> agree with last 2 comments
[10:37] <Stof> lsmith: for notifications, see my proposal above
[10:38] <weaverryan> Having a dashboard is an interesting idea (Stof). The risk is that it will take some effort (and we are all too busy already) and it may not prove a good solution. But it does indeed solve lsmith's comment about notifications
[10:38] <xeoexa> a dev mailing list ?
[10:38] --> jakubzalas_ (uid88514@gateway/web/irccloud.com/x-fpleqzbwgorxglye) has joined this channel.
[10:38] <Stof> for the permissions, replying to people to help them or reproducing the issue does not require being a repo collaborator
[10:38] <weaverryan> xeoexa: we need people to be notified for different issues, but not all of us notified for everything :)
[10:39] <-- aRn0D ([email protected]) has left this server (Ping timeout: 264 seconds).
[10:39] <dunglas> and what about multiplying bug days, hack days… events
[10:39] <Iltar> A custom crawler that you can register to, sends you an update once a day if your chosen tags are present?
[10:39] <Tobion> Very simple idea: before people can create feature requests, they have to try to fix a bug :)
[10:39] <lsmith> this btw could also help in getting more contributors for all components https://github.com/codetriage/codetriage
[10:39] <xeoexa> weaverryan: github already allows to register for notifications for a single issue
[10:40] <webmozart> I think we have two issues now that need to be discussed separately
[10:40] <weaverryan> xeoexa: but not for only issues that relate to "Security", for example :)
[10:40] <Iltar> Let an API register you to notifications of issues/PR with labels you register to?
[10:40] <-- jakubzalas ([email protected]) has left this server (Quit: Leaving.).
[10:40] *** jakubzalas_ is now known as jakubzalas.
[10:40] <webmozart> 1. fixing notifications 2. getting more people to review
[10:41] <webmozart> I suggest we focus on one of these now or discuss both next time
[10:41] <weaverryan> webmozart: very good - we have 4 minutes left
[10:41] <webmozart> I think that 2 is easier to solve
[10:41] <Stof> xeoexa: this is for the discussion about an issue. What we would need is someone notified for any new issue being created, without being notified for every comment on issues
[10:41] <Stof> to receice less emails
[10:42] <xeoexa> Stof: a bot ?
[10:42] <Stof> which bot ?
[10:42] <andrerom> fabot
[10:42] <andrerom> :)
[10:42] <Stof> we want real people being notified, so that they can help
[10:42] <xeoexa> don't know if such bot exists, but I don't think it would be hard to solve
[10:43] <weaverryan> For 1. (and sort of 2), I can propose a plan for what a "dashboard" or notification system might look like and propose to the group to see if we want to spend time on it.
[10:43] <Stof> seems like a good idea
[10:43] <weaverryan> ... and at least if we then think something like this is a bad idea, we can move on to another idea :)
[10:43] <xeoexa> I could try to look for smth like that
[10:43] <webmozart> weaverryan: +1 I think you should try to find something super simple, like a generic notification address that does basic filtering and forwarding
[10:43] <xeoexa> look at the github API, and so on
[10:44] <weaverryan> xeoexa: if you find something that another group is using, you can email me - [email protected]
[10:44] <xeoexa> weaverryan: ok, I will look at that. BTW, when is the next meeting ?
[10:44] <lsmith> Stof: i think https://github.com/codetriage/codetriage is exactly that
[10:45] <lsmith> never used the tool .. just now found it during the meeting
[10:45] <weaverryan> lsmith: awesome - I'll have a look at it and do some research
[10:45] <weaverryan> Time is up for this topic
[10:45] <lsmith> it seems to allow people to subscribe and then tickets get assigned to the people that signed up for triaging
[10:45] <webmozart> cool!
[10:45] <lsmith> so the load gets spread
[10:45] <Stof> lsmith: they seem to assign a single issue per user and per day. Not exactly what we want
[10:45] <xeoexa> +1
[10:45] <kbond> Possible to use ifttt.com for notification of new issues?
[10:46] <lsmith> and maybe people will feel obligated to review the tickets assigned to them :)
[10:46] <Stof> weaverryan: I suggest having a look at Zapier to send an email easily for each new issues
[10:46] <ewgra> Github support watch mode like: Not watchingBe notified when participating or @mentioned.
[10:46] <lsmith> Stof: the goal of this tool is to bring in more people
[10:46] <lsmith> not to solve github notifications
[10:46] <ewgra> There is just must be a role like "issue router"
[10:46] <Stof> ewgra: we know. and this is not what we want
[10:46] <weaverryan> thanks for all the tips :)
[10:47] <ewgra> that will decide who is must be participated
[10:47] <weaverryan> Ok, last topic!
[10:47] <lsmith> but yeah .. i also anxiously await for someone to fix github notifications for me :)

topic-4-topics.irclog

[10:47] <weaverryan> Last topic, is.... about the topics! and meeting format: Next meetings topics, meeting format, etc
[10:47] <Stof> we could have a mailing-list notified only on new issues thanks to that, and encourage people to subscribe to it if they want to help
[10:48] <lsmith> Stof: but then still many or no people will feel obligated .. i think the above tool makes more sense .. just people should be able to pick how many tickets per day they want
[10:48] <webmozart> weaverryan: I think the results of your research are a good topic for the next meeting
[10:48] <Iltar> If they solve issues, reward them with results on symfony.com, motivation is key
[10:48] <lsmith> and that tool should enable people to set tags on their tickets
[10:49] <weaverryan> Let me explain: We want to keep these meetings focused and on important stuff. So, where should topic ideas come from? I think fabpot is not satisfied with far-reaching meeting ideas (e.g. anything Symfony 4), and nobody is really proposing many topic ideas back to me by email
[10:49] <lsmith>    back in the day i think i picked topics from the mailinglist
[10:49] <weaverryan> So, how can we decide the most important meeting ideas, be fair to any ideas on the core team / community, but keep things focused to topics that can have tangible results?
[10:49] <lsmith> since we do not have this anymore ..
[10:50] <lsmith> maybe pick topics from busy issues/PRs?
[10:50] <weaverryan> yes, we have GitHub now, but do we need to talk about most technical things?
[10:50] <webmozart> weaverryan: I think we need to focus the meetings on our biggest goals. For me, that's attracting more people to contribute atm
[10:51] <weaverryan> webmozart: Agree with that. Now, what are our other biggest goals? And where do those come from?
[10:52] <weaverryan> We don't need to get a perfect solution here - just want us all to be on the same page, then I'll run with a plan that we all don't hate :)
[10:52] <andrerom> proposal for topic: distrobution issues, aka DX issue for upgrades becasue Sf and composer currenlty force poeple to merge in changes (most of the times with conflicts) on a Symfony-standard install, as many files are made to allow modifications upstream and downstream
[10:52] <andrerom> examples: config files, kernel file, composer.json, ..
[10:53] <weaverryan> andrerom: I'd open that up as an issue somewhere (maybe on the SE): I think that's a bit specific to how eZ is doing upgrades iirc
[10:53] <andrerom> ez aslo has this as we have stayed close to symfony standard on most things
[10:53] <Stof> andrerom: these files are part of your project once it is started. If we have required changes to do in them when updating Symfony, it is a BC break, which is not allowed
[10:54] <Stof> symfony-standard is only the starting point for new projects
[10:54] <andrerom> true, we’ll probably end up diverging from sf-standard becasue of this and missing multi kernle in sf 3.0 dir layout
[10:55] <-- ewgra ([email protected]) has left this server (Quit: Leaving.).
[10:55] <weaverryan> Let me propose a plan: 1) If you have any issues, you can always email me. 2) I will look ok GitHub PR's/issues, but mostly  I don't think these need discussion. 3) We will spend 5-10 minutes planning next meeting's topics at the end of current meeting
[10:55] <webmozart> weaverryan: Seems we don't have any real goals atm (except for tweaking here and there and solving our manpower problem). Maybe we should fix that?
[10:56] <dunglas> IMO those meeting can be cool to speak about what we are (or will be) working on
[10:56] <weaverryan> agreed!
[10:56] <dunglas> it avoids to start working on something in Symfony without consensus
[10:56] <weaverryan> So perhaps that's the last 10 minutes of each meeting: proposals for future topics, which would be a time to talk about any initiatives that someone might have
[10:56] <weaverryan> then we are aware of them, and can choose to talk about them in the next meeting
[10:56] <dunglas> for instance I’m motivated to start working on a PSR-7 compliant HttpFoundation / HttpKernel (with BC break) but will not because it doesn’t make consensus and don’t want to waste my time
[10:57] <weaverryan> "goals" need to be proposed somewhere first, and then get discussed (potentially) at a meeting later
[10:57] <Tobion> agree with dunglas
[10:57] <Tobion> same for me with routing
[10:57] <lsmith> once you are king of the hill its much harder to move forward .. there isn't a mountain top as a goal .. but you need to visualize mountains to build yourself ..
[10:57] <webmozart> lsmith +1
[10:57] <lsmith> but i also agree with dunglas ..
[10:58] <lsmith> getting consensus for bigger ideas is a good purpose for this meeting
[10:58] --> dbu ([email protected]) has joined this channel.
[10:58] <lsmith> but this to me also again requires symfony 4 timeline being defined
[10:58] <weaverryan> Ok great: then last 15 minutes of each meeting for that purpose?
[10:58] <lsmith> so that we can also figure out what ideas can sensibly be moved there
[10:58] <andrerom> +1
[10:58] <lsmith> weaverryan .. not sure if we need to discuss this together
[10:59] <weaverryan> lsmith: the problem is that I need to know what these potential topics are, to propose them for the next meeting :)
[10:59] <lsmith> people can propose things .. and you can use your own digression to fill up the other time slots
[10:59] <lsmith> this is how i did it .. and nobody complained ;)
[10:59] <weaverryan> lsmith: right now, people aren't proposing to me by email, hence using the last 10 or 15 minutes to do this
[10:59] <webmozart> I like the idea, sounds pragmatic
[11:00] <dunglas> the last 10 minutes can be a sort of « free » time where we can speak about what we are and will be working on and receive feedbacks from other members (I think about webmozart Pulli for instance)
[11:00] <weaverryan> btw, to Tobion and dunglas' points earlier - I totally agree on "getting consensus so I can actually run with an idea" - good purpose of the meeting
[11:01] <Tobion> i agree that we should spend the last 15 minutes on proposing topics for next meeting and for giving peopple the change to get feedback if the core team agres to spend time on an idea
[11:01] <-- Iltar ([email protected]) has left this server (Quit: AndroIRC - Android IRC Client ( http://www.androirc.com )).
[11:01] <weaverryan> I think we have a plan then :). I will continue organizing the meeting, email if you want topics, but we will have time at the end of the meeting for this "free time for ideas / brainstorming"
[11:01] --> Iltar ([email protected]) has joined this channel.
[11:01] <weaverryan> And we're out of time for this meeting :)
[11:01] <webmozart> cool. big *clap* for weaverryan
[11:01] <xabbuh> sounds like a good plan
[11:02] <weaverryan> And the difficulty of these topics shows why we meet again :)
[11:02] <weaverryan> Really nice to chat with you all again. Next meeting is June 18th at the same time
[11:02] <dunglas> than you weaverryan
[11:02] <xabbuh> thank you for the organisation weaverryan
[11:03] <Stof> andrerom: regarding our previous off-topic discussion about upgrading project, not all changes from symfoiny-standard should be applied in projects when upgrading Symfony btw. For instance, https://github.com/symfony/symfony-standard/pull/813 should not be applied in existing projects (except if you decide to do a big DB migration for that), but it is a very good idea for new projects (which is why the change was not in the default DoctrineBundle value bt
[11:03] <xeoexa> thank you weaverryan
[11:03] <weaverryan> If anyone has topic ideas before then or any other questions or issues, message me - [email protected]
[11:03] <webmozart> thanks weaverryan! See you all in two weeks :)
[11:03] <-- romainneutron ([email protected]) has left this server (Quit: romainneutron).
[11:03] <Iltar> Thanks for the meetings, I have a feeling they will help Symfony but also the contributors a lot

@MaxvanderVelde You even split things by topic - very helpful! :)