You must first sign up to be able to contribute.


IRC logs

Feb 17 11:00:13 <fabpot>	ok, so let's start
Feb 17 11:00:34 <Seldaek>	not many seem to be around :/
Feb 17 11:00:35 <fabpot>	first topic is about the Symfony sub-namespaces
Feb 17 11:01:01 <fabpot>	don't know why we need to talk about that as last time I did, everybody seem to be againts any change
Feb 17 11:01:01 *	na8flush ( has joined #symfony-dev
Feb 17 11:01:18 <Seldaek>	bschussek: avalanche123 iampersistent jmikola|w jmikola johanness kriswallsmith lala ping
Feb 17 11:01:25 <jmikola|w>	pong pong pong pong
Feb 17 11:01:28 <avalanche123>	Seldaek lala pong
Feb 17 11:01:30 <jmikola|w>	oh, meeting time :)
Feb 17 11:01:32 *	aways|bnc Bye all
Feb 17 11:01:42 *	kriswallsmith is here
Feb 17 11:01:50 <Seldaek>	fabpot: I believe the thing is that bschussek proposed something new
Feb 17 11:01:51 <lsmith>	fabpot: about to head out ..
Feb 17 11:01:59 <lsmith>	but yeah .. there was a new proposal on the list
Feb 17 11:02:14 <fabpot>	bschussek proposal is to move bundles under Framework
Feb 17 11:02:15 <Seldaek>
Feb 17 11:02:25 <fabpot>	and move up components under the main namespace
Feb 17 11:02:28 <Seldaek>	yes
Feb 17 11:02:33 <Seldaek>	you didn't answer afaik
Feb 17 11:02:42 <fabpot>	Seldaek: I missed that one
Feb 17 11:02:45 <Seldaek>	so that's the main question, is it a no go for you or not :)
Feb 17 11:02:56 <kriswallsmith>	i like the current layout
Feb 17 11:03:25 <fabpot>	but then, the components are not clearly stored under one place
Feb 17 11:03:27 *	johnwards_ ( has joined #symfony-dev
Feb 17 11:03:36 <fabpot>	I think the current way is good enough
Feb 17 11:03:38 <Seldaek>	sure, but if we move them to their own repo at some point anyway
Feb 17 11:03:47 <Seldaek>	then the subnamespace would make less sense
Feb 17 11:03:48 <jmikola|w>	Seldaek: with bernhard's proposal, would the best practice for other vendors be to have no Bundle/ in their bundle namespaces?
Feb 17 11:04:03 <Seldaek>	jmikola|w: no that has nothing to do with vendors I think
Feb 17 11:04:16 <fabpot>	the problem is that the "best practice" will not be followed by Symfony anyway
Feb 17 11:04:24 <Seldaek>	yes, that's irrelevant
Feb 17 11:04:43 <jmikola|w>	I don't mind Symfony having a component namespace... after all, those will become right? :)
Feb 17 11:04:43 <fabpot>	IIRC, we advocate Sensio\FooBundle
Feb 17 11:04:44 <kriswallsmith>	on the other hand, if i wanted to use a component in a non-symfony project, Symfony\Yaml would be nicer than Symfony\Component\Yaml
Feb 17 11:04:53 <bschussek>	kriswallsmith: +1
Feb 17 11:05:00 <Seldaek>	yeah that's what I meant kriswallsmith
Feb 17 11:05:05 <bschussek>	I think it makes sense, because the bundles are the "framework"
Feb 17 11:05:09 <Seldaek>	if they're in their own repo/package, then the extra namespace becomes annoying
Feb 17 11:05:13 <bschussek>	so Symfony\Framework is that, and Symfony\X is everything else
Feb 17 11:05:16 <fabpot>	as discussed on the CMF ML, we will have a Symfony\CMF
Feb 17 11:05:18 <jmikola|w>	bschussek: would we have Framework\FrameworkBundle? :)
Feb 17 11:05:39 <kriswallsmith>	CoreBundle?
Feb 17 11:05:42 <bschussek>	jmikola|w: for example. or CoreBundle, I don't mind
Feb 17 11:05:42 <fabpot>	so, there is no clear difference between a component, the framework (a bunch of bundle), and the CMF
Feb 17 11:05:49 <fabpot>	looks messy, no?
Feb 17 11:05:55 <Seldaek>	fabpot: not really
Feb 17 11:05:56 <bschussek>	I don't think so
Feb 17 11:06:02 <Seldaek>	the framework is a component of sorts
Feb 17 11:06:10 <fabpot>	Seldaek: not at all
Feb 17 11:06:11 <Seldaek>	you can use it on its own, it just has lots of dependencies
Feb 17 11:06:16 <fabpot>	the framework is definitely NOT a component
Feb 17 11:06:33 <fabpot>	the "few dependencies" is part of the component definition
Feb 17 11:06:42 <Seldaek>	yes of course it's special
Feb 17 11:06:53 <Seldaek>	but I don't see it as bad to have it under the same namespace
Feb 17 11:07:02 <Seldaek>	it's quite clear what Framework is..
Feb 17 11:07:04 <Seldaek>	same for CMF
Feb 17 11:07:15 <fabpot>	the problem is not the CMF or Framework namespaces, but all the other ones
Feb 17 11:07:16 *	johnwards has quit (Ping timeout: 240 seconds)
Feb 17 11:07:16 *	johnwards_ is now known as johnwards
Feb 17 11:07:52 <Seldaek>	well the notion of what a component is honestly is just as vague
Feb 17 11:07:59 <Seldaek>	component means something to us because it has been defined
Feb 17 11:08:00 <fabpot>	it's not
Feb 17 11:08:10 <Seldaek>	if we define that those things in Symfony, except Framework, are components
Feb 17 11:08:20 <Seldaek>	then it's the same.. it's just a matter of documenting it properly I think
Feb 17 11:08:36 <Seldaek>	in another framework, Component could be something totally not reusable and standalone
Feb 17 11:08:43 <fabpot>	let's put it another way: Why would you want to remove the Component\ sub-namespace?
Feb 17 11:08:44 <Seldaek>	it's not a universal meaning, that's what I mean
Feb 17 11:09:12 *	gordonslondon_ ( has joined #symfony-dev
Feb 17 11:09:13 *	gordonslondon has quit (Read error: Connection reset by peer)
Feb 17 11:09:13 *	gordonslondon_ is now known as gordonslondon
Feb 17 11:09:14 <Seldaek>	on the plus side it makes things shorter, and it has no real benefit imo
Feb 17 11:09:16 <bschussek>	fabpot: for clarity, mainly. I like the short namespaces of Doctrine
Feb 17 11:09:22 <bschussek>	but it's no must have
Feb 17 11:09:31 <jmikola|w>	Seldaek: i think other projects using namespaces are more single purpose - while Symfony\ here is lumping a lot of independent things together... perhaps one of the few things to compare to would be ZF2, but those are essentially all components afaik
Feb 17 11:09:40 *	weaverryan has quit (Ping timeout: 276 seconds)
Feb 17 11:09:43 <pgodel_work>	you can always use "use namespace;" to shorten things
Feb 17 11:10:00 <fabpot>	to be clear, I'm not opposed to the change. But we are now in a stabilization phase. So we only change things if there is a real advantage
Feb 17 11:10:20 <bschussek>	what about a voting then?
Feb 17 11:10:25 <Seldaek>	pgodel_work: well, you gotta write the long use statements.. :)
Feb 17 11:10:33 <kriswallsmith>	can someone recap why the CMF is going into Symfony\CMF?
Feb 17 11:10:36 <pgodel_work>	IDE autocompletion ;)
Feb 17 11:10:38 <fabpot>	bschussek: I want pros and cons before
Feb 17 11:10:51 <Seldaek>	kriswallsmith: please later, unless it's a pressing matter
Feb 17 11:11:01 <kriswallsmith>	it will inform this decision
Feb 17 11:11:02 *	weaverryan (~ryan@ has joined #symfony-dev
Feb 17 11:11:10 <fabpot>	Seldaek: it is important to make the right decision
Feb 17 11:11:22 <fabpot>	let's add another one: Symfony\Twig
Feb 17 11:11:26 <Seldaek>	well, they will never be in the same repo I guess, so I'd say it's less important
Feb 17 11:11:32 <fabpot>	that's something I'm thinking about
Feb 17 11:11:37 <jmikola|w>	if CMF, as a project is going into the top namespace, i see value in keeping sf2 components isolated from that
Feb 17 11:11:48 <Seldaek>	but the rationale behind the CMF is that it's endorsed by Symfony
Feb 17 11:11:50 <fabpot>	jmikola|w: +1
Feb 17 11:11:57 <pgodel_work>	jmikola|w: and there may be more things like that in the future
Feb 17 11:11:58 <Seldaek>	and it is a CMFramework
Feb 17 11:12:10 <Seldaek>	it's not really a product on its own
Feb 17 11:12:12 <jmikola|w>	pgodel_work: yes, i considered Symfony\Twig, too
Feb 17 11:12:15 <kriswallsmith>	why is CMF different than YAML?
Feb 17 11:12:16 <johanness>	fabpot, what about different release cycles and dependencies between components?
Feb 17 11:12:29 <fabpot>	johanness: What do you mean?
Feb 17 11:12:30 <johanness>	that wouldn't work so well if they are all in the same repo no?
Feb 17 11:12:35 <Seldaek>	kriswallsmith: it's not a component, it'll use many dependencies
Feb 17 11:12:48 <fabpot>	johanness: there are in the same namespace, but can be in different repo
Feb 17 11:12:48 <pgodel_work>	same namespace does not mean same repo
Feb 17 11:12:52 <kriswallsmith>	Seldaek: i see
Feb 17 11:12:55 <fabpot>	they*
Feb 17 11:13:08 <kriswallsmith>	+1 for no change
Feb 17 11:13:09 <fabpot>	2 minutes left
Feb 17 11:13:19 <pgodel_work>	+1 no change
Feb 17 11:13:22 <Stof>	+& for no change too
Feb 17 11:13:24 <fabpot>	+1 no change
Feb 17 11:13:27 <Seldaek>	well, I'll live either way, but I would have liked the shortened ns
Feb 17 11:13:30 <Nenuial>	+1 no change
Feb 17 11:13:33 <bschussek>	+1 change :)
Feb 17 11:13:37 <fabpot>	bschussek: ?!
Feb 17 11:13:41 <mvrhov>	+1 fo no change.
Feb 17 11:13:57 <bschussek>	I'm alright with no change, but as for the voting :P
Feb 17 11:13:59 <Seldaek>	bschussek: it's the liip office influence, you start having ideas that nobody agrees with
Feb 17 11:14:07 <Seldaek>	it's okaay
Feb 17 11:14:09 <jmikola|w>	in the interest of how close we are to stabilizing, +1 for no change (this seems more opinion than functional need)
Feb 17 11:14:10 <fabpot>	Seldaek: hehe
Feb 17 11:14:22 <jmikola|w>	Seldaek: Symfony\ViewBundle? :)
Feb 17 11:14:25 <fabpot>	Seldaek: by the way, I'm the one who started this thread
Feb 17 11:14:38 <fabpot>	jmikola|w: looks ugly o)
Feb 17 11:14:46 *	kriswallsmith gavels
Feb 17 11:14:48 <Seldaek>	well then next topic I guess :p
Feb 17 11:14:53 <fabpot>	yep
Feb 17 11:15:04 <fabpot>	what's missing for RC1?
Feb 17 11:15:17 <fabpot>	bschussek: my first main concern is the form/validation component
Feb 17 11:15:24 <fabpot>	2 things: intl and the binding process
Feb 17 11:15:42 <bschussek>	fabpot: intl is being worked on
Feb 17 11:15:52 <bschussek>	progress can be seen at
Feb 17 11:16:03 <fabpot>	bschussek: great, I will have a look then
Feb 17 11:16:06 <fabpot>	any ETA?
Feb 17 11:16:14 <igorw>	also igorw/symfony for the dateformatter
Feb 17 11:16:16 <kriswallsmith>	i have work to do in assetic and AsseticBundle
Feb 17 11:16:27 <fabpot>	locale branch?
Feb 17 11:16:34 <bschussek>	numberformatter, I think
Feb 17 11:16:36 <igorw>	numberformatter
Feb 17 11:16:40 <igorw>	and intldateformatter on mine
Feb 17 11:16:50 <bschussek>	\Locale and \NumberFormatter are already ported
Feb 17 11:16:59 <bschussek>	igorw is working on \IntlDateFormatter
Feb 17 11:17:11 <bschussek>	then there's \Collator missing, but I hope this'll be a quick one
Feb 17 11:17:12 <jmikola|w>	kriswallsmith: assetic won't depend on bulat's imagine stuff for initial release, correct? not sure how much overlap there was on spriting
Feb 17 11:17:16 <igorw>	bschussek: would be great if you could review what I have and tell me what else is needed
Feb 17 11:17:27 <kriswallsmith>	jmikola|w: correct
Feb 17 11:17:36 <kriswallsmith>	we may work together when it comes to image sprites
Feb 17 11:17:50 <fabpot>	let's finish intl before
Feb 17 11:17:53 <bschussek>	igorw: I'll do that tomorrow
Feb 17 11:18:10 <fabpot>	bschussek: so, as I understand, you are confident about it, right?
Feb 17 11:18:11 <bschussek>	fabpot: so if ecosta has some time, we might have a first intl candidate by the end of next week
Feb 17 11:18:26 <bschussek>	yes
Feb 17 11:18:36 <fabpot>	great
Feb 17 11:18:56 <bschussek>	as for the binding process, I'll change that, but I also want to take Bulat's, Jon's and Lukas' feedback into account
Feb 17 11:19:02 <bschussek>	more on that next week
Feb 17 11:19:06 <fabpot>	great
Feb 17 11:19:19 <fabpot>	anything special on assetic?
Feb 17 11:19:27 <fabpot>	kriswallsmith: what about the documentation for the Symfony book?
Feb 17 11:19:45 <kriswallsmith>	i'm tracking issues here
Feb 17 11:20:06 <kriswallsmith>	there are issues with how assets configured in templates are cached
Feb 17 11:20:23 <kriswallsmith>	i'll probably write a custom cache mechanism in assetic for that
Feb 17 11:20:25 <Seldaek>	I really hope I find time to play with assetic next week
Feb 17 11:20:31 <Seldaek>	I'm very interested in the topic
Feb 17 11:20:35 <fabpot>	Seldaek: same for me
Feb 17 11:20:48 *	johnkary (~johnkary@ has joined #symfony-dev
Feb 17 11:20:56 <fabpot>	kriswallsmith: Will you find some time to write a small chapter on assetic for the book?
Feb 17 11:20:58 <kriswallsmith>	i also need to write the loader that extracts assets from php templates
Feb 17 11:21:21 <igorw>	who is responsible for spriting stuff? one of the phpBB guys was doing something with that lately, he might be able to help
Feb 17 11:21:22 <kriswallsmith>	i need to solve the caching issue before i document it
Feb 17 11:21:31 <fabpot>	kriswallsmith: ok
Feb 17 11:21:34 *	krymen (~krymen@ has joined #symfony-dev
Feb 17 11:21:36 <kriswallsmith>	once that's in place i'll be confident it's stable enough
Feb 17 11:21:55 <pgodel_work>	talking about phpBB, is the bundle dependency going in RC1 ?
Feb 17 11:21:56 <fabpot>	next thing to finish before RC1 is the conversion of the DIC extension configuration
Feb 17 11:22:12 <fabpot>	pgodel_work: hopefully, but that will be though I think
Feb 17 11:22:14 <kriswallsmith>	anyone want to do that for AsseticBundle?
Feb 17 11:22:16 <Stof>	I think 2 docs are needed: the doc about Symfony integration and the doc of the standalone library
Feb 17 11:22:21 <weaverryan>	I'm working on some tweaks to the "Definition" class right now per the extensions
Feb 17 11:22:46 <fabpot>	TwigBundle should also be migrated; this one should be easy. Anyone?
Feb 17 11:22:50 <Stof>	kriswallsmith: I can convert AsseticBundle
Feb 17 11:22:56 <kriswallsmith>	Stof: thanks
Feb 17 11:22:59 <weaverryan>	it's still somewhat difficult to use, because we're so "friendly" to different formats - something can be null, true, an array etc
Feb 17 11:23:16 *	na8flush ( has left #symfony-dev
Feb 17 11:23:27 <kriswallsmith>	please send assetic-related pull requests through kriswallsmith/symfony
Feb 17 11:23:41 <Stof>	ok
Feb 17 11:24:00 <jmikola|w>	fabpot: what remains in Twig Bundle?
Feb 17 11:24:04 <jmikola|w>	to the config builder?
Feb 17 11:24:18 *	jonwage ( has joined #symfony-dev
Feb 17 11:24:28 <jmikola|w>	I can do that today if so
Feb 17 11:24:59 <fabpot>	jmikola|w: that would be great
Feb 17 11:25:51 <weaverryan>	I'm still on the ODM - it's mostly finished locally - will love some feedback soon from the guys using it in prod :)
Feb 17 11:25:57 <jmikola|w>	weaverryan: and please ping me when you submit a pull for Def changes, i'd be interested in tracking those
Feb 17 11:26:16 <jmikola|w>	weaverryan: can accommodate you on ODM feedback, too :)
Feb 17 11:26:27 <weaverryan>	will-do thanks
Feb 17 11:27:22 <Stof>	DoctrineBundle needs to be converted too
Feb 17 11:27:26 <Seldaek>	fabpot: next?
Feb 17 11:27:57 <Stof>	I can work on it this weekend
Feb 17 11:28:14 <weaverryan>	Stof: that's very-much related to the mongodb one - so let's coordinate somewhat
Feb 17 11:28:18 <fabpot>	next topic: bootstrap.php in dev env
Feb 17 11:28:19 <fabpot>
Feb 17 11:28:22 <fabpot>
Feb 17 11:28:24 <weaverryan>	would love to have your thoughts on it anyways
Feb 17 11:29:07 <Seldaek>	fabpot: yes, so we talked a bit last time but you weren't there
Feb 17 11:29:25 <jmikola|w>	fabpot: how is bootstrap currently generated?
Feb 17 11:29:29 <kriswallsmith>	do you mean in debug?
Feb 17 11:29:30 <Seldaek>	basically it's about not using the bootstrap.php file in dev, because it makes it quite annoying to debug
Feb 17 11:29:39 <fabpot>	it's not generated
Feb 17 11:29:43 <fabpot>	it's included in the framework
Feb 17 11:29:44 *	kertz_ (~kertz@ has joined #symfony-dev
Feb 17 11:29:53 <jmikola|w>	oh, it's not the result of addCompiledClass() ?
Feb 17 11:29:58 <Stof>	jmikola|w: no
Feb 17 11:30:03 <avalanche123>	+1 on not using bootstrap.php it in debug=true
Feb 17 11:30:07 <Seldaek>	jmikola|w: nah that's another bootstrap :)
Feb 17 11:30:17 <Seldaek>	it's the bootstrapped bootstrap
Feb 17 11:30:19 <johnwards>	As a n00b to deving with Symfony2 it is a pain for getting my head around the codebase
Feb 17 11:30:27 <Stof>	addCompiledClass create a classXXXX.php file in your cache
Feb 17 11:30:28 <johnwards>	with bootstrap in dev
Feb 17 11:30:45 <Stof>	johnwards: even for non-noob :)
Feb 17 11:30:47 <jmikola|w>	Stof: oh, with the special loader?
Feb 17 11:31:02 <Seldaek>	so.. if nobody has any argument against, we agree on removing bootstrap from the sandbox?
Feb 17 11:31:08 <Stof>	jmikola|w: yes, this file is generated by ClassCollectionLoader
Feb 17 11:31:10 <fabpot>	I want all the env to work the same way as much as possible
Feb 17 11:31:13 <fabpot>	so, I'm )1
Feb 17 11:31:17 <fabpot>	-1
Feb 17 11:31:26 <Seldaek>	but what about generating it on the fly vs having it compiled?
Feb 17 11:31:29 <fabpot>	and we can probably document how to de-activate it
Feb 17 11:31:31 <Seldaek>	because then, envs could be the same
Feb 17 11:31:40 <johnwards>	fabpot has a big point here. that is a big pain in sf1
Feb 17 11:31:40 <fabpot>	Seldaek: not possible
Feb 17 11:31:51 <Seldaek>	fabpot: yeah not completely
Feb 17 11:32:00 <fabpot>	the bootstrap file contains things that are needed very early
Feb 17 11:32:04 <fabpot>	so, it cannot be generated
Feb 17 11:32:10 <jmikola|w>	chicken and egg problem? :)
Feb 17 11:32:13 <Seldaek>	well, if you load the autoloader
Feb 17 11:32:16 <Seldaek>	I guess it can?
Feb 17 11:32:22 *	rooster has quit (Remote host closed the connection)
Feb 17 11:32:25 <Seldaek>	that's how it was before no?
Feb 17 11:32:35 <jmikola|w>	fabpot: so when these core classes change (if at all), you have to update the code in two places?
Feb 17 11:32:42 *	kertz has quit (Ping timeout: 260 seconds)
Feb 17 11:32:43 *	kertz_ is now known as kertz
Feb 17 11:32:57 <Seldaek>	jmikola|w: there is a script to generate it
Feb 17 11:33:01 <Seldaek>	it's just not done on the fly
Feb 17 11:33:07 <fabpot>	jmikola|w: there is a script that need to be called to regenerate them
Feb 17 11:33:27 <Seldaek>	so ..  -1?
Feb 17 11:33:29 <Seldaek>	+1?
Feb 17 11:33:30 <mvrhov>	you can live just fine without bootstra.php. I was until lsmith mentioned it last week that he'd like to exclude it from debug
Feb 17 11:33:32 <jmikola|w>	and having bootstrap.php just require the things it currently includes inline would defeat the optimization?  it would avoid autoloading at least
Feb 17 11:33:49 <Stof>	Seldaek: no. The only change was adding the Autoloader to the bootstrap file. It was not generated on the fly before
Feb 17 11:34:20 <avalanche123>	is bootstrap.php even necessary?
Feb 17 11:34:28 <fabpot>	avalanche123: yes, performance
Feb 17 11:34:34 <avalanche123>	were there any benchmarks?
Feb 17 11:34:41 <avalanche123>	I assume with performance you'd use APC
Feb 17 11:34:43 <johnwards>	I'm not voting, but I think having the envs the same is very important. Then having it well documented on how to disable it for doing debug
Feb 17 11:34:43 <fabpot>	avalanche123: yes, plenty
Feb 17 11:34:48 <fabpot>	avalanche123: even with APC
Feb 17 11:34:52 <avalanche123>	fabpot, I see
Feb 17 11:35:07 <fabpot>	for a simple hello world, the difference can be up to 30%
Feb 17 11:35:09 <fabpot>	with APC
Feb 17 11:35:24 <avalanche123>	fabpot, gotcha, I understand
Feb 17 11:35:35 <Seldaek>	well then let's move on to next topic, those that want can still disable it. ack?
Feb 17 11:35:47 <fabpot>	yes, I will close the pull request then
Feb 17 11:35:57 <avalanche123>	agree, that doesn't seem like a bc breaking change anyway
Feb 17 11:36:01 <fabpot>	and perhaps write a some tuto on how to disable it
Feb 17 11:36:07 <bschussek>	short comment
Feb 17 11:36:19 <bschussek>	your statement about that 30% in hello world, is that relevant?
Feb 17 11:36:26 <fabpot>	bschussek: no
Feb 17 11:36:33 <avalanche123>	bschussek, that's the game we need to play
Feb 17 11:36:40 <fabpot>	except for all the blog posts that try to benchmark frameworks
Feb 17 11:36:46 <avalanche123>	yup
Feb 17 11:36:48 <fabpot>	and I don't want to suffer like we did with symfony1
Feb 17 11:36:51 <bschussek>	yes sure, but we're talking about dev env right?
Feb 17 11:37:07 <fabpot>	bschussek: all the envs should work the same
Feb 17 11:37:17 <fabpot>	that's one of the big pbe in symfony1
Feb 17 11:37:19 <bschussek>	ok
Feb 17 11:37:23 <fabpot>	things work in dev and not in prod
Feb 17 11:37:52 <avalanche123>	next?
Feb 17 11:38:09 <fabpot>	yes
Feb 17 11:38:19 <fabpot>	cache warming
Feb 17 11:38:34 *	ce_afk is now known as cescalante
Feb 17 11:38:39 <fabpot>	I'm aware that the current way the cache warming works is not ideal
Feb 17 11:38:46 <fabpot>	so, I will work on it next week
Feb 17 11:38:52 <fabpot>	I don't see a need to talk about it now
Feb 17 11:39:06 <Seldaek>	nope, there's
Feb 17 11:39:07 <avalanche123>	cool
Feb 17 11:39:18 <Seldaek>	just needs an answer:)
Feb 17 11:39:32 <kriswallsmith>	fabpot: we should discuss before I write the Assetic cache stuff
Feb 17 11:39:40 <fabpot>	kriswallsmith: ok
Feb 17 11:39:50 *	unknownbliss has quit (Ping timeout: 240 seconds)
Feb 17 11:39:51 *	igorkliks ( has joined #symfony-dev
Feb 17 11:40:00 <fabpot>	Seldaek: I work as much as I can but everyday is only 24 hours ;)
Feb 17 11:40:23 <Seldaek>	fabpot: sure no problem, just pointing it out in case it got lost
Feb 17 11:40:37 <Seldaek>	so, johanness are you there?
Feb 17 11:40:42 <fabpot>	Seldaek: nothing is lost if it's on github
Feb 17 11:41:05 <fabpot>	next topic is eager Response creation
Feb 17 11:41:08 <Seldaek>
Feb 17 11:41:16 *	tecbot has quit ()
Feb 17 11:41:24 <Seldaek>	you were already -1 on the ml though iirc
Feb 17 11:41:31 <fabpot>	my answer is very clear: if we change that, it's not Symfony2 anymore, so -1
Feb 17 11:41:45 <Seldaek>	so it's not happening so skip? :)
Feb 17 11:41:53 <kriswallsmith>	sounds like a veto :)
Feb 17 11:41:57 <Seldaek>	or someone wants to try and convince fabpot ? :p
Feb 17 11:41:58 <avalanche123>	I agree with fabpot
Feb 17 11:42:02 <avalanche123>	+1 on not doing that
Feb 17 11:42:02 <weaverryan>	+1 to move on
Feb 17 11:42:30 <fabpot>	route placeholders vs. GET parameters
Feb 17 11:42:30 <johanness>	just as a note, i'm also not really convinced after doing a sample implementation
Feb 17 11:42:43 <Seldaek>
Feb 17 11:42:47 <fabpot>	you will hate me, but I'm -1 also
Feb 17 11:42:51 <Seldaek>	really
Feb 17 11:42:55 <bschussek>	could you explain?
Feb 17 11:42:57 <Seldaek>	I think this one actually makes sense
Feb 17 11:43:05 <Seldaek>	for flexibility's sake
Feb 17 11:43:21 <fabpot>	if you want that, that's possible by registering a listener
Feb 17 11:43:38 <avalanche123>	you could still get the parameters from Request::$attributes, no?
Feb 17 11:43:42 <Seldaek>	yeah but we know we can do anything we want in our fork.. that's not the point :)
Feb 17 11:43:45 <fabpot>	I don't want that as parameters coming from the request must be isolated: POST, GET, PATH INFO, ...
Feb 17 11:44:15 <Seldaek>	avalanche123: the problem is just that your controller has to know where it comes from
Feb 17 11:44:19 *	ckwalsh (~ckwalsh@phpbb/developer/ckwalsh) has joined #symfony-dev
Feb 17 11:44:28 <avalanche123>	Seldaek, make action that doesn't take any parameters
Feb 17 11:44:32 <avalanche123>	and use Reqeust::get()
Feb 17 11:44:34 <avalanche123>	:)
Feb 17 11:44:35 <Seldaek>	fabpot: routing params are kind of get params in hiding though, prettified GET params
Feb 17 11:44:36 <jmikola|w>	Seldaek: but a listener could move them to attributes, no?
Feb 17 11:45:09 <bschussek>	jmikola|w: I think Seldaek is talking about a potential trap for other users
Feb 17 11:45:20 <bschussek>	you think you can easily change the routing, but you can't
Feb 17 11:45:20 <fabpot>	Seldaek: and what do you do when you have /foo/:id and the URL is /foo/12?id=foobar
Feb 17 11:45:34 <Seldaek>	fabpot: route wins
Feb 17 11:45:39 <Seldaek>	otherwise it's security issue
Feb 17 11:45:45 <Seldaek>	because the route has the requirements
Feb 17 11:45:50 <Seldaek>	query params don't
Feb 17 11:46:14 <jmikola|w>	aren't those requirements a contract for the controller, though? (assuming your controller is only accessed through a given route)
Feb 17 11:46:17 <Seldaek>	I'm not saying we have to advertise this as best practice, but I think it's nice if it's possible natively
Feb 17 11:46:21 *	gordonslondon has quit (Quit: gordonslondon)
Feb 17 11:46:42 <avalanche123>	fabpot maybe when we implement the full route template spec, that would be possible?
Feb 17 11:46:54 <avalanche123>	as then you could specify requirements on GET parameters as well
Feb 17 11:47:00 <fabpot>	avalanche123: I'm not sure how this is related
Feb 17 11:47:28 <avalanche123>	well then get parameters can be validate and I don't see harm in injecting them automatically
Feb 17 11:47:35 *	rande has quit (Quit: Leaving.)
Feb 17 11:47:44 <avalanche123>	but since they are not validate now, it might lead to problems
Feb 17 11:47:45 *	kertz has quit (Ping timeout: 246 seconds)
Feb 17 11:47:48 <kriswallsmith>	avalanche123: does the spec support that?
Feb 17 11:47:49 <avalanche123>	*validated
Feb 17 11:47:58 <fabpot>	avalanche123: ok, let's discuss that issue when we have support for the template spec then
Feb 17 11:48:02 <Seldaek>	avalanche123: by default params match .+?, so it's not like we prevent injection of anything
Feb 17 11:48:04 *	rande ( has joined #symfony-dev
Feb 17 11:48:04 <avalanche123>	kriswallsmith spec let's you define get paramters for a route
Feb 17 11:48:15 <avalanche123>	and routing lets you define validation (requirements)
Feb 17 11:48:17 <avalanche123>	kriswallsmith ^
Feb 17 11:48:33 *	rande has quit (Client Quit)
Feb 17 11:48:42 <avalanche123>	Seldaek, but you could with attributes, not with get parameters
Feb 17 11:48:44 <kriswallsmith>	avalanche123: if it's in the spec, that seems like the way to go
Feb 17 11:48:55 <bschussek>	so when we'd have this, we could inject GET parameters into the actions right?
Feb 17 11:49:02 <fabpot>	anyway, this is something we might be able to add for a 2.1, there is no pressure to have it in 2.0 as BC will be kept
Feb 17 11:49:10 <avalanche123>	fabpot +1
Feb 17 11:49:21 <kriswallsmith>	I would love to be able to a ?page={page} to my routes
Feb 17 11:49:29 <kriswallsmith>	*add
Feb 17 11:49:36 <Seldaek>	bschussek: we could already imo, if we consider that /{id} is just /?id=foo beautified (which it is), {id} is a query parameter imo
Feb 17 11:49:42 <avalanche123>	kriswallsmith yeah, that's what I mean
Feb 17 11:49:43 <fabpot>	as of today, we need to concentrate on things that breaks BC
Feb 17 11:49:50 <bschussek>	ok
Feb 17 11:49:51 <Seldaek>	so we could treat them similarly, and allow injecting any of them in the action
Feb 17 11:49:54 <avalanche123>	so -1
Feb 17 11:50:09 <bschussek>	Seldaek: what about implementing that? we can still decide whether and when to merge it
Feb 17 11:50:13 <kriswallsmith>	+1 for 2.1
Feb 17 11:50:33 <Seldaek>	bschussek: if fabpot is somewhat open to it, sure
Feb 17 11:50:56 <Seldaek>	I don't see the reason not to allow GET params to be injected in actions really
Feb 17 11:51:01 <fabpot>	Seldaek: I'm somewhat open to it, but not for 2.0
Feb 17 11:51:18 <kriswallsmith>	what's next?
Feb 17 11:51:29 <fabpot>	we're done
Feb 17 11:51:42 <Seldaek>	well, there's 2 left
Feb 17 11:51:48 <fabpot>	Seldaek: but no vote on them
Feb 17 11:51:58 <fabpot>	generate human readable docs out of bundle Configuration class
Feb 17 11:52:00 <fabpot>	is the next one
Feb 17 11:52:04 <kriswallsmith>	I'm going to send a pull req for subtree-merging Zend\Log
Feb 17 11:52:06 <fabpot>	but there is nothing to discuss
Feb 17 11:52:17 <Seldaek>	yes I don't think so either
Feb 17 11:52:21 <bschussek>	maybe there's someone here wanting to implement it? :)
Feb 17 11:52:25 <weaverryan>	I'm hoping to get to this - but actually getting the merging done in all extensions is more important
Feb 17 11:52:31 <Seldaek>	fabpot: and what about that
Feb 17 11:53:05 <kriswallsmith>	is it possible to generate an xsd from a config definition?
Feb 17 11:53:11 <Seldaek>	fabpot: is that the "one more thing"? is that why you don't answer? !! :p
Feb 17 11:53:17 <fabpot>	lol
Feb 17 11:53:18 <Seldaek>	damn secrets
Feb 17 11:53:19 <kriswallsmith>	theoretically, at least?
Feb 17 11:53:21 <jmikola|w>	kriswallsmith: perhaps for simple things
Feb 17 11:53:29 <jmikola|w>	even with doc generation, the issue is closures :)
Feb 17 11:53:48 <bschussek>	I'd like to throw in a random topic then
Feb 17 11:53:49 <johanness>	kriswallsmith, theoretically it's possible
Feb 17 11:53:54 <bschussek>	bug tracking
Feb 17 11:53:54 <fabpot>	As these helpers use intl, and as we don't have the replacement yet, I don't see how we will be able to include them in 2.0
Feb 17 11:54:07 <kriswallsmith>	it would be nice, to avoid duplication
Feb 17 11:54:08 <fabpot>	bschussek: I'm working on installing Jira for 2.0
Feb 17 11:54:15 <bschussek>	fabpot: awesome
Feb 17 11:54:20 <fabpot>	should be available for the Symfony Live conf
Feb 17 11:54:26 <jmikola|w>	for hackday?
Feb 17 11:54:28 <bschussek>	cool
Feb 17 11:54:31 <Seldaek>	I guess it's not worse than trac :(
Feb 17 11:54:43 <fabpot>	Seldaek: any other viable option?
Feb 17 11:54:45 <bschussek>	Seldaek: why? you've quite some experience with it right?
Feb 17 11:54:56 <Seldaek>	fabpot: no I guess not, they all suck to some extent
Feb 17 11:55:06 <fabpot>	Seldaek: correct
Feb 17 11:55:06 <Seldaek>	but yeah I've gotten quite experienced at handling the 39302 options of jira
Feb 17 11:55:09 <Seldaek>	if you need help
Feb 17 11:55:09 <jmikola|w>	from my experience with jira, it just takes some initial time to define workflows and such
Feb 17 11:55:13 <fabpot>	the concept of a bug tracker sucks
Feb 17 11:55:32 <bschussek>	I'm quite satisfied with pivotal tracker, but that might be too small for our purpose
Feb 17 11:55:33 <johnwards>	Githup issue tracker not suitable (i'm interested in why not)
Feb 17 11:55:38 <kriswallsmith>	we're using target process at OpenSky
Feb 17 11:55:39 <fabpot>	Seldaek: I will probably ask some help then, thanks
Feb 17 11:55:49 <pgodel_work>	fabpot: someone was asking if ESI was supported in the symfony http cache
Feb 17 11:55:59 <fabpot>	pgodel_work: of course it is
Feb 17 11:56:09 <jmikola|w>	kriswallsmith: please no target process :)
Feb 17 11:56:14 <pgodel_work>	that's what I thought, he was having some troubles
Feb 17 11:56:19 <kriswallsmith>	lol
Feb 17 11:56:20 <Seldaek>	fabpot: sure, once configured honestly it's usable. But the problem is most people use it with defaults and there is just too much craziness
Feb 17 11:56:51 <fabpot>	Seldaek: how do you find the configuration of the Doctrine Jira instance?
Feb 17 11:57:04 <Seldaek>	fabpot: it's quite an outdated version
Feb 17 11:57:11 <fabpot>	hehe
Feb 17 11:57:12 <Seldaek>	new one is slightly nicer
Feb 17 11:57:21 <bschussek>	what about GitHubs issue tracking? any experience with that?
Feb 17 11:57:32 <jmikola|w>	pgodel_work: that was jseverson from (ornicar could probably chime in on that, too)
Feb 17 11:57:35 *	notjosh has quit (Quit: notjosh)
Feb 17 11:57:43 <Seldaek>	fabpot: anyway just ping me when you have it running and we can talk
Feb 17 11:57:46 <pgodel_work>	jmikola|w: yup
Feb 17 11:57:47 <jmikola|w>	bschussek: i think github's is very lightweight
Feb 17 11:58:01 <bschussek>	jmikola|w: in a sense of too little features?
Feb 17 11:58:04 <jmikola|w>	probably not suitable for such a large project, vs other packages that support github integration
Feb 17 11:58:05 <Seldaek>	bschussek: github is really not scaling too well for such a big project
Feb 17 11:58:12 <bschussek>	ok
Feb 17 11:58:27 <jmikola|w>	i think jira with fisheye plugin or something could interpret commit id's pointed at github
Feb 17 11:58:42 <igorw>	there's also lighthouse
Feb 17 11:58:42 *	dustinwhittle ( has joined #symfony-dev
Feb 17 11:59:00 <Seldaek>	jmikola|w: eww fisheye that's going too far for me:p
Feb 17 11:59:18 <kriswallsmith>	igorw: a Portland company :)
Feb 17 11:59:18 <pgodel_work>	Seldaek: I know doctrine uses it (I think)
Feb 17 11:59:36 <Seldaek>	pgodel_work: well, it's just the slowest code browser in the universe, but besides that I'm sure it's great:p
Feb 17 11:59:44 <pgodel_work>	lol
Feb 17 12:01:22 <naderman>	pgodel_work: working on it as we speak ;-) (dependency stuff)
Feb 17 12:01:33 *	inspiran has quit (Ping timeout: 250 seconds)
Feb 17 12:01:45 *	bschussek ( has left #symfony-dev
Feb 17 12:01:46 <fabpot>	naderman: Perhaps you can say a bit more about the current status? and what still need to be done?
Feb 17 12:02:09 <avalanche123>	naderman, are you working with everzet?
Feb 17 12:02:16 <naderman>	well I have the rule generation working, I'm on the solving part now, I'll push something later tonight or tomorrow
Feb 17 12:02:37 *	ornicar (~ornicar@ has joined #symfony-dev
Feb 17 12:02:43 <fabpot>	naderman: great! Are you still confident about having something for Symfony Live?
Feb 17 12:02:45 <naderman>	which should be able to calculate the dependencies, what we then need is actual implementations of repositories/packages
Feb 17 12:02:49 <naderman>	fabpot: yes
Feb 17 12:02:57 <fabpot>	cool
Feb 17 12:03:10 <fabpot>	naderman: sorry about the pressure
Feb 17 12:03:20 <naderman>	no that's alright
Feb 17 12:03:24 <naderman>	I would have wanted to work more on it
Feb 17 12:03:30 <Seldaek>	naderman: if I can help with that let me know, instead of doing logging stuff that nobody wants you know:P though maybe you need logging in the depackager ;)
Feb 17 12:03:33 <naderman>	but the last few days after I got back were a bit crazy
Feb 17 12:04:07 <naderman>	heh, I'm sure it'll require plenty of work/help once there is a foundation ;-)
Feb 17 12:04:16 <pgodel_work>	yup
Feb 17 12:04:23 <Seldaek>	aye, don't be shy to share it though
Feb 17 12:04:31 <naderman>	not at all
Feb 17 12:05:13 <Seldaek>	well I don't see no repo! :)
Feb 17 12:05:21 <fabpot>	Seldaek: there is a lot of ground work to do before being able to share -- naderman is porting an existing library (not aPython one this time, but a C one)
Feb 17 12:05:24 *	webPragmatist has quit (Quit: Leaving.)
Feb 17 12:05:49 <Seldaek>	fabpot: yeah I heard, but anyway I'm just very tired and being annoying.. guess I'll head home
Feb 17 12:05:50 <fabpot>	and so, it does not make sense to share things before having ported lots of code
Feb 17 12:06:12 <fabpot>	Seldaek: hmmm, I really need to work on Jira to get you some work then
Feb 17 12:06:32 <naderman>	heh jira is a lot of fun to set up ...
Feb 17 12:07:08 <naderman>	well if you want to adjust the workflow at least
Feb 17 12:07:17 <pgodel_work>	you must have a very special meaning of "fun" :P