symfony metting

[16:54:07] <Stof> hi
[16:55:10] <WouterJ> afternoon Will there be a meeting today?
[16:55:56] <xabbuh> hi
[16:57:04] <Stof> WouterJ: normally yes, but without Fabien
[16:57:42] <-- martinFrances (~martinFra@cpc22-cmbg14-2-0-cust214.5-4.cable.virginm.net) est parti (Ping timeout: 255 seconds)
[16:58:51] <-- jakubzalas (~jakubzala@IW361404.net.t-com.hr) est parti (Quit: Leaving.)
[17:00:30] --> weaverryan (uid32540@gateway/web/irccloud.com/x-jleoukuvuwnmsflz) a rejoint #symfony-dev
[17:02:26] <WouterJ> hi weaverryan
[17:02:30] <weaverryan> o/ everyone - who's all here?
[17:03:24] <weaverryan> I'm at a conference with 2, maybe 3 other core members... who are all mysteriously missing from here :)
[17:03:46] --> ZCJ (~chatzilla@94.200.140.42) a rejoint #symfony-dev
[17:04:25] <ZCJ> Helloe everyone
[17:04:48] <weaverryan> Hey ZCJ - I know you ;)
[17:04:55] <ZCJ> :)
[17:05:08] <ZCJ> How r u Ryan?
[17:05:52] <weaverryan> Other than nobody seems to be here, I could not be better - I'm in Croatia at a restaurant, and with Leanna of course
[17:05:52] --> Iltar (~Iltar@188.207.95.21) a rejoint #symfony-dev
[17:05:54] <weaverryan> how are you?
[17:06:00] <weaverryan> hey Iltar o/
[17:06:09] <Iltar> Heya
[17:06:19] <ZCJ> Lucky you
[17:06:25] <WouterJ> weaverryan, Stof and xabbuh are also here (they commented before you joined)
[17:06:31] <ZCJ> hope all is well - how is the conf so far?
[17:06:34] <weaverryan> ah, ok good good
[17:06:53] -*- WouterJ has to leave somewhere around 5.30 btw
[17:06:58] <weaverryan> it's a great conference - but we have 4 core members here, and I think the rest of them may be enjoying the conference right now :)
[17:07:11] <Stof> hi weaverryan (and Leanna)
[17:07:23] <ZCJ> is there an agenda set for today?
[17:07:48] <weaverryan> "Leanna, ohh, tell Stof I said hi!" - and she added that she's looking forward to seeing you in Paris
[17:07:58] <ZCJ> I have something that I am experiencing with symfony which is related to DX and would like to highlight it -if you dont mind, i can share it
[17:08:10] <weaverryan> ZCJ - it's less defined than normal, and I think that's perfect, because we are short on core members today
[17:08:20] <weaverryan> so, we'll get what we can get done, and see how quickly we can do it
[17:08:25] --> martinFrances (~martinFra@cpc22-cmbg14-2-0-cust214.5-4.cable.virginm.net) a rejoint #symfony-dev
[17:09:28] <Stof> WouterJ: regardless the list of BC breaks for 3.0 (issue linked by Fabien in the mailing-list), there is a point about removing the prototype scope too
[17:09:55] <Stof> this should be discussed, because it would mean removed the shared=false feature we introduced in 2.8 when deprecating scopes
[17:10:39] <weaverryan> https://github.com/symfony/symfony/issues/11742
[17:10:40] <WouterJ> removing prototype scope or removing the complete feature provided by the prototype scope?
[17:11:05] <Stof> WouterJ: I don't understand the distinction you make
[17:11:29] --> bango2 (~bango2@uaf48613.ddns.uark.edu) a rejoint #symfony-dev
[17:11:39] <WouterJ> Stof: well, shared=false was introduced in 2.8, because prototype scope was deprecated. So I tried to make sense of your "it would mean removed the shared=false feature"
[17:12:01] <-- bango2 (~bango2@uaf48613.ddns.uark.edu) est parti (Read error: Connection reset by peer)
[17:12:13] <WouterJ> I wondered if that was a typo or if you meant that both prototype scope and shared=false should be removed (and thus, making it impossible to create a statefull service)
[17:12:43] <Iltar> Shouldnt services be stateless in the first place?
[17:12:43] --> bango2 (~bango2@uaf48613.ddns.uark.edu) a rejoint #symfony-dev
[17:12:48] <weaverryan> As far as I know, prototype is deprecated and to be removed, but not shared, correct?
[17:13:32] <weaverryan> Iltar: I've never used a stateless services, but I bet that there are some projects using the DI component that use this. Anyone know a good use-case?
[17:13:50] <WouterJ> s/stateless/statefull
[17:14:01] <weaverryan> ah, thanks
[17:14:14] <-- fago (~fago@chello084112182213.1.11.vie.surfer.at) est parti (Ping timeout: 246 seconds)
[17:14:16] <Iltar> Flashbag, session
[17:14:30] <Stof> weaverryan: currently, we removed custom scopes, keeping only container and prototype (through the new shared flag, going back to early Symfony preview releases btw)
[17:15:18] <Stof> there is another point in the list asking to remove the prototype scope (forcing all services to be always shared in the container)
[17:15:33] <WouterJ> can't it be implemented without scopes?
[17:15:33] <Stof> I don't think this was discussed much yet
[17:15:50] <Stof> Iltar: the session is not a prototyped-scope service
[17:16:01] <WouterJ> without looking at the implementation, I thought shared was the scopefree replacement of the prototype scope
[17:16:02] <Stof> you want all services using the session to use the same session
[17:16:33] <weaverryan> I think the same as WouterJ. Stof, are we mistaken in this thought?
[17:16:38] <Stof> WouterJ: shared=false is indeed this replacement. Which is what we should remove now (the list was written before this change, and so uses the old name)
[17:17:17] <Stof> prototyped-scope services actually serve a single use case: using the container as a factory (which cannot receive arguments)
[17:17:45] <weaverryan> ooh, so let me summarize: prototype is deprecated and WILL be removed. There's no discussion. The linked issue list should say "discuss deprecating shared=false" - and we haven't really discussed this yet
[17:17:57] <Nicofuma> the solution is to inject a factory which will use new my_class()
[17:18:16] <WouterJ> ah, got it. Thanks weaverryan :)
[17:18:25] <weaverryan> In that case, I don't really see a point to removing this flexibility - we have other things to worry about - is having shared=false (other than supporting some code for this) causing any problems?
[17:18:45] <WouterJ> I agree with weaverryan
[17:18:46] <Nicofuma> with prototype (or shared=false) we use the DI as a service locator, and tbh it's convenient
[17:18:54] <-- DonAlberto (~Alberto@pd95cb44f.dip0.t-ipconnect.de) est parti
[17:19:00] <Iltar> Unused feature maybe, including docs maintained. Other than that, no harm afaik
[17:19:18] <WouterJ> maintaining docs of a feature that doesn't change isn't hard :)
[17:19:29] <Iltar> Exactly
[17:20:48] <WouterJ> "The only valid usage for the prototype type of services is factories." - Fabien @ https://github.com/silexphp/Pimple/pull/86
[17:21:19] <Stof> Nicofuma: you don't use it as a service locator. you use it as a factory (prototype-scoped services are not really services IMO)
[17:21:36] <Nicofuma> they aren't services
[17:21:49] <Nicofuma> and yes, factory. It's a better description
[17:21:55] <Stof> Nicofuma: you were the one sayign it is used as service locator
[17:22:06] <Nicofuma> my mistake
[17:22:10] <weaverryan> More largely, we need to prioritize - and accomplish - things in https://github.com/symfony/symfony/issues/11742 that are important - as we only have one shot at 3.0
[17:22:20] <Stof> WouterJ: we also need to maintain all the logic forbidding to scope widening cases
[17:22:47] <weaverryan> As as Fabien likes to say, if an issue is important enough, someone will care. Otherwise, if it's not important, nobody will care and it won't get done.
[17:23:11] <Stof> well, he was the one suggesting to remove them in 3.0 in a discussion
[17:23:25] <Stof> but we almost never went back to this list to see what should be done
[17:23:41] <Iltar> I have to add the acl to that list
[17:23:56] <weaverryan> That's basically the idea: if you want something done, then get it done - time is short
[17:24:00] <WouterJ> I've done some Security things from that list (open PRs at the moment)
[17:24:06] --> yjv (~yjv@static-71-112-177-2.pitbpa.fios.verizon.net) a rejoint #symfony-dev
[17:24:21] <WouterJ> only 3 days left, right?
[17:24:22] <weaverryan> We could decide to assign some things to people from the list, but I'm not sure if that's useful
[17:24:30] <WouterJ> oh, 3 days and a month sorry
[17:24:35] <weaverryan> yes, end of Sep
[17:24:43] --> Garfield-fr (~Garfield-@unaffiliated/garfield-fr) a rejoint #symfony-dev
[17:24:51] <weaverryan> but that basically means that things are *merged* in 1 month + 3 days...
[17:25:30] <Iltar> I hope the acl bundle will be finished before then .. Otherwise it will have to wait for 3.1 :(
[17:25:53] <weaverryan> I hope so too
[17:26:23] <WouterJ> can we create a list of things that really have to be done, so we can assign people to make sure it's finished? E.g. Templating removal, Guard,
[17:26:30] <Iltar> Ill get started on the docs as soon as I have some time, the bundle needs a lot of testing but the initial PR is almost done
[17:26:49] <WouterJ> Iltar: be aware that you'll have 2 months to make the docs after feature freeze
[17:27:16] <Iltar> Just needs some reorganisation
[17:27:33] <weaverryan> WouterJ That list is subjective, but in a way, yes - it may be helpful to have some goals for the next 5 weeks - I certainly some
[17:28:37] <weaverryan> Should we try to create such a list then? On the core group, Fabien did this once for a patch release - i.e. listed blocker PR's/issues asking for help - it worked fairly well
[17:29:14] <WouterJ> milestones also help with this
[17:29:42] <weaverryan> Related to https://github.com/symfony/symfony/issues/11742 - that's ultimately the discussion: which items do we *really* care about, which are just not good ideas (so let's reject them). And finally, get done what we want to get done
[17:29:57] --> wizhippo (~wizhippo@64.201.57.7) a rejoint #symfony-dev
[17:30:19] <weaverryan> https://github.com/symfony/symfony/milestones/3.0
[17:30:52] <weaverryan> Stof: we've used milestones with limited success in the past (I'm asking because you know about the problems). But what do you think about this?
[17:31:02] <WouterJ> weaverryan, that milestone needs to be cleaned up. 95% of the issues in there were created and added to the milestone in the time were we thought 3.0 was allowed to break things
[17:31:38] <weaverryan> that's perfect - let's do that. That also means that some things should just not be fixed - i.e. issues should be closed
[17:31:47] <Iltar> Should probably also clean up the issue and pr list
[17:32:45] <weaverryan> Iltar: for the 3.0 milestone, or in general? If in general - of course - we just need eager volunteers
[17:32:54] <Iltar> In general yes
[17:33:54] <Iltar> Pr are easy, old ones that cannot be merged and are untouched. Issues need to be checked, can use Carson for that and label them to br removed in the near future
[17:34:34] <Iltar> Status: invalid
[17:34:36] <weaverryan> 👍 we need to be opinionated. Even if you're wrong with your opinion, you'll finally create discussion that will make it more obvious
[17:34:55] <weaverryan> Ok, I'll message the core list - since we're missing many people - about using the milestone special for 3.0 to focus on things that we would want to get done for 3.0
[17:35:27] <weaverryan> Ultimately though - me included - we just need time and effort from people, if you care about an issue
[17:35:59] <WouterJ> a project always needs direction from the core team imo
[17:36:17] <weaverryan> Very good point
[17:36:21] <Iltar> Issues for unsupported versions might be closed already. If it was an issue, it would be an active discussion
[17:36:25] --> jakubzalas (~jakubzala@IW361404.net.t-com.hr) a rejoint #symfony-dev
[17:36:48] <WouterJ> that's also how we handle it in the CMF btw: After each minor release, we discuss for an hour which features we want in the next release. We'll work on those features and everything that comes from the community is a nice bonus :)
[17:36:58] <WouterJ> *everything = mostly other features than discussed
[17:38:23] <weaverryan> Mixing what we'd like to get done with the timed release would be ideal
[17:39:33] <weaverryan> Stof: What's the discussion status of the C extension stuff? It got technical at the end of the mailing list discussion.
[17:40:30] <WouterJ> anyway, have to leave now, sorry o/
[17:40:36] <weaverryan> Oh, and to guys that have been more active then me lately - despite not pushing Carson at all yet, are a few people using it? Asked differently, is it still accurate that we should write a blog post telling people about Carson, etc?
[17:40:37] <Iltar> Cya o/
[17:40:48] <-- WouterJ (~WouterJ@194.121.186.34) est parti (Quit: Nettalk6 - www.ntalk.de)
[17:40:51] <weaverryan> I'm happy to do that - I have been delaying - if it still seems like a valid experiment
[17:41:31] <xabbuh> as far as I have seen it is used by some people
[17:41:47] --> webmozart (~bernhard@IW361404.net.t-com.hr) a rejoint #symfony-dev
[17:42:01] <webmozart> hey there :)
[17:42:09] <Iltar> Hi
[17:42:17] <webmozart> is the meeting happening?
[17:42:17] <xabbuh> users who are not so familiar with the contributing process don't use it, but that's probably simply because they don't know how to use it or if they are allowed to
[17:42:20] <xabbuh> hi webmozart
[17:42:26] <webmozart> apparently yes, great
[17:42:46] <weaverryan> webmozart: I was just asking about carson - if at least some people are using it
[17:43:02] <Iltar> I have not yet tried
[17:43:14] <webmozart> I saw that, yes. It's great that you can already filter some issues by "Status: Reviewed" :)
[17:43:26] <weaverryan> So I will write a blog post about Carson (finally) and then we can finally see if it's helpful and move on from there, etc
[17:43:39] <-- woutersioen (~woutersio@81.83.29.89) est parti (Quit: leaving)
[17:44:23] <webmozart> yes, we should also finish and publish the doc page. I didn't find time for that yet
[17:44:53] <weaverryan> webmozart: if you don't finish that, I'm just going to merge it - changing your "todo" to "webmozart todo" - ok? :P
[17:45:02] <webmozart> haha
[17:45:18] <webmozart> well anybody is free to complete the todo really ;)
[17:45:57] <Iltar> Oh hey look, an easy pick *shuffles away*
[17:46:07] <weaverryan> haha
[17:46:44] <-- steph_py (~Instantbi@hoaproject/contributor/stephpy) est parti (Quit: steph_py)
[17:46:45] <weaverryan> webmozart: yes, but you have to say that on the PR - there was no reply from you. But, in a perfect world, we'd be more aggressive "taking over PR's" like that - we do it commonly in the docs
[17:47:19] <webmozart> just did
[17:47:24] <weaverryan> Great
[17:47:49] <weaverryan> Ok, I have nothing left to discuss - and as I mentioned before, we're short quite a few people today anyways
[17:49:02] <Iltar> getFlashBag()? :3
[17:49:08] <xabbuh> should we talk about the C extension?
[17:49:58] <-- jola (~Thunderbi@2a02:908:f422:ad80:650d:4319:dd78:4a06) est parti (Ping timeout: 252 seconds)
[17:50:26] <weaverryan> xabbuh: I think Stof is gone now
[17:50:36] <webmozart> weaverryan: are you both downtown?
[17:50:40] <weaverryan> So, we should continue that on the mailing list - try to un-stall it
[17:50:45] <xabbuh> Iltar: what exactly was the issue you had with the flash bag?
[17:50:54] <weaverryan> Iltar: Oh yes, you want to add it to the SessionInterface, correct?
[17:51:26] <Iltar> I dont know what I want, but I can do SessionInterface::getFlashBag
[17:51:48] <Iltar> Which breaks getSession on request or I have to inject it as a service
[17:52:31] <xabbuh> was there a good reason initially not to have getFlashBag() in the SessionInterface?
[17:52:36] <Iltar> Yes
[17:53:20] <Iltar> Flashbag is nothing more than a specific type of bag, cant remember which issue it was, but wad explained in detail
[17:54:27] <Iltar> Cant find it atm, on my phone :(
[17:55:38] <Iltar> https://github.com/symfony/symfony/issues/11279
[17:56:06] <Iltar> Its in there somewhere
[17:56:19] <weaverryan> "flash" functionality is really an extra feature of sessions - I don't think having it on SessionInterface makes sense
[17:56:27] <Iltar> Indeed
[17:56:30] <weaverryan> Iltar: remind me of what the problem is?
[17:57:08] <Iltar> $request->getSession() returns the interface
[17:57:31] --> dunglas (~dunglas@37.162.32.30) a rejoint #symfony-dev
[17:57:40] <Iltar> Injection of interface makes it impossible to use too
[17:58:05] <Iltar> So injecting the bag directly is the only solution
[17:58:46] <dunglas> Hi (sorry to be so late)
[17:58:55] <xabbuh> hi dunglas
[17:58:59] <Iltar> Hi
[17:59:18] <weaverryan> Iltar: can you explain the last 2 points again - what is the issue? I understand that $request->getSession() returns the interface, and that doesn't have getFlashbag() on it, which troubles people. But is there a bigger issue? For me, that's not enough
[17:59:30] <weaverryan> dunglas o/ - we're basically finished, but happy to see you
[17:59:40] <xabbuh> Iltar: having a FlasBagAwareSession like you suggested could be an idea so you could check if you can actually use the flash bag
[18:00:20] <Iltar> The issue is that you will call a method that might not exist if you depend on the request
[18:00:22] --> aRn0D1 (~arnaud@bdx.clever-age.net) a rejoint #symfony-dev
[18:01:40] <Iltar> Its a fragile construction
[18:01:49] <weaverryan> I think a FlashbagAwareSession interface would be the only way to solve it. I don't see an issue with trying that
[18:02:36] <xabbuh> indeed, that's my opinion too
[18:02:39] <weaverryan> Yea, the problem makes logical sense to me, but no too much practical sense. In my app, I know what my concrete implementations are. It seems like this is only a problem if a third-party library will receive your SessionInterface, and then needs to know if it can call getFlashbag() on it
[18:02:42] <-- aRn0D (~arnaud@bdx.clever-age.net) est parti (Ping timeout: 250 seconds)
[18:03:00] <xabbuh> if you are optimistic, you simply call getFlashBag() and if you want to do it safely, you first check for that interface
[18:03:03] <Iltar> I had implemented a custom session so I encountered it
[18:03:40] <weaverryan> Iltar: you implemented a custom session without a getFlashBag() and encountered problems where other code was calling getFlashBag() when it did not exist?
[18:03:43] <Iltar> Injecting the bag is easier for services
[18:04:08] <weaverryan> Iltar: I don't understand this last point - "Injecting the bag is easier..."
[18:04:18] <Iltar> Yes, more or less. It got scraped at the end as it was a test internally so it didnt give us trouble
[18:04:36] <Iltar> @session.flash_bag
[18:05:02] <-- jjanvier (~jjanvier@2a01:e35:8be0:760:ba6b:23ff:fe5a:4127) est parti (Quit: Konversation terminated!)
[18:05:12] <-- aRn0D1 (~arnaud@bdx.clever-age.net) est parti (Ping timeout: 264 seconds)
[18:05:18] <Iltar> In controllers and such I started injecting that bag directly
[18:05:39] --> WouterJ (~WouterJ@dsl-087-195-143-158.solcon.nl) a rejoint #symfony-dev
[18:06:06] <Iltar> Saves you a method chain either way.. But it feels nasty
[18:06:39] <weaverryan> Iltar: Do you have a PR yet for this? I basically see your point - so it seems good enough to propose in more detail
[18:06:46] <Iltar> Not yet
[18:07:43] <Iltar> I can work on it and see what it turna out to be
[18:08:12] <Iltar> Frameworkbundle specific most likely
[18:08:37] <-- ZCJ (~chatzilla@94.200.140.42) est parti (Quit: ChatZilla 0.9.92 [Firefox 40.0/20150807085045])
[18:08:50] <weaverryan> try it, based on how important it is to you
[18:09:18] <weaverryan> but do other stuff first :p
[18:10:00] <Iltar> Ye, its not high on my prio lisr, just something that keeps nagging in thr back of my head
[18:10:36] <webmozart> weaverryan: I finished the TODO now. https://github.com/symfony/symfony-docs/pull/5480 should be mergeable whenever you deem it ready
[18:11:11] --> aRn0D (~arnaud@2a01:e35:2420:b2d0:cd89:c46f:b968:f0bb) a rejoint #symfony-dev
[18:11:38] <weaverryan> Iltar: to be fair it nags me too - specifically the auto-completion - so I'd love to have it be perfect... but it's a matter of time
[18:11:45] <Iltar> Yeah
[18:11:57] <weaverryan> Ok, everyone here on Rovinj wants to go swimming apparently, so I will go join them
[18:12:02] <Iltar> @var ftw
[18:12:11] <Iltar> Enjoy!
[18:13:16] <weaverryan> Always nice chatting Iltar - keep up all your good work please!
[18:13:35] <-- dunglas (~dunglas@37.162.32.30) est parti (Ping timeout: 246 seconds)
[18:16:19] --> mmoreram (~mmoreram@50.Red-213-98-183.staticIP.rima-tde.net) a rejoint #symfony-dev
[18:16:24] --> tigitz (~quassel@pha75-h01-31-38-211-251.dsl.sta.abo.bbox.fr) a rejoint #symfony-dev
[18:16:36] <mmoreram> LOL! Supercool! :D
[18:16:37] <mmoreram> Hi there :)
[18:16:58] <webmozart> hi mmoreram :) see you in two weeks, the meeting is over :P
[18:17:03] <mmoreram> ¬¬'
[18:17:14] <webmozart> it's from 5-6pm every second Thursday
[18:17:14] <mmoreram> I was superexcited
[18:17:21] <webmozart> haha sorry dude :)
[18:17:29] <mmoreram> Now I'm going to my bathroom... to cry XD
[18:17:35] <mmoreram> Okay! Next time then :D
[18:17:36] --> dunglas (~dunglas@37.162.32.30) a rejoint #symfony-dev
[18:17:39] <webmozart> I'll send you a package of tissues
[18:17:46] <mmoreram> yes please!
[18:19:19] --> sshaun (~sshaun@unaffiliated/simshaun) a rejoint #symfony-dev
[18:19:58] <-- dbu (~david@IW361404.net.t-com.hr) est parti (Quit: Konversation terminated!)
[18:20:28] <-- timg___ (~timg_____@195.14.225.138) est parti (Remote host closed the connection)
[18:20:56] <-- ewgra (~ewgra@gchq1.acdm.de) est parti (Quit: Leaving.)
[18:21:06] <-- dunglas (~dunglas@37.162.32.30) est parti (Client Quit)
[18:21:46] --> dunglas (~dunglas@37.162.32.30) a rejoint #symfony-dev
[18:23:42] <-- jakubzalas (~jakubzala@IW361404.net.t-com.hr) est parti (Quit: Leaving.)
[18:24:41] <-- webmozart (~bernhard@IW361404.net.t-com.hr) est parti (Quit: webmozart)
[18:26:54] <Stof> weaverryan: sorry, I stopped reading
[18:27:17] <-- dunglas (~dunglas@37.162.32.30) est parti (Quit: Colloquy for iPhone - http://colloquy.mobi)
[18:28:09] <-- WouterJ (~WouterJ@dsl-087-195-143-158.solcon.nl) est parti (Ping timeout: 255 seconds)
[18:28:22] <Stof> for the C ext stuff, we need to make a decision whether we keep them inside the symfony/symfony repo (with all the associated drawbacks, which is what is described in the technical discussion which is arguing on them) or we move it to its own repo, acknowledging the fact that the symfony_debug is a different codebase than the symfony framework
[18:28:27] --> dunglas (~dunglas@37.162.32.30) a rejoint #symfony-dev
[18:29:32] <Stof> weaverryan: the main need for the C ext discussion would be to have Fabien's opinion IMO (most people participating in the discussion voted on splitting it to its own repo)