Log of #symfony-dev meeting 20111103 (all times GMT-4)

transcript.txt

Nov 03 12:00:08 *	lsmith has changed the topic to: http://www.doodle.com/pn4r2x9xmrqd6ubn | http://symfony.com/doc/current/contributing/
Nov 03 12:00:55 <Seldaek>	oh, I didn't see the new topics
Nov 03 12:01:57 <lsmith>	ok lets start i guess .. jmikola|w, fabpot, johannes__, Stof, couac .. ping
Nov 03 12:02:23 <couac>	yep
Nov 03 12:02:39 <jmikola|w>	improving flash messages leads by a wide margin: drak 
Nov 03 12:02:42 <lsmith>	most popular topic this week seems to be Improve flash messages: http://bit.ly/vqnTFT
Nov 03 12:03:09 *	lstrojny has quit (Quit: lstrojny)
Nov 03 12:03:22 <lsmith>	drak: could you briefly explain the purpose .. then again i am not even sure if there is any big controversey at this point ..
Nov 03 12:03:37 *	kriswallsmith (~kriswalls@c-24-21-247-81.hsd1.or.comcast.net) has joined #symfony-dev
Nov 03 12:03:37 *	kriswallsmith has quit (Changing host)
Nov 03 12:03:37 *	kriswallsmith (~kriswalls@symfony/developer/kriswallsmith) has joined #symfony-dev
Nov 03 12:03:38 <drak>	sure
Nov 03 12:03:42 <lsmith>	so the question is more to fabpot do you have any questions or concerns?
Nov 03 12:04:02 <couac>	why do we need some levels ?
Nov 03 12:04:08 <couac>	the key message cannot do the job ?
Nov 03 12:04:35 <lsmith>	ok .. then lets have drak briefly explain the purpose first
Nov 03 12:04:37 <drak>	currently flash messages are only of one type, so it's not possible to have differnet levels.  For example, info, warning, error.  This is useful because when you render the flashes, you can then style them accordingly
Nov 03 12:05:03 <fabpot>	of course, you can have levels
Nov 03 12:05:09 <fabpot>	the is what you can use the key for
Nov 03 12:05:13 <couac>	+1
Nov 03 12:05:16 <lsmith>	also remember that usually you dont want to tie the displaying of the flash messages to outputting layer
Nov 03 12:05:33 <drak>	it's simply categorising them
Nov 03 12:05:47 <fabpot>	the key is all you need to categorize them
Nov 03 12:05:48 <lsmith>	which means it would be good to "standardize" categorizing things a bit
Nov 03 12:05:53 <fabpot>	as the key can be anything you want
Nov 03 12:06:18 <lsmith>	fabpot: i am not sure how you display flash messages in your applications
Nov 03 12:06:24 <lsmith>	but in mine i have some logic in the layout
Nov 03 12:06:24 <couac>	info, warning, error don't cover all cases
Nov 03 12:06:31 <jmikola|w>	drak: opensky practically had a need for something like this, and it ended up being a service class on top of sessions: https://gist.github.com/388dc7f1ed977c396e7f
Nov 03 12:06:50 <lsmith>	now if every bundles uses the flash messages with a key if its choosing its kinda tricky
Nov 03 12:07:04 <jmikola|w>	the other concern was ensuring "flash" messages could stick around until we requested them, so it has a getOnce() method in conjunction with the buckets for types
Nov 03 12:07:13 <rande>	The admin bundle has its own message key too
Nov 03 12:07:20 <rande>	like the idea
Nov 03 12:07:23 <lsmith>	jmikola|w: right .. i remember that we even once agreed on adding a message class for this to core
Nov 03 12:07:29 *	jakubzalas has quit (Quit: Leaving.)
Nov 03 12:07:46 <drak>	I personally dont like they keys, I would just stack them with addFlash($message, $type)
Nov 03 12:08:20 <lsmith>	http://trac.symfony-project.org/wiki/IRCLogs20101216
Nov 03 12:08:26 <couac>	doesn't change anything if you consider the key as your type
Nov 03 12:08:30 <drak>	but the person who started the PR originally has them
Nov 03 12:08:31 <rande>	but not sure it is the framework job to do define such constants
Nov 03 12:09:01 <fabpot>	rande: it's not
Nov 03 12:09:08 <drak>	ok I have the code in front of me - the current code only allows one flash per $name.  That's not very flexible when you might need to issue many flashes.
Nov 03 12:09:14 <fabpot>	the flash system is just a simple key/value system that is only persisted for the very next request
Nov 03 12:09:32 <lsmith>	well there has to be a standard .. otherwise your layout template will have to have a gigantic switch statement
Nov 03 12:09:50 <rande>	lsmith: agree on that
Nov 03 12:09:55 <lsmith>	or you need a listener just to "fix" the flash statements
Nov 03 12:09:57 <drak>	@fabpot - having constants means you dont need to to know the internals of how the flashes are stored.
Nov 03 12:10:16 <lsmith>	right now the feature imho is useless .. we would be better off to remove it entirely
Nov 03 12:10:50 <rande>	drak: a framework provides foundation, the PR starts to build something on top of it
Nov 03 12:11:00 <fabpot>	lsmith: ?!
Nov 03 12:11:10 *	dbu has quit (Read error: Connection reset by peer)
Nov 03 12:11:14 <Seldaek>	to me flash keys are similar as the priorities for event listeners, without some guidelines ("standardization") from our side, it ends up in a giant mess where nobody knows what to use
Nov 03 12:11:33 <rande>	Seldaek: like the log then
Nov 03 12:11:34 <lsmith>	fabpot: the purpose of flash messages is in 99% of the cases to display a simple message
Nov 03 12:11:53 <fabpot>	lsmith: correct, that's why adding yet another way to categorize them is useless
Nov 03 12:11:55 <drak>	as it stands now, flashes cannot store multiple flashes for a given type.  this PR allows you to categorize flashes and have many flash messages per category
Nov 03 12:11:58 *	rooster has quit (Remote host closed the connection)
Nov 03 12:12:13 <johannes__>	why not create a service which wraps the session and add your logic there? https://gist.github.com/e8e11830614ba53661fa
Nov 03 12:12:17 *	bergie has quit (Ping timeout: 260 seconds)
Nov 03 12:12:19 <jmikola|w>	drak: the point is that flash has no types to begin with :)
Nov 03 12:12:20 <fabpot>	flashes are used to display the result of an action after a post, I don't see how you can have many of them
Nov 03 12:12:24 <lsmith>	fabpot: the flash system is only useful if you write all the bundles that set them
Nov 03 12:12:46 <jmikola|w>	johannes__: +1, looks like another alternative to the Notifier class opensky used
Nov 03 12:13:09 <fabpot>	ok, let's given guidelines about which ones should be used in thrid-party bundles (error, warning, ...)
Nov 03 12:13:12 *	phidah (~phidah@79.138.244.119.bredband.3.dk) has joined #symfony-dev
Nov 03 12:13:12 <lsmith>	there can be multiple .. one that says "add a user" another one that says "notice that you will now have to do this, this and this"
Nov 03 12:13:13 <jmikola|w>	it's really trivial to create a specific service to meet your own needs for notification/flash messages
Nov 03 12:13:53 <couac>	yeah johannes__ code is quite simple and logic
Nov 03 12:13:58 <rande>	jmikola|w: the point is about integrating different bundles from different vendors
Nov 03 12:14:05 <lsmith>	jmikola|w: so we are talking about making it easy to plug in some code when you set flashes?
Nov 03 12:14:18 <rande>	if each vendors have their own key, it will be a mess
Nov 03 12:14:28 <lsmith>	ok .. we are reaching the end of the time box
Nov 03 12:14:50 <drak>	This is HttpFoundation, and session flashes are pretty much a standard requirement for any web application - everything has them. The flash system here is just too simplistic.
Nov 03 12:15:06 <drak>	re categories, it's a bit like logging - there are some pretty standard log levels.
Nov 03 12:15:18 *	lstrojny (~lstrojny@p5099f5c8.dip0.t-ipconnect.de) has joined #symfony-dev
Nov 03 12:15:18 <lsmith>	another approach would be to move the flash system out of the session class
Nov 03 12:15:22 <drak>	for flashes there are usually a max of 4 colours.
Nov 03 12:15:22 *	dbu (~david@194.230.159.81) has joined #symfony-dev
Nov 03 12:15:35 <lsmith>	to make it cleaner to replace it with something more sophisticated
Nov 03 12:15:41 <drak>	red, green, yellow and maybe blue.
Nov 03 12:16:01 <jmikola|w>	lsmith: i think if SonataAdminBundle ships with its own templates, it could easily use it's own service and templating helper for custom flash messages
Nov 03 12:16:15 <jmikola|w>	likewise if someone made a bundle integrating Twitter bootstrap
Nov 03 12:16:24 <lsmith>	jmikola|w: and what if there is a listener that some other guy writes that does things differently?
Nov 03 12:16:29 <drak>	yes, pulling it out would also be an option - but remember this is more than just about types, it's about being able to have multiple flashes for a given type/name
Nov 03 12:17:01 <drak>	addFlash() at least is missing (adding to a stack)
Nov 03 12:17:14 <lsmith>	drak: agreed
Nov 03 12:17:29 <jmikola|w>	lsmith: i've personally never used stock templates/controllers of any bundle, so i'd be inclined to use my own service from the get-go :)
Nov 03 12:17:30 *	marijnh has quit (Quit: marijnh)
Nov 03 12:17:47 <fabpot>	I've just had a look at Rails implementation
Nov 03 12:17:48 <lsmith>	jmikola|w: thats the point! .. you are going to use other peoples bundles and listener
Nov 03 12:17:56 <fabpot>	they have the same key/value system
Nov 03 12:18:06 <lsmith>	but you then want to have a sensible way to dispplay their flash messages
Nov 03 12:18:12 <fabpot>	but they also have two convenience method to get/set "notice" and "alert"
Nov 03 12:18:20 <lsmith>	without having to write a ton of code to categorize 3rd party flash messages
Nov 03 12:18:29 <jmikola|w>	fabpot: do those add a basic prefix to the key?
Nov 03 12:18:46 <fabpot>	no, getNotice() just return the value of the "notice" key
Nov 03 12:18:55 <fabpot>	there is no special logic, just a convenience shortcut
Nov 03 12:19:13 <fabpot>	so instead of getFlash('notice'), you can use getFlashNotice()
Nov 03 12:19:25 <rande>	So a notifier service need to be created
Nov 03 12:19:41 <rande>	with a dependency to the session
Nov 03 12:19:45 <drak>	In Zikula we do it quite simply - https://github.com/zikula/core/blob/release-1.3/src/lib/Zikula/Session.php#L117
Nov 03 12:19:54 <rande>	like johannes__ shows us
Nov 03 12:20:00 <fabpot>	in rails, this is done with a middleware (so an event listener in Symfony2)
Nov 03 12:20:01 <drak>	which is pretty much how Sf2 does it, but using a stack
Nov 03 12:21:11 <lsmith>	so we need to figure out the direction: add a message class, move the flash stuff out of session to make extending cleaner, add the stack feature as in the PR, do nothing
Nov 03 12:21:13 <drak>	Please remember, I simply integrated the changes of an existing PR.  It could be reworked.
Nov 03 12:21:42 <drak>	there is the issue of BC too right?
Nov 03 12:21:51 <lsmith>	or just do them all and pick then :)
Nov 03 12:22:31 <drak>	:)
Nov 03 12:22:49 <jmikola|w>	lsmith: if a stack/bucket is implemented, i think the method should at least change from set() to add()
Nov 03 12:22:50 <fabpot>	moving some logic to an event listener is something that was on my todo list
Nov 03 12:23:04 <lsmith>	ok .. but we are well over the timebox .. think we have some more to discuss in the PR and mor the mailinglist
Nov 03 12:23:14 <drak>	ok
Nov 03 12:23:22 <fabpot>	again, the flash system should be kept as a simple key/value store
Nov 03 12:23:34 <lsmith>	the 2nd most popular topic is "how to grow the reach of Symfony2 components?" but i feel its a bit open ended .. so if its ok we will discuss it last
Nov 03 12:23:50 <lsmith>	[SecurityBundle] Added a way to extend the providers section of the config: http://bit.ly/nvOqTC
Nov 03 12:23:54 <lsmith>	is Stof here?
Nov 03 12:23:54 <fabpot>	what I can say is that I'm going to work on some documentation
Nov 03 12:24:02 <couac>	lsmith: stof will be late
Nov 03 12:24:07 <lsmith>	doh
Nov 03 12:24:21 <couac>	yeah he's at school atm
Nov 03 12:24:26 <lsmith>	k
Nov 03 12:24:44 <lsmith>	forgot to mention in regards to the flash discussion .. i guess it related to "Added structured namespacing to session attributes: http://bit.ly/vakgGq" as well
Nov 03 12:24:53 *	jakubzalas (~Adium@93.191.34.130) has joined #symfony-dev
Nov 03 12:24:59 <lsmith>	or could relate to ..
Nov 03 12:25:12 <lsmith>	anyway
Nov 03 12:25:19 <drak>	well, flashes and attributes are separate things really..
Nov 03 12:25:23 <lsmith>	then a quick one (i think) before beberlei returns and we can talk about the ORM
Nov 03 12:25:24 *	sblack (~sblack@c-67-180-89-162.hsd1.ca.comcast.net) has joined #symfony-dev
Nov 03 12:25:28 <lsmith>	location of tests for bridges and components in the symfony repo
Nov 03 12:25:39 <couac>	don't we talk about Stof's PR ?
Nov 03 12:25:42 <lsmith>	fabpot is there any reason why the tests are not within their respective dirs?
Nov 03 12:25:56 <fabpot>	2 reasons : an historical one and a practical one
Nov 03 12:25:57 <lsmith>	couac: think it doesnt make sense without him around
Nov 03 12:26:16 <lsmith>	ok .. whats the practical one?
Nov 03 12:26:19 <fabpot>	with the tests outside of the main namespace directory, the read-only repositories are only about the code
Nov 03 12:26:32 <fabpot>	so, you just get the code without anything else
Nov 03 12:26:42 <lsmith>	fabpot: ah ok .. to me thats actually a disadvantage
Nov 03 12:26:47 <fabpot>	which can be seen as a drawback too
Nov 03 12:27:06 <lsmith>	fabpot: but it might be something to ask the wider audience
Nov 03 12:27:10 <fabpot>	but, for some optional features, you actually need some other components
Nov 03 12:27:20 <lsmith>	fabpot: right
Nov 03 12:27:34 *	sblack (~sblack@c-67-180-89-162.hsd1.ca.comcast.net) has left #symfony-dev
Nov 03 12:27:35 <fabpot>	which would mean adding a bunch of if statements everywhere
Nov 03 12:27:48 <fabpot>	that's why they are isolated into their own directory
Nov 03 12:28:00 <rande>	can composer solve this issue ?
Nov 03 12:28:09 <lsmith>	then we should likely just make it easy for people to find the tests from the read-only repo's
Nov 03 12:28:22 <fabpot>	and as any PR must be done on symfony/Symfony anyway, running the tests on the standalone components is not something that useful IMO
Nov 03 12:28:59 <lsmith>	fabpot: i guess i came to wonder this mostly because of the lack of docs
Nov 03 12:29:21 <fabpot>	docs are coming ;)
Nov 03 12:29:23 <lsmith>	because tests tend to be useful for documentation as well
Nov 03 12:29:33 <lsmith>	right
Nov 03 12:29:56 <lsmith>	maybe we should however have a README for each component
Nov 03 12:30:10 <lsmith>	which then also contains a link to the tests and forthcoming docs
Nov 03 12:30:12 <drak>	+1
Nov 03 12:30:37 <lsmith>	and a short description
Nov 03 12:30:46 *	dbu has quit (Remote host closed the connection)
Nov 03 12:31:01 <fabpot>	let's wait for the docs first
Nov 03 12:31:05 <lsmith>	k
Nov 03 12:32:01 <beberlei>	hello
Nov 03 12:32:05 <beberlei>	back from confcall
Nov 03 12:32:06 <lsmith>	ah great
Nov 03 12:32:15 <lsmith>	so next topic then
Nov 03 12:32:24 <lsmith>	how to proceed with ORM support in Symfony 2.1: http://bit.ly/smsAkz
Nov 03 12:32:36 <lsmith>	basically couac proposed adding a propel bridge
Nov 03 12:32:59 <lsmith>	but it also started to sound a bit like we might just move all of the doctrine stuff out of the core repo
Nov 03 12:33:09 <couac>	well, following fabpot's last blog post, it's quite logic
Nov 03 12:33:22 <couac>	bridge is ok for ORM stuffs IMO
Nov 03 12:33:27 <jmikola|w>	couac: Symfony is VC, not M? :)
Nov 03 12:33:37 <couac>	something like that
Nov 03 12:34:25 <fabpot>	I'm +1 for keeping the Doctrine and Propel bridges in the main repo
Nov 03 12:34:32 <beberlei>	from my perspective having the bridges in core is good and the bundles outside the main repo
Nov 03 12:34:35 <fabpot>	I'm also +1 for moving the Doctrine bundles outside the main repo
Nov 03 12:34:49 <drak>	fabpot: me too, seem quite logical since these are so important to everyone's use
Nov 03 12:34:51 <beberlei>	question is if we should move the doctrine bundles to the doctrine organization aswell
Nov 03 12:34:59 <couac>	yes
Nov 03 12:35:00 <beberlei>	and namespace them under Doctrine\bundle
Nov 03 12:35:10 <fabpot>	beberlei: that would be wonderful
Nov 03 12:35:18 <jmikola|w>	beberlei: +1
Nov 03 12:35:21 <beberlei>	i do have committ access on all of them atm in the symfony namespace, but it stills strange to have the bundles there
Nov 03 12:35:47 <beberlei>	i am not sure at which points we break BC there, o rpeople dont work with this anyways since they get it from the DIC
Nov 03 12:36:02 <fabpot>	beberlei: 2.1 is fine
Nov 03 12:36:12 <jmikola|w>	would this lead to having specific distributions then? since that was first discussed at sf live, we've still only had symfony-standard available afaik
Nov 03 12:36:22 <lsmith>	beberlei: well it will break type hints and tests etc .. so its a BC break
Nov 03 12:36:26 <jmikola|w>	seems like a good opportunity to publish doctrine and propel distros
Nov 03 12:36:34 <couac>	+1 jmikola|w
Nov 03 12:36:36 <fabpot>	jmikola|w: we also have the hello world edition ;)
Nov 03 12:36:41 <jmikola|w>	ah yes
Nov 03 12:36:49 <lsmith>	there is also my tecktalk edition :)
Nov 03 12:37:00 <lsmith>	but yeah .. think we havent really pushed this
Nov 03 12:37:00 <rande>	and the sonata one ;)
Nov 03 12:37:01 <beberlei>	well i discussed with fabien also to have an xml and an yml version of the config as distributions, since people using xml are kind of screwed at the moment, so we should maybe start digging into having a generator for distributions
Nov 03 12:37:21 <jmikola|w>	beberlei: i think if the service names don't change, the BC break is minimal to the kernel and some folks' tests
Nov 03 12:37:53 <fabpot>	beberlei: the hello world edition is actually just a script that converts the standard edition
Nov 03 12:37:55 <lsmith>	jmikola|w: most sane people dont inject the DIC into their controllers :)
Nov 03 12:38:08 <fabpot>	I think the propel and doctrine editions can be done with the same kind of script
Nov 03 12:38:30 <beberlei>	with 2.1 its just a change in the composer.json file +the default config options in config.yml
Nov 03 12:38:40 <lsmith>	yeah
Nov 03 12:38:51 <beberlei>	and the acme demo bundle is persistence agnostic anyways nowadays
Nov 03 12:39:12 <fabpot>	as a side note, I'm not confident about marking 2.1 as the first LTS
Nov 03 12:39:13 <lsmith>	ok .. seems like stof will likely not make it .. is anyone sufficiently familiar with what stof did for "[SecurityBundle] Added a way to extend the providers section of the config: http://bit.ly/nvOqTC" ?
Nov 03 12:39:41 <fabpot>	so, everyone is fine with the Doctrine bundles moving out of the main Symfony repo?
Nov 03 12:39:51 <couac>	yes
Nov 03 12:39:53 <couac>	:p
Nov 03 12:39:54 <drak>	yes
Nov 03 12:39:54 <fabpot>	I have had time to have a look at this PR yet
Nov 03 12:39:58 <beberlei>	couac:  :)
Nov 03 12:40:00 <Stof>	hi
Nov 03 12:40:01 <fabpot>	I have NOT
Nov 03 12:40:25 <couac>	Stof: we are discussing your PR about security and providers
Nov 03 12:41:21 <jmikola|w>	Stof: I assume you reviewed this PR, yes? ;)
Nov 03 12:41:23 *	asm89 has quit (Quit: bye!)
Nov 03 12:42:13 <jmikola|w>	propel models are also called entities, yes?
Nov 03 12:42:19 <lsmith>	Stof: ?
Nov 03 12:42:25 <couac>	jmikola|w: well no
Nov 03 12:43:04 <rande>	(an after meeting link : http://www.google.fr/search?aq=f&gcx=c&sourceid=chrome&ie=UTF-8&q=do+a+barrel+roll )
Nov 03 12:43:19 <jmikola|w>	couac: ok, the comments about doctrine handling "entity" provider in that PR made me assume there was a conflict
Nov 03 12:43:41 <lsmith>	in general i think we shouldnt bother with BC in the security config
Nov 03 12:43:56 <lsmith>	ideally we shouldnt have BC breaks that lead to silent security issues
Nov 03 12:44:08 <lsmith>	but otherwise we shouldnt make things even more complicated by maintaining BC
Nov 03 12:44:16 <lsmith>	in the security layer
Nov 03 12:44:24 <lsmith>	which isnt marked stable yet anyway
Nov 03 12:44:31 <jmikola|w>	lsmith: to beberlei's point, the in_memory BC break is safe, in that at worst it will not let you authenticate (vs. letting people in)
Nov 03 12:45:11 <lsmith>	yeah ... all good as long as the bc breaks actually breaks something you notice :)
Nov 03 12:45:23 <jmikola|w>	and to Stof's point, being able to validate the security config (and provide intelligent error reporting) is a huge plus
Nov 03 12:45:24 <drak>	heh
Nov 03 12:45:46 <lsmith>	yes .. the lack thereof is what is killing users today
Nov 03 12:46:30 <Stof>	lsmith: even more: as the config is validated by the Configuration class, the BC break is a exception when loading the configuration if the user does not update the config file
Nov 03 12:46:46 <lsmith>	all the better
Nov 03 12:46:53 <Stof>	so the app will not work at all => no security issue
Nov 03 12:47:07 <lsmith>	so maybe a quick straw poll in regards to maintaing BC in this regard?
Nov 03 12:47:08 <jmikola|w>	Stof: if I understand the PR correctly, existing config doesn't have chain or in_memory keys, and it infers based on what is under those blocks? simple scalars are a chain, and user "objects" are in_memory?
Nov 03 12:47:22 <lsmith>	otherwise i guess we will have to wait on fabpot and johannes__ reviewing the changes
Nov 03 12:47:38 <Seldaek>	lsmith: I spent all day mucking around with the Security component, anything that helps I'll +1 :)
Nov 03 12:48:07 <beberlei>	well my fear is that "never change a running system" is important for a security component ;)
Nov 03 12:48:36 <lsmith>	beberlei: so you are opposed to a BC break?
Nov 03 12:48:59 <Seldaek>	beberlei: in my experience, many "running systems" are also misconfigured, insecure, and broken. Only nobody noticed yet.
Nov 03 12:49:55 <lsmith>	hmm ..
Nov 03 12:50:06 <lsmith>	not the busiest chatters today it seems
Nov 03 12:50:10 <Stof>	jmikola|w: an scalar-prototyped node named "providers" is the chain provider
Nov 03 12:50:19 <couac>	anyway, this security part is to close to doctrine : https://github.com/symfony/symfony/blob/master/src/Symfony/Bundle/SecurityBundle/DependencyInjection/SecurityExtension.php#L478
Nov 03 12:50:39 <couac>	we should be able to extend this part without a custom provider
Nov 03 12:50:42 <jmikola|w>	Stof: vs. an array-prototyped node for in-memory?
Nov 03 12:51:03 <Stof>	vs a prototyped node named "users" for in_memory
Nov 03 12:51:11 <beberlei>	couac: other bundles like oauth and such have the same problems of needing to extend the security configuratino
Nov 03 12:51:12 <Stof>	there is already a key for these nodes
Nov 03 12:51:33 <couac>	beberlei: I agree, it's not just against Doctrine :D
Nov 03 12:51:34 <Stof>	I suggest adding a level with a standard array node before the prototyped node
Nov 03 12:52:00 <Stof>	the issue being the prototyped node which requires some tricky stuff to allow the factory to use it and forbids validating cleanly the configuration of the provider
Nov 03 12:52:08 *	stodan (~daniel@unaffiliated/stodan) has joined #symfony-dev
Nov 03 12:52:37 <Stof>	beberlei: oauth needs to extend the firewalls: section of the security config, which is already possible in 2.0
Nov 03 12:53:37 <lsmith>	so then lets wrap it up with the "how to grow the reach of Symfony2 components?" topic
Nov 03 12:53:54 <Stof>	fabpot: can you give your mind about the need for BC here ?
Nov 03 12:54:09 *	stodan has quit (Remote host closed the connection)
Nov 03 12:54:16 <lsmith>	fabpot: do you have an ETA on component docs? also do you plan to launch it all at once .. or step by step? i know you prefer releasing stuff when its perfect .. but
Nov 03 12:54:18 <fabpot>	Stof: as lsmith said, the security component has been explicitly marked as NOT stable
Nov 03 12:54:36 <fabpot>	lsmith: I have not began yet, so we will see how it goes
Nov 03 12:54:39 <Stof>	if you really want to keep the BC in the config, the PR can be merged as is. If you allow breaking it, I will implement my cleaner proposal mentionned in the PR
Nov 03 12:54:47 <fabpot>	but I want to have something by the end of the end
Nov 03 12:55:07 <fabpot>	Stof: no need to keep BC but we need to clearly document how to upgrade
Nov 03 12:55:23 *	notjosh has quit (Remote host closed the connection)
Nov 03 12:55:27 <fabpot>	so, yes, let's keep this PR with no BC break and create a new one with the BC break
Nov 03 12:55:42 <beberlei>	can we make sure that everything blows into users faces and there are no silent problems?
Nov 03 12:56:42 *	mapi has quit (Ping timeout: 244 seconds)
Nov 03 12:56:55 <Stof>	beberlei: the Configuration class ensures that it blows into your face if your config is not updated
Nov 03 12:57:04 <lsmith>	fabpot: ok .. but in that case i think we should start adding some README's sooner than that
Nov 03 12:57:19 *	stodan (~daniel@unaffiliated/stodan) has joined #symfony-dev
Nov 03 12:58:01 *	tystr has quit (Quit: tystr)
Nov 03 12:58:02 <lsmith>	the README could basically be exactly what you put in the blog post after symfony day
Nov 03 12:58:11 *	tystr (~tystr@wsip-98-175-247-26.sd.sd.cox.net) has joined #symfony-dev
Nov 03 12:58:17 <fabpot>	there is no rush
Nov 03 12:58:29 <lsmith>	plus some more links to the tests, the issue tracker (with filter)
Nov 03 12:58:58 <lsmith>	fabpot: well i think there is
Nov 03 12:59:04 <lsmith>	not really a rush
Nov 03 12:59:07 <fabpot>	lsmith: why?
Nov 03 12:59:15 <fabpot>	2 months is not that far away
Nov 03 12:59:15 <lsmith>	but its not like we are rushing
Nov 03 12:59:29 <lsmith>	well we released in july
Nov 03 12:59:31 <beberlei>	whats the topic btw? i think i missed a switch :)
Nov 03 12:59:40 <lsmith>	beberlei: components ..
Nov 03 12:59:47 <lsmith>	growing their reach ..
Nov 03 13:00:20 <lsmith>	also adding some README's with some basic info doesnt seem like a rush
Nov 03 13:00:27 <lsmith>	i mean its stuff we will want either way imho
Nov 03 13:00:40 *	jstout (~jstout@wsip-98-175-247-26.sd.sd.cox.net) has joined #symfony-dev
Nov 03 13:01:18 <fabpot>	but basic infos won't' help people that much anywya
Nov 03 13:02:08 <lsmith>	i think it does .. for one they will know where to report bugs, they will know that there are actually tests .. and they can read the tests as documentation
Nov 03 13:02:39 <lsmith>	https://github.com/symfony/browserkit
Nov 03 13:02:45 <lsmith>	what does this component do?
Nov 03 13:02:59 <lsmith>	there is zero information in the repo
Nov 03 13:03:51 <lsmith>	https://github.com/symfony/CssSelector alteast references its inspiration
Nov 03 13:04:32 <drak>	yeah, even github as standard asks you to create a README for all repos... so probably you want to do this in all cases.
Nov 03 13:05:31 <lsmith>	ok anyway .. i will send PRs :)
Nov 03 13:05:43 <lsmith>	we are 5min over time .. so i guess the meeting is over ..