You must first sign up to be able to contribute.

Version 2 (modified by lsmith, 7 years ago)


We kind of went off script with the topics. Also note that in the end there wasnt a properly organized meeting afterwards .. but still lots of smaller groups discussing topics.

Replacing the current event manager with a Doctrine2 inspired version

No more new major core changes

What to include in the Standard Edition

IRC logs

[17:00] <lsmith> ok ..
[17:00] <lsmith> lets start
[17:01] <lsmith> bschussek would like to pull a wild card
[17:01] <lsmith> and discuss the event manager first
[17:01] <lsmith> he also has to leave early
[17:01] <lsmith> so
[17:01] <lsmith> bschussek: go!
[17:01] <bschussek> so, basically the idea is to change the current implementation of the EventDispatcher to something similar to Doctrine's EventManager
[17:02] → Dominique__ joined the channel.
[17:02] <bschussek> we can't reuse their implementation, because they optimized it for speed and we need more features
[17:02] <bschussek> but we can copy the API, which has several benefits
[17:02] • bshafs|away is now known as bshafs.
[17:02] <bschussek> the benefits are listed here:
[17:03] <lsmith> i guess the key question is how much performance loss is acceptable in what scenario
[17:03] <lsmith> fabpot: found a 5% performance loss in the hello world benchmark
[17:03] <bschussek> to sum up, event listener and dispatcher code becomes more readable, and users profit because of type safety and IDE hinting
[17:03] <lsmith> the loss might be larger bigger with security .. then again it might be lower as soon as you do more work
[17:03] <johanness> where is the loss coming from?
[17:03] <lsmith> johanness: i assume from the additional object creation?
[17:04] <johanness> there is none?
[17:04] <bschussek> lsmith: there is none
[17:04] <Stof> bschussek: reading the point about subscribers let me think that this was exactly was has been changed to lazy-load the listeners some weeks ago
[17:04] <bschussek> Symfony creates Event objects, DOctrine does
[17:04] <lsmith> thought EventArgs are now objects
[17:04] <bschussek> Symfony also creates an Event object when you dispatch it
[17:05] → beberlei joined the channel.
[17:05] <bschussek> here is the EM implementation:
[17:05] <lsmith> err right .. i meant "Event Listeners are objects, not callbacks."
[17:05] <bschussek> that doesn't count either, as in most cases the callbacks are methods of objects too
[17:05] <lsmith> but anyway .. again the key question is how much performance loss is acceptable in what test scenario
[17:06] <lsmith> discussing the exact implementation is beyond the scope of this meeting imho
[17:06] <bschussek> yes
[17:06] <Stof> lsmith: most listeners are still objects method now so the object is also instanciated
[17:06] <bschussek> I have to perform a benchmark, but judging from the above implementation, the performance loss should be minimal
[17:06] <fabpot> lsmith: I think the real question is not about performance
[17:06] <fabpot> but more: do we want to change this now?
[17:07] <fabpot> my point of view is to keep the current implementation
[17:07] <johanness> fabpot, are there reasons beyond the timing of this change?
[17:07] <beberlei> what are the disadvantages of the symfony event listener to remote it btw?
[17:08] <bschussek> beberlei:
[17:08] <fabpot> first reason is obviously the timing
[17:08] <fabpot> then, the current impl is well known (introduced in sf 1.1)
[17:08] <Stof> saying "we change to use the same interface than Doctrine but reimplementing it totally" seems weird when we still have a working implementation of an event dispatcher
[17:08] <fabpot> and last, I don't see any big benefit over the current code
[17:09] <lsmith> i think it will make developing events easier
[17:09] → dawinterfeldt joined the channel.
[17:09] <bschussek> fabpot: what about the benefits I listed in the commit?
[17:09] <fabpot> they are all minor. again, timing is really bad and as there is no big benefit, I'm -1
[17:10] <MagicalGradient> onSuccess(EventInterface $event) protected <-> onSuccess(RequestEventArgs $eventArgs) right one is less readable to me...
[17:10] <Stof> bschussek: the subcriber is not an advantage as it is exactly what was removed in the current implementation to lazy-load listeners
[17:10] <johanness> i think the big benefit is that it is much more explicit
[17:10] <bschussek> MagicalGradient: the name of the event object is a detail. The benefit is that you have an object with explicit methods
[17:10] <bschussek> so no $event->get('request'), but $event->getRequest()
[17:10] <lsmith> that being said .. i do not really know how much performance loss i would find acceptable
[17:10] <bschussek> and no $event->set('response', $response), but $event->setResponse($response) (type hinting!)
[17:11] <bschussek> so the new solution takes error management away from you
[17:11] <lsmith> yeah .. this is where i think it will ease development and debugging of events quite a bit
[17:11] <bschussek> you don't need to check $event->get('response') against an interface, because $event->getResponse() guarantees return values of a specific interface
[17:11] <MagicalGradient> The cool thing with the old implementation is that it uses the ParameterBag which is highly reusable...
[17:11] <fabpot> there is no Chekote/brokentest_democontroller_testindex
[17:11] <fabpot> oops
[17:12] <johnwards> the development and debugging events is key for me. Especially on 3rd party bundles
[17:12] <fabpot> let's try again, there is no $event->set('response', $response) in the current impl AFAIK
[17:12] <beberlei> MagicalGradient: an "array is also highly resuable", generic object collections are not an argument for something imho :)
[17:12] <johanness> fabpot, it's return $response
[17:12] <bschussek> fabpot: no, there is a "return $response" from the listener which is just as bad
[17:12] <johanness> and an additional call to setProcessed(true)
[17:13] <bschussek> when I refactored the code, this was hard to understand
[17:13] <bschussek> "processed" can have so many different meanings
[17:13] <lsmith> we have 3 more mins in this time box
[17:13] <bschussek> when you have custom events, you can tailor the "processed" to your needs
[17:13] <bschussek> for instance, hasResponse() etc.
[17:13] <MagicalGradient> +1 for stopPropagation() though..
[17:13] ← ivoaz left IRC. (Quit: Lost terminal)
[17:14] <Stof> bschussek: this method can also be renamed in the current implementation to make it clearer
[17:14] <MagicalGradient> much more clearer than notifyUntil...
[17:14] <bschussek> Stof: that's not the point
[17:14] • aways|bnc A+
[17:14] <bschussek> Event is used _everywhere_, you can't find a naming that fits every use case
[17:14] <bschussek> but if you have different Event classes, you can adjust the naming
[17:15] <johanness> yeah, personally, i like the change, and it's not as fundamental as ... eager response ;)
[17:15] <bschussek> also, because you implement own Event classes, they can contain their own logic
[17:15] <bschussek> e.g., the Event can decide that it is processed once you call setResponse($response) and that propagation should be stopped
[17:15] <lsmith> even though its a beefed up version of the Doctrine event handler .. its still quite similar
[17:15] <beberlei> bschussek: couldnt you just use specific even timplementations with the current approach also?
[17:15] <bschussek> listeners and dispatchers don't have to care about it
[17:16] <lsmith> so i think most users will need to understand its API anyway eventually
[17:16] <bschussek> beberlei: no, because currently there is no stopPropagation()
[17:16] <lsmith> but .. end of the time box reached
[17:16] <lsmith> we have lots of topics
[17:16] <lsmith> so moving on
[17:16] <lsmith> what to include in the Standard Edition?
[17:16] <bschussek> hum
[17:16] <fabpot> we cannot move on
[17:16] <fabpot> we need to make a decision
[17:16] <bschussek> yes
[17:16] <Stof> bschussek: this is what setProcessed is for
[17:16] <fabpot> and if it takes 1 hour, we won't be able to discuss anything else
[17:17] <lsmith> ok
[17:17] <Stof> stopping the propagation for a notifyUntil
[17:17] <bschussek> Stof: yes, but setProcessed() is semantically different
[17:17] <bschussek> it also says "yes this event was handled"
[17:17] <bschussek> and not just "please, no listener should do anything anymore"
[17:18] <naderman> how is that any different
[17:18] <beberlei> you could have an event handler that processes the result and does not stop the propagation
[17:18] <Stof> and notifyUntil is exactly that: call them until one says it has processed it
[17:18] <bschussek> exactly
[17:18] <bschussek> what beberlei said
[17:18] <beberlei> but you could do the same with notifyUntil
[17:18] <beberlei> just dont call setProcessed
[17:18] <beberlei> its sort of the same, just different api
[17:18] <Stof> just don't call setProcessed in this case
[17:18] <bschussek> beberlei: yes, but then the dispatcher is responsible for using the right method
[17:19] <bschussek> IMO encapsulating this logic in the Event class is much easier to understand
[17:19] <beberlei> call_user_func_array hmm
[17:19] <bschussek> ?
[17:19] <beberlei> well symfony dispatcher uses call_user_func_array, so every callback is allowed
[17:20] <beberlei> wheras doctrine "approach" has specific naming
[17:20] <tech13> Adding the routing logic to the event also makes it more restricted.  Request is processed, therefore since it is a notifyUntil, the additional filters would be skipped.
[17:20] <bschussek> no, I meant dispatcher method
[17:20] <bschussek> notify vs
[17:20] <bschussek> notifyUntil
[17:20] <bschussek> or filter
[17:20] <beberlei> ah
[17:20] <bschussek> tech13: what do you mean?
[17:20] <tech13> er /filters/logging or triggers/
[17:21] <bschussek> there is one more benefit with the new implementation, which is greater flexibility
[17:21] <bschussek> what if you want to filter a value but still stop propagation?
[17:21] → jonwage joined the channel.
[17:21] <tech13> bschussek, so if the event->setProcessed() triggers the event's behavior to stop going to the next listeners,
[17:21] <fabpot> bschussek: then, it's not a filter anymore
[17:21] <MagicalGradient> what if you want to filter a value but still stop propagation? -> true that
[17:22] <bschussek> fabpot: sure, but what do you use instead? notifyUntil with $event->set('foo', 'bar')?
[17:22] <bschussek> don't tell me that's easier
[17:23] <bschussek> any further questions?
[17:23] <fabpot> bschussek: I don't say one is easier/faster/more flexible than the other, I just say that it comes late in the game and that the benefits are not enough to change everything (think core code but also documentation, third-party bundles, ...)
[17:23] <cranberyxl> git status
[17:24] <bschussek> fabpot: we can copy the Doctrine documentation for a start. As for core code, everything has been migrated
[17:24] <fabpot> bschussek: last question: we won't depend on any Doctrine code, right?
[17:24] <beberlei> we are still in PR, so bc breaks even "late" in the game are still something people expect
[17:24] <bschussek> fabpot: no
[17:24] <bschussek> we'd replace the EventDispatcher implementation
[17:25] <lsmith> and i dont think it will affect that many people anyway
[17:25] <lsmith> and those affected will be the more advanced users
[17:25] <MagicalGradient> lsmith, this will break my apps...:D
[17:25] MagicalGradient has userhost and realname Christophe Eblé
[17:25] MagicalGradient is on #symfony-dev
[17:25] MagicalGradient is connected on (Vilnius, Lithuania, EU)
[17:25] MagicalGradient signed on at 07.03.2011 08:04:54 and has been idle for 16s
[17:26] <lsmith> wonder where the opensky guys are
[17:26] <bschussek> jonwage: are you there?
[17:26] <avalanche123> here
[17:26] <jonwage> yes
[17:26] <lsmith> kriswallsmith, avalanche123, jonwage
[17:26] <bschussek> afaik you were interested in that topic too
[17:26] <avalanche123> lsmith hi:)
[17:26] <jonwage> talking about events?
[17:26] <kriswallsmith> oh yeah, meeting
[17:26] → nostrzak joined the channel.
[17:26] <bschussek> yes
[17:27] <lsmith> essentially at this point fabpot isnt convinced that the benefits are worth it to bother at this point
[17:27] <lsmith> actually he doesnt really see the new approach to have much of any benefits to the new approach
[17:28] <lsmith> and we have deemed this topic to require a decision today
[17:28] <bschussek> jonwage, avalanche123, kriswallsmith: what's your opinion on this?
[17:28] <fabpot> lsmith: correct. But I won't use my veto on this one; so for the record, my vote is still -1. But if enough people are indeed in favor of this change, then let's do it (we will still have to work on names though).
[17:28] <jonwage> well, he has to see the benefits...what he's really saying is he doesn't think the benefit is greater then the cost of making the change and causing people to have to upgrade
[17:28] <kriswallsmith> i agree with everything fabpot has said, which is what i've also said on twitter and GH
[17:28] <kriswallsmith> -1
[17:28] <jonwage> technically it has benefits, no matter what ..its not about the technical decision right now..
[17:29] <jonwage> it just sucks for ppl to have to change their code
[17:29] <MagicalGradient> jonwage, +1
[17:29] <jonwage> and it won't technically change much for them..
[17:29] ← hidenorigoto left IRC. (Remote host closed the connection)
[17:29] <jonwage> but i think it is the right implementation for the long term
[17:29] <johanness> +1
[17:29] <bschussek> jonwage: what if we use a "mostly" BC solution?
[17:30] <vincentl> hey for the posts at symfonydevs, do they get validated by a moderator?
[17:30] <fabpot> bschussek: nope, we do the change or we don't change anything; but there is no point is being mostly compatible
[17:30] <jonwage> bschussek: that can help offset set it some but the cost of rewriting the application event code if you make use of lots of events could be a lot
[17:30] <bschussek> fabpot: what I mean is that I already taught the manager to accept callbacks
[17:31] <jonwage> bschussek: i think we should do it, so it adds 1-2 weeks of time on to the timeline for this change
[17:31] <jonwage> i think it is worth it for the next 10 years we will be building on symfony2 :)
[17:31] <bschussek> I agree
[17:31] <bschussek> votes?
[17:31] <jonwage> +1
[17:31] <pgodel_wor> if it really has technical benefits, then right now is not too late to make the change
[17:31] <lsmith> ok .. so i think at this point we can probably vote .. the vote result would just be "for consideration" for fabien
[17:32] <lsmith> he is the release manager
[17:32] <lsmith> and yes .. its late in the game
[17:32] <lsmith> ok?
[17:32] <kriswallsmith> i still don't see the technical benefits... but i want to see them :)
[17:32] <bschussek> kriswallsmith:
[17:32] <jonwage> they are all not totally tangible things kris
[17:32] <jonwage> its more about the quality of the end users implemented code
[17:32] <jonwage> if you have lots of events
[17:32] <jonwage> whats gonna be better, a class filled with different methods
[17:32] <bschussek> yes. You notice it when you use it
[17:32] <jonwage> handling events
[17:32] <jonwage> or multiple classes
[17:32] <jonwage> w
[17:33] <jonwage> ith clear interfaces
[17:33] <jonwage> with a name like PreUpdateEvent
[17:33] <jonwage> you know what that event gets
[17:33] <jonwage> the IDE can read it
[17:33] <jonwage> make sense?
[17:33] <jonwage> in symfony1 events are a mess because of this
[17:33] <pgodel_wor> that's how most other languages do events, I think
[17:33] <lsmith> right now there is a lot of stuff that relies on strings .. rather than class/interfaces
[17:33] <kriswallsmith> it's the binding of event name to method name?
[17:33] <tech13> I saw mention of something about lazy-load listeners.  How does that look in the DIC/XML?
[17:33] <bschussek> kriswallsmith: this, and that events use tailored Event objects
[17:34] <bschussek> so $event->getRequest() instead of $event->get('request')
[17:34] <jonwage> its just more close to the side of pure oo
[17:34] <kriswallsmith> bschussek: we can do that with the current code
[17:34] <avalanche123> bschussek, we could still tailor events as is, no? but subclassing Event
[17:34] <bschussek> or $event->setResponse($response) instead of return $response
[17:34] <avalanche123> *by
[17:34] <bschussek> I'm repeating myself, we currently don't have stopPropagation()
[17:34] <kriswallsmith> avalanche123: exactly
[17:34] <bschussek> without this, we can't do this
[17:34] <kriswallsmith> fabpot has explained that before -- this is based on apple's pattern
[17:35] <kriswallsmith> but we can change that within the current code
[17:35] <beberlei> i am +1 for this change also, it benefits in the long run
[17:35] <bschussek> kriswallsmith: to repeat my example, what if you want to filter a value, but stop propagation?
[17:35] <bschussek> you can't
[17:35] <fabpot> bschussek: and I will repeat myself: it's not filter then
[17:35] <bschussek> you can hack around it by using notifyUntil() with $event->set('foo', 'bar'), but that's not really clear
[17:35] <bschussek> fabpot: I never said that, I'm talking about realizing features, not naming things
[17:36] <fabpot> but anyway, I think we have discussed everything here, just let's vote and please only vote if you have actually had a look at the code and only if you understand the pros and cons
[17:36] <johanness> :)
[17:36] <MagicalGradient> -1
[17:36] <bschussek> +1
[17:36] <johanness> +1
[17:36] <kriswallsmith> -1
[17:37] <lsmith> what a tight race :)
[17:37] <avalanche123> could we do it in steps maybe? as in make specific even subclasses first?
[17:37] <kriswallsmith> it's neck and neck!
[17:37] <avalanche123> *event
[17:37] <bschussek> avalanche123: no, it wouldn't make sense
[17:38] <beberlei> +1
[17:38] <avalanche123> I can't vote, as I don't see strong improvements honestly, its just different, not better
[17:38] <lsmith> avalanche123: well that sounds like a -1 to me ..
[17:38] <fabpot> avalanche123: the vote is not about the technical side of things. It is whether we do the change or not
[17:38] <avalanche123> yeah -1
[17:38] ← rande left IRC. (Ping timeout: 252 seconds)
[17:38] <lsmith> obviously a change needs to have improvements
[17:39] <bschussek> jonwage?
[17:39] <lsmith> ok .. so then with fabpot -1 .. its -4 to +3
[17:39] <jonwage> I am +1 for the change
[17:39] <lsmith> ok +4 -4
[17:39] <bschussek> lsmith?
[17:39] <lsmith> i am not going to vote
[17:39] <avalanche123> aww
[17:40] <fabpot> naderman?
[17:40] <naderman> fabpot?
[17:40] <naderman> sorry wasn't following for a minute
[17:40] <naderman> vote on events?
[17:40] <bschussek> do you have a clear opinion and vote on events?
[17:40] <fabpot> naderman: ok, yes
[17:40] <lsmith> from what bschussek explained it sounds like a change for the better .. but i dont know the topic enough
[17:40] <naderman> +1 from me
[17:40] <jonwage> hmm
[17:40] • DeluxZ is now known as DeluxZ`food.
[17:40] <jonwage> wait have we shown examples?
[17:40] <jonwage> has everyone seen examples
[17:41] <kriswallsmith> yes
[17:41] <avalanche123> I read through commit message, but I would appreciate and example
[17:41] <naderman> mostly because of the notifyUntil stuff though
[17:41] <lsmith> the pull is one giantic example :)
[17:41] <beberlei> everybody that voted, must have read the commit otherwise his vote is void ;)
[17:41] <lsmith> hrhr
[17:41] <bschussek> just a moment...
[17:41] <lsmith> so now we are at -4 +5
[17:41] <jonwage> because all I see is how an old project of mine looks with symfony events and how it would look if i organized it better  with Doctrine events and the specific event type classes
[17:41] <bschussek>
[17:41] <jonwage> :)
[17:41] <johanness> we should create a test for everyone to pass before he can vote :)
[17:41] <jonwage> lol
[17:42] <avalanche123> :)
[17:42] <bschussek>
[17:42] ← johnwards left IRC. (Ping timeout: 250 seconds)
[17:43] <MagicalGradient> IMHO Only stopPropagation worth the change...
[17:43] <jonwage> so, we always talk about killing the magic in symfony2 :) that was a huge goal
[17:43] <bschussek>
[17:43] <jonwage> and the Event class here is still so magical
[17:43] <jonwage> we want explicitness right?
[17:43] <lsmith> i definately like the new versions better .. but like i said .. i dont know the current event system good enough to tell if similar improvements could be gotten by subclassing Event
[17:43] <jonwage> well explicit method names and explicit arguments for that event
[17:43] → rande joined the channel.
[17:43] <jonwage> is what this change is all about
[17:43] <jonwage> so i dont understand why we wouldnt do it
[17:43] <fabpot> jonwage: magic != explicit
[17:43] <jonwage> you have magic here with the event object
[17:43] <jonwage> how do I know what data is in it?
[17:43] <jonwage> i have to do what
[17:43] <jonwage> check the docs
[17:43] <jonwage> or print_r it
[17:44] <jonwage> if it was proper i could just use oo and check the api
[17:44] <jonwage> i know what object it is
[17:44] <jonwage> i can just click the method name in my ide
[17:44] <jonwage> but in the old symfony1 way of doing things this was never possible
[17:44] <avalanche123> well we could get rid of ParameterBag then in favor of request specific classes as in HomepageParameterBag, LoginParameterBag, etc
[17:44] <jonwage> but i think weve made a clear decision early on to FIX that problem
[17:44] <kriswallsmith> it's a convention, that's all
[17:44] → Groove- joined the channel.
[17:44] <bschussek> avalanche123: that doesn't help, you're still dealing with Event objects, not ParameterBags
[17:44] <jonwage> ya, symfony1
[17:45] ← ofus_ left IRC. (Read error: Connection reset by peer)
[17:45] <fabpot> do we still wait for someone to vote?
[17:45] <Stof> I'm +1
[17:45] → ofus_ joined the channel.
[17:45] <avalanche123> bschussek, I was just giving example
[17:45] <bschussek> avalanche123: sound's undecided, and as I know him he'll change his mind once he fully understands :)
[17:45] <avalanche123> bschussek :)
[17:46] <jonwage> getting a FilterResponseEventArgs $eventArgs instead of a EventInterface $event is way more clear to me
[17:46] <avalanche123> I am not 100% sure, that's true
[17:46] <kriswallsmith> i think we're throwing the baby out with the bathwater
[17:46] <jonwage> i cant just follow the class here to know what $event is
[17:46] <jonwage> its a dead end for the developer
[17:46] <lsmith> -4 +6
[17:46] <fabpot> ok, so, the community has decided
[17:46] <jonwage> of course, the people who dont vote the same as what i think just dont understand fully :) har har
[17:46] <cranberyxl> Event is just a message, it's up to the listener to interpret it
[17:47] <Stof> I think the name should be Event and not eventArgs as it is the event, not just the arguments but this can still be changed
[17:47] <avalanche123> actually, yes, I agree too, its like for parameters array instead of specific dependencies
[17:47] <bschussek> Stof: I agree, I will change this name
[17:47] <fabpot> Stof: we will need to work on the names for sure
[17:47] <jonwage> cranberyxl: right, what i am saying is with the new implementation the Message sis way more loud and clear
[17:47] <lsmith> ok next topic then
[17:47] <bschussek> it was taken from Doctrine
[17:47] <lsmith> what to include in the Standard Edition?
[17:47] <fabpot> lsmith: I have something else before continuing
[17:47] <avalanche123> I'm still unsure if its worth it
[17:47] <fabpot> sorry about that
[17:47] <lsmith> fabpot: ooookay :)
[17:47] <bschussek> avalanche123: let's talk about it later on IM?
[17:47] <fabpot> I want to be sure that everyone is on the same page about the current state of Symfony2
[17:48] <fabpot> is *now* on
[17:48] <fabpot> we are entering the final release cycle of Symfony2 and we badly need to finish everything, to stabilize features we have, to document them, and much more
[17:48] <avalanche123> bschussek yup
[17:48] <fabpot> and we all have other things to do of course
[17:48] <fabpot> just for the record, we still do not have a form component, locale is not finished yet, documentation is far from finished, ...
[17:48] <fabpot> so let's make it clear that this is the last discussion about changing a core feature like the one we have just discussed
[17:48] <lsmith> conversion to translation keys
[17:49] <fabpot> I will use my veto on any other big change before Symfony 2.0 final version, no matter what
[17:49] <kriswallsmith> ok
[17:49] <kriswallsmith> brb
[17:49] <lsmith> fabpot: does that include stuff like subrequest security? early response headers?
[17:49] <bschussek> fabpot: Locale is mostly finished, I'll send you the PR
[17:50] <fabpot> lsmith: I'm not talking about the current discussions we have. I'm talking about new changes
[17:50] <lsmith> ah ok
[17:50] <bschussek> I need to recheck everything again, but as far as I'm informed we can start testing
[17:50] <igorw> bschussek: did you see the PR message? I'd like to still fix the naming, but apart from that we're done
[17:50] <bschussek> igorw: yes
[17:50] <lsmith> yeah .. i agree .. the world must fall if we open another major topic at this point
[17:50] <naderman> fabpot: line needs to be drawn somewhere if it's ever going to get finished, so might as well be here and now :)
[17:51] <lsmith> ok .. so next topic? :)
[17:51] <beberlei> with the current architecture there is no problem changing stuff later also
[17:51] <fabpot> lsmith: yes, please
[17:51] <lsmith> beberlei: especially if we go private :)
[17:51] <lsmith> what to include in the Standard Edition?
[17:51] <lsmith> basically this was spawend over the inclusion of FrameworkExtraBundle
[17:51] <lsmith> though i generally got the vibe that the bulk of the people didnt mind to have it in
[17:51] <lsmith> but just that this is obviously not in core ..
[17:52] <lsmith> so the question was should it be moved to core?
[17:52] <johanness> what is the core?
[17:52] <lsmith> or should other non Symfony namespaced stuff potentially also be in SE
[17:52] <fabpot> lsmith: yes
[17:52] <lsmith> johanness: s/core/Symfony namespaced code
[17:52] <fabpot> the SE is about choosing a set of bundles, they do not need to be in "core"
[17:52] <lsmith> k
[17:52] <avalanche123> core is the minimum for framework to work imo
[17:52] <jonwage> fabpot how are we building the distributions?
[17:52] <jonwage> are you hand building them?
[17:52] → kris|m joined the channel.
[17:53] ← nostrzak left IRC.
[17:53] <fabpot> jonwage: bin/ to build the package
[17:53] <beberlei> avalanche123: well standard distribution is not called "core distribution"
[17:53] <lsmith> so we should start thinking if there is anything else to include ..
[17:53] <beberlei> its just what people should hcoose if they are indifferent
[17:53] <avalanche123> beberlei, exactly my point, no need to move bundles in core if they are part of standard distro
[17:53] → johnwards joined the channel.
[17:53] <lsmith> and if so what .. not sure if we need a formal process here .. or if we just do adoc vote decisions
[17:53] <avalanche123> standard is just optimized for solving standard problems
[17:53] <lsmith> agreed
[17:53] <fabpot> beberlei: yes, it's the bundles that most people will need for most common projects
[17:54] <Stof> the issue with SE is that it provides MongoDB but provide the 2.0.2 release of Doctrine\Common which is incompatible with it
[17:54] <fabpot> so, ORM is in, ODM is not for instance
[17:54] <jonwage> fabpot: it would be nice if users could go to the symfony website and build their own distribution, and everything is built for you by combining the chosen features/bundles + symfony2 directory structure and configuration..and packages it for you for download
[17:54] <Stof> fabpot: currently it is
[17:54] <lsmith> right .. so not all "core" Bundles will be included
[17:54] <beberlei> Stof: we already discussed that, the Common interfaces will be removed from mongodb for the first release
[17:54] <jonwage> we could have the 3-4 distributions we offer but really it is a pre chosen list of features/bundles
[17:54] <beberlei> jonwage has it on the todo list
[17:54] <jonwage> ok
[17:54] <johanness> jonwage, we need naderman sat resolver for this
[17:54] <jonwage> because then it doesnt really matter what we put in each distribution
[17:54] <fabpot> jonwage: this is what the packaging system is all about
[17:55] <jonwage> and we wouldnt ve having this discussion
[17:55] <jonwage> be*
[17:55] <jonwage> people need to not worry so much about what is in a distribution
[17:55] <naderman> err yes, it'd just be a set of default installed packages
[17:55] <jonwage> who cares, you can get exactly what you want just as fast
[17:55] <lsmith> jonwage: yes .. distributions are just a set of "defaults"
[17:55] <kris|m> +1 ala mootools
[17:55] <jonwage> cool
[17:55] <naderman> like if you get a linux distro it comes with a predefined set of packages that are installed
[17:55] <jonwage> can't wait :)
[17:55] <fabpot> jonwage: the idea of the distrib is to get started without messing with the CLI
[17:55] <Stof> btwn why is there no PR7 tag in the core repo ?
[17:55] <naderman> I need to hurry up :(
[17:55] <beberlei> so we agree? next topic :D
[17:56] → seb_m joined the channel.
[17:56] <fabpot> let's move on then
[17:56] <jonwage> ya you need to finish it, i feel like its a Mirage right now :)
[17:56] <Stof> this means the SD will always use the master branch when downloading it without the vendors
[17:56] <rande> a linux distribution also have a command to install new package ;)
[17:56] <lsmith> the topic isnt answered for me at all
[17:56] <lsmith> the question was what is in SE and what isnt
[17:57] <fabpot> lsmith: the real question is: what would you want to include that is not included yet?
[17:57] <MagicalGradient> ViewBundle xD
[17:57] <lsmith> ViewBundle for example :)
[17:57] <Stof> maybe FOS UserBundle for example
[17:57] <jonwage> Its still early, wouldn't we want to make everything easily available to them right now?
[17:57] <kris|m> -1
[17:57] <lsmith> FOSUserBundle
[17:57] <johanness> suprisingly, i think the SecurityBundle, and SecurityExtraBundle should be in there as well
[17:58] <lsmith> yeah .. i guess we can easily add new Bundles
[17:58] <fabpot> johanness: there already are in
[17:58] ← dbu left IRC. (Remote host closed the connection)
[17:58] <beberlei> Fos user bundle is way to unstable and still needs tests
[17:58] <fabpot> johanness: ah, not the SecurityExtraBundle
[17:58] <beberlei> it always breaks on me :D
[17:59] <lsmith> yes .. it needs tests!
[17:59] <lsmith> but being part of SE can be a motivation there :)
[17:59] <lsmith> ViewBundle also doesnt have tests
[17:59] <beberlei> no
[17:59] <fabpot> I think that this discussion about what to include should be postponed until we have stabilized things a bit more
[17:59] <beberlei> its tests first
[17:59] <beberlei> not tests when its in standard edition
[17:59] <beberlei> :p
[17:59] <lsmith> beberlei: agreed
[17:59] <lsmith> fabpot: aka .. so after RC1
[17:59] <lsmith> i can live with that
[18:00] <fabpot> lsmith: that makes sense I think
[18:00] <lsmith> ok time is up ..
[18:00] <lsmith> so we want to continue?
[18:00] <lsmith> hold an extra meeting?
[18:00] <lsmith> or just postpone until next week .. and talk on the ml in the mean time
[18:00] <beberlei> btw can someone recommend a symfony2 basics talk for me?
[18:00] <beberlei> i havent done anything for mine in the phpugcgn tomorrow :)
[18:00] <johanness> security subrequests should be solved asap
[18:01] <johanness> same as early response headers
[18:01] <fabpot> lsmith: that's what we get when deciding to change big things in the current core... delay
[18:01] <kris|m> I can continue
[18:01] <beberlei> well, i agree we dont have time for delays
[18:01] <beberlei> so continue or drop
[18:01] <Stof> I can too
[18:01] <lsmith> ok .. so lets focus on the topics that affect core
[18:01] <fabpot> I need to go for lunch now
[18:02] <beberlei> break?
[18:02] <lsmith> fabpot: i hope you mean dinner :)
[18:02] <lsmith> ok so break ..
[18:02] <pgodel_wor> lsmith: he's in canada
[18:02] <beberlei> i think he is one of the poor people freezing to death i ncanda :)
[18:02] <lsmith> i would say .. can we do a meeting tomorrow at 17:00?
[18:02] <fabpot> I will be back in about an hour
[18:02] <lsmith> pgodel_wor: oh right
[18:03] <lsmith> i will not be around then .. but i know that johanness will represent me well :)
[18:03] • lsmith kris|m
[18:03] ← bschussek left the channel.
[18:03] ← johnwards left IRC. (Ping timeout: 255 seconds)
[18:03] kris|m has userhost and realname Kris Wallsmith
[18:03] kris|m is on #symfony-dev
[18:03] kris|m is connected on (Evry, FR)
[18:03] kris|m signed on at 10.03.2011 17:51:55 and has been idle for 2min 37s
[18:03] <beberlei> running home then
[18:03] <kris|m> -1 for johanness getting 2 votes :)
[18:03] • bshafs is now known as bshafs|away.
[18:03] <lsmith> that was supposed to me /whois
[18:04] ← beberlei left IRC. (Quit: ChatZilla 0.9.86 [Firefox 3.6.15/20110303024726])
[18:04] ← pentarim left IRC. (Remote host closed the connection)
[18:04] <lsmith> kris|m: we have the same opinion on the matter :)