<ac:macro ac:
<h2>Information</h2>
<ul>
<li>Date: 07 December 2011, 18:00-19:00 UTC</li>
<li><ac:link><ri:page ri:<ac:link-body>Agenda</ac:link-body></ac:link></li>
<li>Moderator: Matthew Weier O'Phinney (nickname weierophinney)</li>
<li>Next meeting: TBD – supposed to be 21 December 2011, but may be pushed to 4 January 2012</li>
</ul>
<h2>Summary</h2>
<h3>Application Environment Variable In Config Files</h3>
<p>In mailing list and IRC discussions, several contributors have indicated they thing usage of an <code>APPLICATION_ENV</code> constant is not necessary, and, by extension, environment-specific configuration file sections.</p>
<p>The proposed idea is instead to use configuration globbing, specifying a "global" configuration and a "local" one:</p>
<ac:macro ac:<ac:plain-text-body><![CDATA[
config/
autoload/
application.global.php
application.local.php
contact.global.php
contact.local.php
guestbook.global.php
guestbook.local.php
]]></ac:plain-text-body></ac:macro>
<p>In the index.php, when specifying a glob pattern for the Config listener, you would then use:</p>
<ac:macro ac:<ac:plain-text-body><![CDATA[
"config/autoload/*.
.php"
]]></ac:plain-text-body></ac:macro>
<p>Typically, you will keep your "local" config files outside of version control (as they could contain credentials or other information you may need to keep secure). "local" would then be "local" to whereever the application is installed.</p>
<p>Matthew (yes, I refer to myself in the 3rd person) suggested that this could be expanded to utilize environment-specific configurations as well:</p>
<ac:macro ac:<ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
if (!($env = getenv('APPLICATION_ENV'))) {
$env = 'local';
}
$glob = glob(_DIR_ . "/config/autoload/*.
.php", GLOB_BRACE);
]]></ac:plain-text-body></ac:macro>
<p>The final outcome of discussion was:</p>
<ul>
<li>No more environment sections in configuration files.</li>
<li>Standardize on "global" and "local" files, with the former under version control and the latter not.</li>
<li>Standardize on shipping "local.<format>.dist" files as templates for local configuration. (Using the .dist extension breaks syntax highlighting, but this is by design; the idea is that developers would need to copy these to a name without the .dist extension to use them.)</li>
<li>Have a commented block in the generated index.php file indicating how to introduce environment-specific configuration files for globbing.</li>
<li>Provide a .gitignore in the ZendSkeletonApp that ignores non-.dist local configs.</li>
</ul>
<p><strong>tl;dr:</strong> Environment "sections" in config files are going away, to be replaced by individual config files per-environment. Additionally, the notion of "production" vs. "development" goes away, replaced by "global" settings and "local" settings.</p>
<h3>Deprecation of Mandatory/Recommended PHP_CONSTANTS in Config Files</h3>
<p>In ZF1, we have a history of using constants in our configuration files. This started with the INI format, as <code>parse_ini_*()</code> automatically replace these with the values.</p>
<p>The problems we have are:</p>
<ul>
<li>They are expensive to parse for and replace in other formats.</li>
<li>They make expectations about use. Constants must be defined prior to loading configuration, which also means you must know what constants the configuration is looking for.</li>
<li>In most cases, constants are being used to define paths for resources such as logging, caching, etc.</li>
</ul>
<p>The proposed solution is three-fold:</p>
<ul>
<li>Recommend <em>against</em> using constants in configuration files.</li>
<li>If constants <em>must</em> be used, have opt-in pre/post-parsers (TBD) that would do constant value replacements.</li>
<li>In the case of path configuration, the solution is to have the invoking script <code>chdir()</code> to the application root. Configuration would then either define absolute paths, or paths relative to the application root.</li>
</ul>
<p>To demonstrate the latter, consider the following structure:</p>
<ac:macro ac:<ac:plain-text-body><![CDATA[
my_application/
config/
module.config.php
autoload/
application.global.php
application.local.php
contact.global.php
contact.local.php
data/
cache/
session/
module/
public/
index.php
]]></ac:plain-text-body></ac:macro>
<p>Configuration could then use relative paths:</p>
<ac:macro ac:<ac:default-parameter>php</ac:default-parameter><ac:plain-text-body><![CDATA[
return array(
'cache' => array(
'path' => 'data/cache/',
),
'session' => array(
'save_path' => 'data/session/',
),
);
]]></ac:plain-text-body></ac:macro>
<p>One counter-example provided was modules seeding their own view script directories, as this requires some knowledge of where the module lives in the filesystem. However, Evan Coury and Ben Scholzen both provided examples of how that task could be accomplished using the module's <code>Module.php</code> classfile, and Artur Bodera also indicated that those might be cases for using the pre/post parser for constant value injection.</p>
<p>Artur volunteered to write the configuration pre/post parser for constant value injection.</p>
<p><strong>tl;dr:</strong> Don't use constants in configuration files if possible, and specify paths relative to the application's root directory.</p>
<h3>Endorsement of Application Path</h3>
<p>This basically followed on from the previous topics. Again, the idea is to formalize using the application's root directory as the basis for relative paths. Scripts would <code>chdir()</code> into that directory initially, ensuring that file operations (fopen, file_get_contents, parse_ini_file, glob, etc.) occur relative to that directory.</p>
<p>There were no further arguments and no further discussions at this point; all were in agreement on this approach.</p>
<h3>Pull Request Queue Management</h3>
<p>Per the meeting agenda, the following was proposed:</p>
<blockquote><p>Our workflow is simple; whenever someone who's allowed to push the pull request reviews it, he either merges it, or comments & closes it. If the contributor then updates his pull request the pull requester can just reopen it. That way the queue of open pull requests always resembles the list of pull requests that can potentially be merged.</p></blockquote>
<p>Developers who open a pull request have the option to re-open a pull request on GitHub (as do admins and committers). As such, if a PR is not quite ready to merge, a committer will comment on why, and close the request. The contributor can then perform the work necessary to ready the code for merge, and re-open the request when ready.</p>
<p>Consensus was immediate and enthusiastic. Matthew indicated he will update the <code>README-DEV.txt</code> and <code>README-GIT.txt</code> files, and try and find an appropriate place to call out this process on the ZF2 subsite.</p>
<h3>Schedule Beta 2 Release</h3>
<p>We discussed readiness of the various components slated for the beta2 release.</p>
<ul>
<li>Mail is ready except for documentation. Matthew indicated he can have this ready in the next day or two.</li>
<li>Cache is not yet ready. Marc Bennewitz, who is leading this effort indicated:
<ul>
<li>The EventManager usage needs review. (Matthew said he'll assist with that.)</li>
<li>The core functionality is ready, but several adapters are not yet refactored. (We indicated that those could happen at a later beta.)</li>
<li>Many docblocks are missing (prolic and Matthew indicated they can assist here).</li>
<li>End-user docs are not ready (Matthew indicated he can generate skeletons and start filling in details).</li>
<li>Most importantly: consumers of the Cache component need updating to follow the new API.</li>
</ul>
</li>
<li>Log is barely begun. Benoit Durand, leading the effort, indicated he hasn't had time the last two weeks. He said he'll have time starting during the weekend. Matthew urged him to pawn off tasks as much as possible to collaborators in IRC in order to speed development.</li>
<li>Config was originally slated for this beta, but due to the discussions earlier in this meeting, clearly will need further refactoring. Matthew suggested pushing this to beta3.</li>
</ul>
<p>Based on the fact that neither Cache nor Log are ready, we decided to push a go-no-go vote to next Wednesday (14 December 2011), and push hard as a community to get them ready to go. Ben Scholzen indicated that he can have Config ready in that time frame as well.</p>
<p><strong>tl;dr:</strong> We're waiting a week.<">
Dec 07 18:02:22 <weierophinney> Okay, all... let's get started
Dec 07 18:02:31 <weierophinney> Since I forgot to ask for a moderator, I guess that means I'm moderating.
Dec 07 18:02:38 <weierophinney> Agenda is here:
Dec 07 18:02:47 <guilhermeblanco> weierophinney: EvanDotPro can always moderate
Dec 07 18:02:50 <guilhermeblanco> =)
Dec 07 18:02:50 <weierophinney> EvanDotPro and Thinkscape, want to get started?
Dec 07 18:02:51 »» DASPRiD nomiates ChanServ
Dec 07 18:03:03 <weierophinney> guilhermeblanco, EvanDotPro will be talking too much in this one to moderate.
Dec 07 18:03:22 <EvanDotPro> weierophinney: haha, probably true
Dec 07 18:03:23 <guilhermeblanco> weierophinney: gimme op and I can kick if someone bugs too much
Dec 07 18:03:31 <weierophinney> guilhermeblanco, LOL
Dec 07 18:03:38 <DASPRiD> (funny that there is most of the time no "nay" vote on that page)
Dec 07 18:03:48 <weierophinney> To open op: the first few topics are about configuration and some proposed changes.
Dec 07 18:04:08 »» guilhermeblanco raises my hand
Dec 07 18:04:11 <weierophinney> Particularly to how we treat "environment-specific" configuration, as well as constants in configuration. They're kinda related.
Dec 07 18:04:19 <weierophinney> guilhermeblanco, yes?
Dec 07 18:04:25 <guilhermeblanco> weierophinney: point about config files is simple
Dec 07 18:04:38 <guilhermeblanco> you do not want to show all devs the prod specific config
Dec 07 18:04:42 <weierophinney> DASPRiD, what's frustrating is that the nay votes don't say why. Anwyays... on to guilhermeblanco
Dec 07 18:04:47 <weierophinney> guilhermeblanco, exactly
Dec 07 18:04:47 <guilhermeblanco> so it's better if you split into local files and global files
Dec 07 18:05:09 <guilhermeblanco> weierophinney: I suggets something compatible to GlobIterator...
Dec 07 18:05:14 <guilhermeblanco> which it's
Dec 07 18:05:16 <weierophinney> guilhermeblanco, well, it may not be just two environments. There may be testing, qa, etc. So globbing would take the env into account still.
Dec 07 18:05:30 <weierophinney> guilhermeblanco, yes, eaxctly – that's also how glob() works.
Dec 07 18:05:38 <guilhermeblanco> weierophinney: for other envs... just use
when needed
Dec 07 18:05:54 <guilhermeblanco> but main point is it's fixed naming convention
Dec 07 18:05:58 <weierophinney> it'd be "
" – we can use interpolation.
Dec 07 18:05:59 <guilhermeblanco> local for web app
Dec 07 18:06:04 <guilhermeblanco> weierophinney: no
Dec 07 18:06:08 <guilhermeblanco> global, local
Dec 07 18:06:09 <guilhermeblanco> fixed
Dec 07 18:06:12 <guilhermeblanco> and test
Dec 07 18:06:13 <guilhermeblanco> sorry
Dec 07 18:06:14 »» mabe__ is now known as mabe_
Dec 07 18:06:28 <guilhermeblanco> if you wanna modify env specific stuff... just alter local or test files
Dec 07 18:06:33 <guilhermeblanco> like...application.local.php
Dec 07 18:06:38 <guilhermeblanco> or application.test.php
Dec 07 18:06:45 <guilhermeblanco> but all possible config is placed into global file
Dec 07 18:06:56 <guilhermeblanco> application.global.php
Dec 07 18:07:49 <guilhermeblanco> weierophinney: we don't need to care about envs... user is supposed to configure this information in local and test files
Dec 07 18:08:00 <guilhermeblanco> we can even ship a application.locla.php.dist
Dec 07 18:08:03 <weierophinney> guilhermeblanco, I'm not convinced. I've often used many more environments than that, and wanted a "base" config I can create env-specific ones off of. I think doing this: glob(_DIR_ . "/configs/autoload/
.php") is fine
Dec 07 18:08:06 <guilhermeblanco> but not a requirement at all
Dec 07 18:08:15 <EvanDotPro> let's try to focus on what we do and do not want from ZF2 as a framework as far as configs go
Dec 07 18:08:42 <guilhermeblanco> weierophinney: if you're installing on an env... you do not need to care about $env
Dec 07 18:08:48 <guilhermeblanco> EvanDotPro: ok
Dec 07 18:08:52 <weierophinney> the env is configured by the developer, and seeded at the bootstrap stage. Doesn't require a constant, just declaring a variable so that the value can be discovered. It also allows setting env on CLI
Dec 07 18:08:57 <DASPRiD> EvanDotPro, pff, you always want the pudding first
Dec 07 18:09:00 »» guilhermeblanco gives voice to EvanDotPro
Dec 07 18:09:03 <Thinkscape> IMHO environments should not be offered or endorsed out-of-the-box (read: in skeleton or in docs).
Dec 07 18:09:20 <Thinkscape> They should be explained in docs as a separate document.
Dec 07 18:09:28 <weierophinney> Thinkscape, +1
Dec 07 18:09:40 <EvanDotPro> for example, one solution could be that we do not want the framework to be aware of environments, and thus not check configs for a section matching the environment string
Dec 07 18:09:58 <weierophinney> My point is that $env = getenv('APPLICATION_ENV'); is still reasonable
Dec 07 18:09:59 <intiilapa> Hello
Dec 07 18:10:06 <DASPRiD> EvanDotPro, +1
Dec 07 18:10:06 <Thinkscape> Same applies for complex, multi-directory, merged config configurations. It should be KISS from start + docs how to extend/change it.
Dec 07 18:10:20 <weierophinney> EvanDotPro, right – and you then only glob on "global" or a specific string
Dec 07 18:10:21 <EvanDotPro> weierophinney: but what would the framework do with that?
Dec 07 18:10:29 <guilhermeblanco> weierophinney: it did pretty much of what I wanted:
Dec 07 18:10:36 <weierophinney> EvanDotPro, see above – it would only be used in the glob pattern
Dec 07 18:10:45 <guilhermeblanco> EvanDotPro: +1
Dec 07 18:11:20 <weierophinney> guilhermeblanco, I'm simply saying that if you want different config envs, you'd have to change that script.
Dec 07 18:11:20 <EvanDotPro> weierophinney: ah, right.. so it can be used, but the framework would have no knowledge of it.
Dec 07 18:11:25 <EvanDotPro> it would be a user choice
Dec 07 18:11:27 <weierophinney> EvanDotPro, exactly.
Dec 07 18:11:30 <DASPRiD> yeah
Dec 07 18:11:33 <DASPRiD> i like that
Dec 07 18:11:33 <EvanDotPro> i'm +1 all over that
Dec 07 18:11:34 <Thinkscape> weierophinney: do we want that included by default in skeleton etc. ? I think it blurs the image ...
Dec 07 18:11:46 <Thinkscape> Arguably local/global is more important than DEV/PRODUCTION
Dec 07 18:11:52 <DASPRiD> then the question is: do we still need inheritance in zend\config
Dec 07 18:11:55 <guilhermeblanco> weierophinney: why would you need diff env files into same application server/box?
Dec 07 18:12:09 <EvanDotPro> theoretically, local and global covers everything.
Dec 07 18:12:18 <guilhermeblanco> EvanDotPro: agree
Dec 07 18:12:19 <Thinkscape> EvanDotPro: not really
Dec 07 18:12:24 <weierophinney> Thinkscape, we could simply discuss it in documentation, I suppose. But keeping the basic bootstrap flexible so that folks don't need to modify it for stuff like this has benefits, too.
Dec 07 18:12:32 <DASPRiD> EvanDotPro, should be a user choice whether he uses global/local or base config + env config
Dec 07 18:12:33 <EvanDotPro> well what i'm saying is that 'production' would really fall under local
Dec 07 18:12:47 <Thinkscape> EvanDotPro: I often have same-server, same-directory installations and "swap" envs to test them out...
Dec 07 18:12:48 <DASPRiD> but global + local should be fine in most cases
Dec 07 18:12:50 <EvanDotPro> if they choose to use a different or additional string to "local" that's up to them.
Dec 07 18:12:53 <weierophinney> EvanDotPro, theoretically, yes. In practice, I've had very different qa and testing envs.
Dec 07 18:12:56 <DASPRiD> although you want test configuration be preconfigured
Dec 07 18:13:06 <Thinkscape> weierophinney: like leave that line commented out ?
Dec 07 18:13:07 <DASPRiD> and not to be local
Dec 07 18:13:07 <weierophinney> and they may inherit from each other. So some details I may want in VCS
Dec 07 18:13:13 <guilhermeblanco> EvanDotPro: you may even want to have multiple application.*.php files... all you need to do is symlink the one you be active into app.local.php
Dec 07 18:13:15 <guilhermeblanco> and you're done
Dec 07 18:13:18 <EvanDotPro> weierophinney: no i'm saying you have a conig that's local to qa and a config that's local to testing.
Dec 07 18:13:33 <EvanDotPro> s/conig/config
Dec 07 18:13:35 <DASPRiD> guilhermeblanco, in development, you may want to use two envs at once: development and testing
Dec 07 18:13:38 <guilhermeblanco> symlinks are known to be bad under heavy server load... but it's totally acceptable
Dec 07 18:13:47 <guilhermeblanco> DASPRiD: so just place the symlink
Dec 07 18:13:50 <EvanDotPro> those both qualify as 'local' in my mind
Dec 07 18:13:50 <DASPRiD> development for apache/cli, testing for phpunit
Dec 07 18:13:58 <DASPRiD> guilhermeblanco, without changing symlinks all the time
Dec 07 18:13:59 <EvanDotPro> they're local to some specific environment.
Dec 07 18:13:59 <weierophinney> EvanDotPro, and sometimes those might inherit from each other.
Dec 07 18:14:10 <Thinkscape> simply put: local/global !== devel/production
Dec 07 18:14:12 <guilhermeblanco> DASPRiD: application.global.php, application.local.php and application.tets.php is what I'm suggesting
Dec 07 18:14:30 <DASPRiD> guilhermeblanco, well, eventually, that is up to the user what he prefers
Dec 07 18:14:34 <guilhermeblanco> Thinkscape: would you ever change local config on a prod server or even in dev box?
Dec 07 18:14:39 <EvanDotPro> they can do that too, just adjust the glob or manually array_replace_recursive from within a php config (my preference as it has total control)
Dec 07 18:14:41 <DASPRiD> we shouldn't discuss about something which will not touch the framework source
Dec 07 18:14:45 <Thinkscape> guilhermeblanco: sure
Dec 07 18:14:51 <guilhermeblanco> Thinkscape: how?
Dec 07 18:15:02 <guilhermeblanco> why not just place a symlink as the active config?
Dec 07 18:15:11 <guilhermeblanco> global, local and test
Dec 07 18:15:14 <guilhermeblanco> that's all I can see
Dec 07 18:15:37 <DASPRiD> global + local / global + test should be merged based on the env then
Dec 07 18:15:41 <EvanDotPro> my proposal is this: Zend Framework itself has no knowledge of what an "environment" is.
Dec 07 18:15:45 <ralphschindler> guys, i think we're really talking about two separate concepts: 1: Development environment () and then 2) application interface (web, cli, test)
Dec 07 18:15:49 <DASPRiD> EvanDotPro, +1
Dec 07 18:15:50 <Thinkscape> guilhermeblanco: swap db server, add api key, whatever. In my apps, local config relates to local machine (db, api keys etc.) while devel/production relates to log settings, error reports etc. Global holds everything else.
Dec 07 18:15:57 <guilhermeblanco> EvanDotPro: +1
Dec 07 18:16:08 <guilhermeblanco> Thinkscape: if you're doing it in prod... you're doing it wrong
Dec 07 18:16:11 <EvanDotPro> is anyone -1 to that?
Dec 07 18:16:11 <weierophinney> This is what I'm suggesting, btw:
Dec 07 18:16:16 <DASPRiD> Thinkscape, right
Dec 07 18:16:29 <Thinkscape> EvanDotPro: to what extent do we want to include those examples in skeleton and docs ?
Dec 07 18:16:39 <Thinkscape> (last one)
Dec 07 18:16:54 <EvanDotPro> Thinkscape: i dunno, i'd say whatever covers the most common cases.
Dec 07 18:17:01 <DASPRiD> i'm with Thinkscape here
Dec 07 18:17:16 <weierophinney> that was the wrong gist
Dec 07 18:17:19 <Thinkscape> Let's do the following:
Dec 07 18:17:19 <weierophinney> one sec
Dec 07 18:17:22 <weierophinney>
Dec 07 18:17:28 <weierophinney> That's what I was getting at.
Dec 07 18:17:34 <guilhermeblanco> weierophinney: +1
Dec 07 18:17:37 <Thinkscape> - we provide a skeleton that has a single, flat config structure (KISS)
Dec 07 18:17:38 <weierophinney> Which is in line with what EvanDotPro suggests.
Dec 07 18:17:46 <EvanDotPro> weierophinney: exactly
Dec 07 18:17:46 <DASPRiD> weierophinney, should be
imho
Dec 07 18:17:47 <Thinkscape> - we provide commented-out options for devel/production/staging
Dec 07 18:17:54 <Thinkscape> - we provide commented-out options for local/global
Dec 07 18:18:00 <guilhermeblanco> DASPRiD: that's too much
Dec 07 18:18:04 <Thinkscape> - we write up good explanation in docs on how to use it
Dec 07 18:18:30 <DASPRiD> guilhermeblanco, that are three configs, global and $env should never be touched, local be modified for local settings
Dec 07 18:18:32 <weierophinney> Thinkscape, do we comment them out, though? would we need to with the gist I suggested?
Dec 07 18:18:46 <EvanDotPro> remember this is just an example we're providing devs at this point, not the framework behavior
Dec 07 18:18:52 <Thinkscape> I think yes.
Dec 07 18:18:55 <guilhermeblanco> DASPRiD: I still think that's 3 I/Os
Dec 07 18:18:57 <weierophinney> DASPRiD, I'd argue the env one would likely extend a "local" config or base config.
Dec 07 18:18:59 <Thinkscape> It itroduces the concept
Dec 07 18:19:04 <Thinkscape> you have to explain it ...
Dec 07 18:19:09 <DASPRiD> guilhermeblanco, sure, if you disable all caching
Dec 07 18:19:13 <Thinkscape> I'd say just include global by default...
Dec 07 18:19:22 <Thinkscape> and have 2 extra commented lines with more "complex" scenarios.
Dec 07 18:19:24 <guilhermeblanco> DASPRiD: application is always loaded atm
Dec 07 18:19:29 <Thinkscape> = fast start for newbies
Dec 07 18:19:31 <guilhermeblanco> so I cannot comment on the future
Dec 07 18:19:32 <DASPRiD> weierophinney, extending… mh, should work
Dec 07 18:19:43 <DASPRiD> weierophinney, but then it can also extend the global one
Dec 07 18:19:53 <DASPRiD> weierophinney, which means we only need to load the env config
Dec 07 18:20:00 <weierophinney> Thinkscape, I disagree with only including global by default. We want to encourage developers to keep credentials and whatnot out of their configs. As such, they need a global, and a local that's outside VCS to override.
Dec 07 18:20:15 <Thinkscape> good point
Dec 07 18:20:21 <Thinkscape> but not to mix it with envs
Dec 07 18:20:22 <EvanDotPro> weierophinney: +1
Dec 07 18:20:29 <Thinkscape> so
Dec 07 18:20:33 <ralphschindler> +1
Dec 07 18:20:37 <guilhermeblanco> +1
Dec 07 18:20:39 <Thinkscape> because local != development
Dec 07 18:20:46 <weierophinney> Thinkscape, and then commented section showing how to do $env
Dec 07 18:20:52 <EvanDotPro> so i think we have a consensus here... because what we're talking about, imho covers every use case i can think of.
Dec 07 18:20:53 <Thinkscape> correct
Dec 07 18:21:04 <ralphschindler> so, out of curiosity, isn't this kidna the same a .dist.php and then just .php ?
Dec 07 18:21:21 <Thinkscape> + good explanation how to change order, merge local->global, global->local, global->production->local etc.
Dec 07 18:21:23 <guilhermeblanco> ralphschindler: application.local.php.dist
Dec 07 18:21:34 <guilhermeblanco> I'd rather change the terminology there
Dec 07 18:21:42 <weierophinney> ralphschindler, not quite. The ".dist" would be a template for a local file mainly
Dec 07 18:21:46 <Thinkscape> drop the .dist
Dec 07 18:21:51 <RobAllen> IMO dist files are never loaded by app
Dec 07 18:21:56 <guilhermeblanco> this enforces people to rename the file for local changes
Dec 07 18:22:03 <weierophinney> guilhermeblanco, +1
Dec 07 18:22:04 <DASPRiD> idd
Dec 07 18:22:08 <Thinkscape> weierophinney: you just said, it's good to educate people to keep local outside VCS...
Dec 07 18:22:08 <weierophinney> RobAllen, +
Dec 07 18:22:11 <Thinkscape> so no .dist
Dec 07 18:22:26 <DASPRiD> RobAllen, hah, there are a few php apps which actually load .dist if the .php is not present
Dec 07 18:22:32 <ralphschindler> this is now the way phpunit looks at it, but I'm ok with is as having a .dist suffix is something most IDE's don't recognize
Dec 07 18:22:33 <weierophinney> Thinkscape, different concept. .dist is a template
Dec 07 18:22:38 <guilhermeblanco> Thinkscape: you may distribute the dist file... but force dev to rename it. like final ext is .dist
Dec 07 18:22:42 <weierophinney> Thinkscape, and .dist would not get loaded.
Dec 07 18:22:46 <guilhermeblanco> so it's a php recognized file extension
Dec 07 18:22:48 <guilhermeblanco> =)
Dec 07 18:22:53 <Thinkscape> I know it is, but that's "another thing you have to do to make it work"
Dec 07 18:22:54 <guilhermeblanco> and makes it never loaded
Dec 07 18:22:56 <DASPRiD> ralphschindler, you can tell every ide to reconignize ".php.dist"
Dec 07 18:23:00 <guilhermeblanco> so... I agree with you in some parts
Dec 07 18:23:01 <guilhermeblanco> =)
Dec 07 18:23:07 <wilmoore> No secret that I'm a fan of the "application.
.dist" route
Dec 07 18:23:21 <ralphschindler> sure DASPRiD, but if its .dist.php it automatically recognizes it
Dec 07 18:23:30 <weierophinney> Thinkscape, if you're making a configurable application, you're going to have these sorts of artifacts.
Dec 07 18:23:36 <DASPRiD> ralphschindler, but tht could fit some glob pattern
Dec 07 18:23:45 <wilmoore> ralphschindler, +1
Dec 07 18:23:49 <Thinkscape> Will it work, if I download skeleton and run it without local.php ? (but with the local.php.dist ? )
Dec 07 18:23:57 <guilhermeblanco> weierophinney: 24min of this topic already
Dec 07 18:24:04 <guilhermeblanco> so.. votes required
Dec 07 18:24:11 <DASPRiD> also, the general "make" way is always to prepend ".in" to a template file
Dec 07 18:24:11 <guilhermeblanco> and next topic
Dec 07 18:24:23 <weierophinney> guilhermeblanco, Agreed. I'll sum up:
Dec 07 18:24:36 <weierophinney> * No application envs INSIDE config files
Dec 07 18:25:00 <weierophinney> * Ship a "global" config, and optionally a "local" config template (likely with a .dist segment)
Dec 07 18:25:13 <weierophinney> * use glob() to aggregate config for merging
Dec 07 18:25:42 »» EvanDotPro proposes that we also include a .gitignore in the skeleton which ignores the non-dist local conig.
Dec 07 18:25:46 <guilhermeblanco> re point 2. Make .dist segment at the end. So dev is enforced to rename it to work.
Dec 07 18:25:49 <weierophinney> * have commented areas in the base index.php showing how you might use an ENV to glob different configs than the shipped.
Dec 07 18:25:54 <weierophinney> EvanDotPro, +1
Dec 07 18:26:00 <wilmoore> EvanDotPro, +1
Dec 07 18:26:01 <guilhermeblanco> EvanDotPro: +1
Dec 07 18:26:13 »» RobAllen_ is now known as RobAllen
Dec 07 18:26:25 »» guilhermeblanco loves standardization =)
Dec 07 18:26:30 <wilmoore> guilhermeblanco, +1 (RE: .dist at the end)
Dec 07 18:26:35 <DASPRiD> +1 @ all
Dec 07 18:26:39 <DASPRiD> (lazy)
Dec 07 18:26:41 <weierophinney> Next topic: deprecate PHP constant usage in config files.
Dec 07 18:26:44 <prolic> +1 for .dist at the end
Dec 07 18:26:47 <DASPRiD> weierophinney, stop plz
Dec 07 18:26:50 <ralphschindler> wait a sec
Dec 07 18:26:59 <weierophinney> ralphschindler, DASPRiD tie it up quickly
Dec 07 18:27:07 <weierophinney> looks like guilhermeblanco has votes at this point.
Dec 07 18:27:11 <ralphschindler> if we're talking about a module, .gitignore is useless as you're not suppose to edit configs in the module anywa
Dec 07 18:27:21 <ralphschindler> so whats the point?
Dec 07 18:27:26 <DASPRiD> since we are removing envs from the config files, are we still in need for inheritance in config files?
Dec 07 18:27:31 <weierophinney> ralphschindler, we're talking about the app skeleton
Dec 07 18:27:34 <weierophinney> not the modules
Dec 07 18:27:51 <weierophinney> ralphschindler, module config overrides go into your application config directory
Dec 07 18:27:52 <Thinkscape> DASPRiD: inheritance like in "merging" ?
Dec 07 18:27:55 <ralphschindler> ah, gotcha- sounds good then (as this does not apply to a ZendModuleSkeleton)
Dec 07 18:27:57 <wilmoore> DASPRiD: My vote would be to remove the inheritance
Dec 07 18:27:59 <DASPRiD> Thinkscape, like "extends"
Dec 07 18:28:04 <DASPRiD> wilmoore, dito
Dec 07 18:28:17 <guilhermeblanco> wilmoore: +1
Dec 07 18:28:20 <weierophinney> DASPRiD, I still see some places it could be useful. routes, for instance.
Dec 07 18:28:33 <weierophinney> but most of those cases could likely be covered by merging.
Dec 07 18:28:38 <RobAllen> Are we expecting devs to clone skeleton?
Dec 07 18:28:41 <wilmoore> weierophinney: in that case, I would document that use of Yaml is preferred
Dec 07 18:28:43 <SpiffyJr_> Ah ha. Found it.
Dec 07 18:28:44 <Thinkscape> well, array_replace_recursive() takes care of that ...
Dec 07 18:28:45 <DASPRiD> weierophinney, inheritance for routes? uh?
Dec 07 18:28:51 <DASPRiD> wilmoore, it is not
Dec 07 18:28:51 <mabe_> there is also an issue to include config files from another
Dec 07 18:28:51 <weierophinney> RobAllen, that, or console tool would create it
Dec 07 18:28:54 <RobAllen> Yaml?!?!?!?
Dec 07 18:29:06 <wilmoore> DASPRiD: I mean for that use case that weierophinney suggests
Dec 07 18:29:16 <weierophinney> mabe_, that would be importing.
Dec 07 18:29:17 <DASPRiD> wilmoore, heh, nah, php is prefered for that
Dec 07 18:29:24 <RobAllen> I'm assuming skel will be in my repo
Dec 07 18:29:28 <weierophinney> kk, we're off topic now
Dec 07 18:29:31 <DASPRiD> wilmoore, we will surely not suggest the most slow format
Dec 07 18:29:34 <weierophinney> Move on to next topic NOW
Dec 07 18:29:43 <SpiffyJr_> So, I miss constants?
Dec 07 18:29:45 <DASPRiD> so: drop inheritance?
Dec 07 18:29:45 <weierophinney> "Discuss deprecation of mandatory/recommended PHP_CONSTANTS in config files and documentation"
Dec 07 18:29:46 <Thinkscape> DASPRiD: replace_recursive() (if that's what we use) will take care of that. It will add new routes to existing collection etc.
Dec 07 18:29:47 <SpiffyJr_> Bollocks.
Dec 07 18:29:56 <weierophinney> SpiffyJr_, we're just starting that one.
Dec 07 18:29:57 <DASPRiD> Thinkscape, indeed
Dec 07 18:30:02 <SpiffyJr_> woohoo
Dec 07 18:30:09 <guilhermeblanco> weierophinney: conceptually... -1
Dec 07 18:30:11 <weierophinney> Thinkscape, take it away.
Dec 07 18:30:12 <EvanDotPro> SpiffyJr_: you missed the application environment thing, and the consensus was what you were hoping for.
Dec 07 18:30:22 <SpiffyJr_> EvanDotPro: Yes!
Dec 07 18:30:23 <weierophinney> guilhermeblanco, why?
Dec 07 18:30:24 <Thinkscape> kk
Dec 07 18:30:31 <Thinkscape> Guys... guys ... guys...
Dec 07 18:30:34 <Thinkscape> (and gals?)
Dec 07 18:30:38 <guilhermeblanco> weierophinney: Paths is an important thing to keep in mind
Dec 07 18:30:51 <Thinkscape> Please give me any good use cases where you use PHP_CONSTANTS inside config files
Dec 07 18:30:56 <Thinkscape> (aside from previously mentioned)
Dec 07 18:30:56 <DASPRiD> paths are exactly the point here
Dec 07 18:30:56 <guilhermeblanco> if you drop constants... how can you play nice with absolute paths?
Dec 07 18:31:01 <wilmoore> weierophinney, +1 (RE: deprecate PHP CONSTANTS in configs)
Dec 07 18:31:03 <weierophinney> guilhermeblanco, paths are still present. They're simply either absolute, or relative to the application root
Dec 07 18:31:20 <DASPRiD> +1 deprecrate them
Dec 07 18:31:21 <SpiffyJr_> +1 for deprecation
Dec 07 18:31:26 <guilhermeblanco> weierophinney: but devs are willing to refer to something like: APPLICATION_ROOT
Dec 07 18:31:36 <Thinkscape> There is no APPLICATION dir any more
Dec 07 18:31:39 <weierophinney> guilhermeblanco, they wouldn't anymore.
Dec 07 18:31:39 <Thinkscape> so no APPLICATION_ROOT
Dec 07 18:31:41 <DASPRiD> (if deprecation means we drop them from the current config readers)
Dec 07 18:31:44 <Thinkscape> any other use case ?
Dec 07 18:31:53 <guilhermeblanco> weierophinney: so how can you map a path without constants?
Dec 07 18:31:54 <EvanDotPro> okay i have a question then.
Dec 07 18:32:00 <DASPRiD> guilhermeblanco, relative
Dec 07 18:32:02 <Thinkscape> DASPRiD: yes, config values will be just string. HOWEVER, we will give you parsing component..
Dec 07 18:32:11 <weierophinney> guilhermeblanco, the idea would be that the bootstrap script changes to the application root directory. fopen/file_get_contents/parse_ini_file/etc. all work relative from the CWD
Dec 07 18:32:15 <DASPRiD> Thinkscape, i'm the "we" here
Dec 07 18:32:17 <guilhermeblanco> DASPRiD: relatives implies into include_path inclusions
Dec 07 18:32:19 <guilhermeblanco> #bad
Dec 07 18:32:22 <mabe_> what about something like log to "PHP_SAPI.log"
Dec 07 18:32:23 <DASPRiD> guilhermeblanco, no
Dec 07 18:32:27 <DASPRiD> guilhermeblanco, relative to CWD
Dec 07 18:32:31 <wilmoore> guilhermeblanco: ant, phing, gradle, etc. all handle this.
Dec 07 18:32:34 <DASPRiD> which is the application root
Dec 07 18:32:45 <guilhermeblanco> DASPRiD: I need to see a sample
Dec 07 18:32:46 <Thinkscape> mabe_: explain
Dec 07 18:32:49 <EvanDotPro> if paths must be absolute or relative to the application root, then would we no longer allow any sort of paths relative to a module within module configs (view script paths)
Dec 07 18:32:50 <weierophinney> guilhermeblanco, no, not include_path. That's only for code you include/require. Paths in configs should be about application resources, not class loading
Dec 07 18:32:54 <guilhermeblanco> comment without having code is useless then
Dec 07 18:33:02 <guilhermeblanco> sorry
Dec 07 18:33:06 <DASPRiD> guilhermeblanco, there was a long mailing list entry
Dec 07 18:33:09 <DASPRiD> guilhermeblanco, linekd in the agenda
Dec 07 18:33:11 <Thinkscape> EvanDotPro: I suggest we resolve this inside View* component ...
Dec 07 18:33:21 <mabe_> Thinkscape a constant to switch between file names
Dec 07 18:33:35 <RobAllen> We use a config define for some stuff unrelated to paths
Dec 07 18:33:37 <guilhermeblanco> DASPRiD: ok... I got it
Dec 07 18:33:51 <guilhermeblanco> +0
Dec 07 18:33:59 <Thinkscape> mabe_: you just switch it in global or local config ...
Dec 07 18:34:00 <guilhermeblanco> I don't really care about this change then
Dec 07 18:34:02 <EvanDotPro> Thinkscape: views were just an example (i don't have a another), but it would potentially come up any time a module wants to have any config value with a path relative to where the module lives.
Dec 07 18:34:17 <guilhermeblanco> EvanDotPro: Thinkscape stick to the topic
Dec 07 18:34:23 <DASPRiD> EvanDotPro, i thought we solved that in the ML already?
Dec 07 18:34:34 <Thinkscape> EvanDotPro: that's a valid point. Because modules are loaded programatically anyways, I'd suggest it should be handled by module manager or module.php
Dec 07 18:34:36 <EvanDotPro> did we?
Dec 07 18:34:36 <weierophinney> EvanDotPro, the question of view script paths is a good one, though. Right now, with PHP config files, it's a non-issue – use _DIR_. But with other styles, yes, we have issues. But the idea would be to include a pre-parser to substitute values as eneded.
Dec 07 18:34:40 <DASPRiD> EvanDotPro, config gives relative path to module, module makes it to an absolute one
Dec 07 18:34:49 <mabe_> no really if you have more than local+global
Dec 07 18:34:54 <DASPRiD> weierophinney, i wouldnt even do that
Dec 07 18:34:55 <mabe_> or i'm wrong
Dec 07 18:35:10 <Thinkscape> Can I point out one thing?
Dec 07 18:35:27 <Thinkscape> You define module paths explicitly (inside init.php or public.php)
Dec 07 18:35:27 <weierophinney> Thinkscape, go for it
Dec 07 18:35:32 <Thinkscape> so you know those paths ...
Dec 07 18:35:35 <EvanDotPro> i think i might be with Thinkscape on this one... if we need a relative path to the module for something, that's probably best suited to handle in Module.php or similar.
Dec 07 18:35:43 <DASPRiD> Thinkscape, +1
Dec 07 18:35:50 <weierophinney> EvanDotPro, Thinkscape +1
Dec 07 18:35:54 <DASPRiD> Thinkscape, it's not really a configuration thingy like that
Dec 07 18:35:54 <EvanDotPro> i'd say we should discourage "dynamic" values in configs
Dec 07 18:36:01 <DASPRiD> EvanDotPro, right
Dec 07 18:36:02 <Thinkscape> So it boils down to the scenario of: a module with NO CONFIG by default searches for it's OWN view scripts.
Dec 07 18:36:38 <Thinkscape> I'd suggest it's done inside module.php: there you can use _DIR_ and inject it inside ViewScriptStack
Dec 07 18:36:49 <DASPRiD> yep
Dec 07 18:36:51 <EvanDotPro> Thinkscape: exactly
Dec 07 18:37:09 <Thinkscape> We could automate/ease it a bit with some handy function....
Dec 07 18:37:12 <EvanDotPro> and i'd argue that any other scenarios where a similar issue comes up, the solution would be the same
Dec 07 18:37:17 <Thinkscape> (inside Zend\Module\ somewhere)
Dec 07 18:37:21 <DASPRiD> and in case you want to configure a path relative to module, you put a relative path in the config, and make in absolute in the Module.php
Dec 07 18:37:29 <DASPRiD> that's really a user choice then
Dec 07 18:37:58 <SpiffyJr_> +1 EvanDotPro Thinkscape
Dec 07 18:38:05 <weierophinney> So, final thoughts on this topic?
Dec 07 18:38:06 <Thinkscape> true. Some people pointed out that modules can be scattered througout the whole filesystem ... but in that case that is NOT a standard scenario to find yourself in. That can be handled with scanners/parsers and _DIR_
Dec 07 18:38:15 <weierophinney> Who wants to write the constant parser functionality?
Dec 07 18:38:33 <EvanDotPro> final thoughts: the one scenario where constants make sense have an alternative suggestion now, so constants in configs can be deprecated
Dec 07 18:38:39 <DASPRiD> weierophinney, will constant parser functionallity go out of Zend\Config\Reader s?
Dec 07 18:38:44 <guilhermeblanco> EvanDotPro: +0
Dec 07 18:38:55 <guilhermeblanco> I'm neutral on this one
Dec 07 18:38:58 <guilhermeblanco> just reading
Dec 07 18:39:01 <EvanDotPro> maybe not deprecated, but not relied upon.
Dec 07 18:39:13 <weierophinney> DASPRiD, I'd say so – we'd move it into a separate class under the Zend\Config namespace
Dec 07 18:39:21 <Thinkscape> not implicitly (as in ALWAYS) parsed - only opt-in
Dec 07 18:39:24 <weierophinney> (or set of classes, dependent on approach)
Dec 07 18:39:31 <DASPRiD> weierophinney, so Zend\Config\Xml woudl not use <zf:const /> anymore, correct?
Dec 07 18:39:34 <SpiffyJr_> Thinkscape: +1 for opt-in
Dec 07 18:39:40 <MikeA> EvanDotPro: "not relied upon" == confusing
Dec 07 18:39:59 <weierophinney> DASPRiD, it'd be either opt-in, or we'd have a parser that would auto-expand the constant values prior to parsing the file.
Dec 07 18:40:03 <Thinkscape> MikeA: there will be no constant in skeleton app and no global constant inside any Zend* component
Dec 07 18:40:13 <Thinkscape> weierophinney: me
Dec 07 18:40:17 <EvanDotPro> right now we're 100% reliant on _DIR_ and i'm majorily -1 on that.
Dec 07 18:40:26 <DASPRiD> weierophinney, mh, we gotta talk about implementation details, but later
Dec 07 18:40:27 <weierophinney> Thinkscape, cool
Dec 07 18:40:37 <RobAllen> Consts should only be app specific
Dec 07 18:40:38 <weierophinney> DASPRiD, discuss them with Thinkscape
Dec 07 18:40:40 <Thinkscape> Next topic
Dec 07 18:40:44 <weierophinney> RobAllen, +1
Dec 07 18:40:54 <EvanDotPro> with Thinkscape's suggestion, we no longer have that particular need for constants (particularly magic constants)
Dec 07 18:41:03 <DASPRiD> indeed
Dec 07 18:41:07 <weierophinney> Next topic is related to the last two:
Dec 07 18:41:14 <weierophinney> "Discuss endorsement of root (main) application path"
Dec 07 18:41:30 <DASPRiD> +1 @ chdir() in entry point
Dec 07 18:41:41 <weierophinney> We've kind of already discussed this with the previous.
Dec 07 18:41:46 <ralphschindler> ie: "Application path becomes a first class constant in Zend\Mvc\Application" ?
Dec 07 18:41:47 <Thinkscape> Does anyone see any problem with chdir(_DIR) or chdir(DIR_."/../) and then using relative paths in all other modules/components?
Dec 07 18:41:48 <DASPRiD> somewhat, yeah
Dec 07 18:41:57 <DASPRiD> ralphschindler, no constants
Dec 07 18:41:58 <weierophinney> ralphschindler, no, not a constant
Dec 07 18:41:59 <ralphschindler> constant = concept
Dec 07 18:42:00 <ralphschindler> sorry
Dec 07 18:42:04 <DASPRiD> ralphschindler, ah, heh
Dec 07 18:42:27 <DASPRiD> Thinkscape, i'm fine with that
Dec 07 18:42:36 <weierophinney> Thinkscape, between you and ralphschindler and EvanDotPro, I'm convinced at this time.
Dec 07 18:43:15 <Thinkscape> btw: this and previous one will deprecate things like _DIR_."/../../../../library/foo" ....
Dec 07 18:43:17 <RobAllen> Me too
Dec 07 18:43:23 <EvanDotPro> is getcwd() right now not ./public/?
Dec 07 18:43:27 <ralphschindler> i wasn't arguing one way or the other, i was just pointing out that PHP itself strictly adheres to the current working directory in all filesystem operations
Dec 07 18:43:37 <ralphschindler> EvanDotPro: yes
Dec 07 18:43:38 <DASPRiD> EvanDotPro, that's why we do chdir()
Dec 07 18:43:45 <weierophinney> EvanDotPro, getcwd() will be the public directory – hence the need to chdir()
Dec 07 18:44:03 <guilhermeblanco> weierophinney: 15min
Dec 07 18:44:04 <SpiffyJr_> weierophinney: presumably in index.php?
Dec 07 18:44:08 <Thinkscape> we have to do chdir() to make sure we have the proper one (bacause i.e. MS IIS handles that differently from Apache)
Dec 07 18:44:11 <ralphschindler> (or any php file dispatched from the public directory or subdirectory that uses your application resources)
Dec 07 18:44:15 <weierophinney> guilhermeblanco, actually, we have up to 45m left.
Dec 07 18:44:17 <DASPRiD> SpiffyJr_, correct
Dec 07 18:44:33 <weierophinney> guilhermeblanco, we alot up to 90, but try to keep it to 60
Dec 07 18:44:40 <weierophinney> SpiffyJr_, yes
Dec 07 18:44:43 <EvanDotPro> Thinkscape: thanks, that's what i was looking for
Dec 07 18:44:47 <Thinkscape> Guys...any counter ideas or arguments?
Dec 07 18:44:51 <weierophinney> any further debate at this time?
Dec 07 18:45:04 <weierophinney> NEXT
Dec 07 18:45:09 <ralphschindler> none from me, i always like utilizing features in PHP
Dec 07 18:45:12 <weierophinney> I'm going to skip to the last topic
Dec 07 18:45:17 <weierophinney> and get back to beta2 readiness
Dec 07 18:45:18 <weierophinney> So:
Dec 07 18:45:19 <Thinkscape>
Dec 07 18:45:25 <weierophinney> "Pull Request Queue Management"
Dec 07 18:45:36 <DASPRiD> +1 for closing
Dec 07 18:45:44 <guilhermeblanco> weierophinney: can I "hijack" and ask for another discussion topic later?
Dec 07 18:45:45 <EvanDotPro> +1 for closing as well
Dec 07 18:45:46 <weierophinney> I think the quote RobAllen put in from Dolf works well.
Dec 07 18:45:49 <EvanDotPro> the stale ones stress me out
Dec 07 18:46:01 <weierophinney> guilhermeblanco, we should only do ones that have been discussed on-list
Dec 07 18:46:06 <weierophinney> if it has, sure.
Dec 07 18:46:16 <guilhermeblanco> weierophinney: it's not... I think we can do later
Dec 07 18:46:34 <Thinkscape> One question: what happens if for a closed PR, someone comments, but the other side "forgets" about it ?
Dec 07 18:46:39 <weierophinney> My feeling is that we should ratify this and have it stated somewhere prominent, so that folks know what to expect.
Dec 07 18:46:45 <Thinkscape> (and does not reopen it)
Dec 07 18:46:57 <weierophinney> Thinkscape, if they don't re-open it, it's their own damn fault.
Dec 07 18:47:05 »» prolic does not know how to reopen a pull request
Dec 07 18:47:06 <SpiffyJr_> I agree with closing PR's and only open ones indicating a potential merge. With the removal of the CLA it's going to be essential for new contributors to be able to quickly determine if something is fixed or being fixed already.
Dec 07 18:47:16 <wilmoore> +1 for closing
Dec 07 18:47:22 <SpiffyJr_> tldr: +1
Dec 07 18:47:29 <weierophinney> prolic, if you were the person who submitted it, you can revisit it, and there's a nice big "re-open" button
Dec 07 18:47:30 <Thinkscape> Because there are currently few people inside Zend org. on github, there is "fuzzy responsibility"
Dec 07 18:47:39 <RobAllen> Can always open a new PR too
Dec 07 18:47:47 <prolic> thank you weierophinney
Dec 07 18:47:55 <Thinkscape> weierophinney: wait, what? only zend/* people can reopen...
Dec 07 18:47:59 <Thinkscape> not the submitter.
Dec 07 18:48:04 <weierophinney> Thinkscape, NO
Dec 07 18:48:12 <weierophinney> Thinkscape, the SUBMITTER can reopen
Dec 07 18:48:13 <Thinkscape> can I reopen a PR ?
Dec 07 18:48:15 <Thinkscape> ah
Dec 07 18:48:15 <weierophinney> yes
Dec 07 18:48:15 <SpiffyJr_> Thinkscape: No, if your the PR submitter you can reopen.
Dec 07 18:48:18 <Thinkscape> oknm
Dec 07 18:48:32 <Thinkscape> So it's dead simple and should be announced ASAP.
Dec 07 18:48:43 <weierophinney> Thinkscape,
Dec 07 18:48:46 <Thinkscape> Let them PR's pour in
Dec 07 18:48:49 <weierophinney> that didn't take much convincing.
Dec 07 18:48:53 »» SpiffyJr_ waits for emails about his PR's being closed...
Dec 07 18:49:02 <Thinkscape> SpiffyJr_: set it up on github
Dec 07 18:49:08 <RobAllen> Great. That makes life easier
Dec 07 18:49:21 <Thinkscape> (email notifications)
Dec 07 18:49:29 <weierophinney> Okay.. I'll put this in the README-DEV.txt, in README-GIT.txt, and find a place on the zf2 subsite to note it.
Dec 07 18:49:46 <weierophinney> So, moving to the last topic:
Dec 07 18:49:52 <weierophinney> "Schedule Beta 2 Release"
Dec 07 18:50:00 <SpiffyJr_> right meow
Dec 07 18:50:06 <weierophinney> Zend\Mail is ready, except for docs. I can get those done by tomorrow.
Dec 07 18:50:12 <EvanDotPro> midnight?
Dec 07 18:50:15 <guilhermeblanco> weierophinney: 2 weeks ago? =P
Dec 07 18:50:21 <RobAllen> Heading home now. Back online later
Dec 07 18:50:26 <weierophinney> I believe mabe_ indicated Zend\Cache is ready?
Dec 07 18:50:28 <Thinkscape> weierophinney: tests? I've taken a peak, and there's been like 20% done
Dec 07 18:50:36 <Thinkscape> peelk
Dec 07 18:50:39 <weierophinney> Thinkscape, on what?
Dec 07 18:50:43 <weierophinney> Mail is tested.
Dec 07 18:50:48 <Thinkscape> Mail
Dec 07 18:50:56 <Thinkscape> hmm..
Dec 07 18:50:56 <weierophinney> Thinkscape, did you look on my branch?
Dec 07 18:50:57 <guilhermeblanco> Thinkscape: I tried test suite yesterday... it was broken to me
Dec 07 18:50:58 <mabe_> cache is ready with some adapters/plugins - see last ML thread
Dec 07 18:51:06 <Thinkscape> yes.
Dec 07 18:51:07 <guilhermeblanco> probably an intermitent issue
Dec 07 18:51:10 <weierophinney> guilhermeblanco, did you test my branch? it's not merged yet.
Dec 07 18:51:21 <EvanDotPro> i have one PR that i am going to be submitting momentarily that i will want in beta2 (removing envs per this meeting)
Dec 07 18:51:26 <Thinkscape> ok, we'll trust you on this one
Dec 07 18:51:30 <weierophinney> Thinkscape, The new stuff for the transports, Message, address list, address, and headers is tested. I used TDD as I went.
Dec 07 18:51:33 <Thinkscape> What about Cache?
Dec 07 18:51:35 <guilhermeblanco> weierophinney: no... I'm actually trying to change the EventManager N instances (which it's the topic I wanna inject)
Dec 07 18:51:36 <mabe_> but some is missing like : Memcached, SQLite, apc, ...
Dec 07 18:51:45 <guilhermeblanco> weierophinney: what's supposed to be in b2?
Dec 07 18:51:46 <weierophinney> EvanDotPro, kk, noted
Dec 07 18:51:50 <guilhermeblanco> Cache, Mail and Log?
Dec 07 18:51:55 <weierophinney> mabe_, is the base rewrite ready to go, though?
Dec 07 18:52:09 <mabe_> yes
Dec 07 18:52:12 <DASPRiD> guilhermeblanco, finished zf2 router is in b2
Dec 07 18:52:26 <weierophinney> guilhermeblanco, cache, mail, log, and a bunch of mvc/module imprvements
Dec 07 18:52:29 <EvanDotPro> guilhermeblanco: ah, that... let's talk about that in zftalk.2 with weierophinney after and we'll put it up for the next meeting depending on how the conversation goes
Dec 07 18:52:31 <weierophinney> mabe_, cool – docs?
Dec 07 18:52:40 <guilhermeblanco> DASPRiD: originally (October-12) we defines that b2 should also include Config
Dec 07 18:52:42 <mabe_> the event manager implementation should be reviewed
Dec 07 18:52:43 <guilhermeblanco> weierophinney: ^
Dec 07 18:52:50 <weierophinney> EvanDotPro, guilhermeblanco I have to leave briefly right after the meeting; I'll ping you when back
Dec 07 18:52:54 <DASPRiD> guilhermeblanco, yeah… except that we had this config discussion right now
Dec 07 18:52:54 <EvanDotPro> guilhermeblanco: (last was re the EventManagerinstances)
Dec 07 18:52:55 <mabe_> docs are missing completely
Dec 07 18:53:05 <EvanDotPro> weierophinney: that's fine
Dec 07 18:53:09 <mabe_> including most phpdocs
Dec 07 18:53:20 <weierophinney> mabe_, kk – how long until you can get docs ready? If I generate skeletons for you, would that help?
Dec 07 18:53:23 <prolic> mabe i can help out with phpdocs
Dec 07 18:53:28 <weierophinney> prolic, awesome
Dec 07 18:54:10 <mabe_> a skeleton helps - i thing end of next week ( fr )
Dec 07 18:54:13 <prolic> i can submit them until friday, is that okay?
Dec 07 18:54:14 <weierophinney> guilhermeblanco, We'll push config changes to b3 now. Too many questions came up in the last two weeks
Dec 07 18:54:23 <guilhermeblanco> weierophinney: ok
Dec 07 18:54:24 <mabe_> prolic great
Dec 07 18:54:42 <guilhermeblanco> weierophinney: but we still have to define a commitment here
Dec 07 18:54:43 <weierophinney> mabe_, oof, end of next week is getting a bit late.
Dec 07 18:54:49 <guilhermeblanco> b2 is about to be released when?
Dec 07 18:54:51 <mabe_> weierophinney: can someone review the event manager implementation ?
Dec 07 18:54:57 <weierophinney> guilhermeblanco, was hoping this week
Dec 07 18:55:04 <weierophinney> mabe_, yes, I'll do that ASAP
Dec 07 18:55:07 <mabe_> weierophinney: i'm working
Dec 07 18:55:13 <mabe_> thanks
Dec 07 18:55:21 <prolic> mabe: which branch? cache_beta2 i assume?
Dec 07 18:55:32 <mabe_> prolic yes
Dec 07 18:55:33 <weierophinney> mabe_, I'll fork your branch, and work with prolic on docblocks and docbook skeletons
Dec 07 18:55:35 <prolic> ok
Dec 07 18:55:45 <weierophinney> maybe we can get it in "good enough" state sooner.
Dec 07 18:55:51 <SpiffyJr_> weierophinney: This Friday?
Dec 07 18:55:57 <weierophinney> SpiffyJr_, we can try!
Dec 07 18:56:00 <mabe_> much thanks
Dec 07 18:56:03 <weierophinney> Is intiilapa here?
Dec 07 18:56:06 <SpiffyJr_> Would be nice!
Dec 07 18:56:07 <weierophinney> how is log coming?
Dec 07 18:56:35 <mabe_> how to rewrite dependend components ?
Dec 07 18:56:52 <wilmoore> mabe_: rm -rf
Dec 07 18:56:58 <wilmoore> mabe_: j/k
Dec 07 18:57:06 <intiilapa> weierophinney: yes
Dec 07 18:57:06 <weierophinney> mabe_, hm?
Dec 07 18:57:11 <mabe_> doesn't work well
Dec 07 18:57:17 <weierophinney> intiilapa, what's the state of log?
Dec 07 18:57:43 <intiilapa> I'm overwhelmed right now, and I could not spend any time in ZF since two weeks :\ so at the beginning. I try to continue this week-end.
Dec 07 18:57:51 <weierophinney> mabe_, oh, you mean the components that consume cache?
Dec 07 18:57:53 <mabe_> weierophinney: there are components using Zend\Cache that needs to be changed
Dec 07 18:58:00 <mabe_> oh yes
Dec 07 18:58:18 <weierophinney> mabe_, so, this sounds like we will need to push off until sometime next week
Dec 07 18:58:31 <weierophinney> because we likely don't want to ship with cache broken everywhere.
Dec 07 18:58:41 <prolic> agreed
Dec 07 18:58:42 <weierophinney> mabe_, can you write up the chief changes to consuming the component?
Dec 07 18:58:46 <DASPRiD> weierophinney, then we can probably finish the config rewrite until then
Dec 07 18:58:49 <guilhermeblanco> weierophinney: mabe_ are these components willing to consume cache
Dec 07 18:58:49 <guilhermeblanco> can't we make a boundary to them?
Dec 07 18:58:57 <weierophinney> intiilapa, can you get log ready by this time next week?
Dec 07 18:59:01 <guilhermeblanco> I hate hard dependencies
Dec 07 18:59:02 <mabe_> creating a branch for that and merge to master if ready ?
Dec 07 18:59:14 <weierophinney> guilhermeblanco, that's a good idea – maybe a compat layer?
Dec 07 18:59:19 <guilhermeblanco> weierophinney: ya
Dec 07 18:59:22 <intiilapa> some news about ralph's idea for bridge and dependency?
Dec 07 18:59:27 <weierophinney> intiilapa, not yet
Dec 07 18:59:28 <prolic> question: should components know about zend\cache or just emit events that a cache listener is listening for?
Dec 07 18:59:30 <mabe_> i'll do that
Dec 07 18:59:37 <intiilapa> weierophinney: when next week?
Dec 07 18:59:41 <weierophinney> prolic, ideally, they'd compose listeners
Dec 07 18:59:41 <guilhermeblanco> interface and you can just attach a control instance that implements the boundary
Dec 07 18:59:48 <weierophinney> intiilapa, this time next week?
Dec 07 19:00:03 <weierophinney> prolic, but that may be a bit much to tackle in a week.
Dec 07 19:00:11 <weierophinney> So, I'm going to sum up:
Dec 07 19:00:16 <weierophinney> * Mail is ready except for docs
Dec 07 19:00:36 <weierophinney> * Cache core functionality is ready except for docs; some adapters are not yet ready but can be pushed to a later beta
Dec 07 19:00:39 <wilmoore> of course, that would still break old consumers that assume they need to pass in a Zend_Cache or Zend\Cache instance.
Dec 07 19:00:49 <weierophinney> * Components consuming cache need to be refactored to new API
Dec 07 19:00:59 <wilmoore> weierophinney, +1
Dec 07 19:01:00 <weierophinney> * Log rewrite is just starting
Dec 07 19:01:26 <weierophinney> * tl;dr: Try and get all that done by next week in order to release.
Dec 07 19:01:44 <guilhermeblanco> weierophinney: Components consuming cache should be refactored to not have hard dependency of Cache component
Dec 07 19:01:54 <intiilapa> weierophinney: I can try
Dec 07 19:01:57 <guilhermeblanco> then I'm +1
Dec 07 19:02:04 <weierophinney> guilhermeblanco, that's ideal – want to assist?
Dec 07 19:02:11 <guilhermeblanco> weierophinney: sure
Dec 07 19:02:17 <weierophinney> intiilapa, anything you can, push off to others to assist
Dec 07 19:02:20 <guilhermeblanco> who's taking care of this change?
Dec 07 19:02:25 <weierophinney> intiilapa, ask in #zftalk.2
Dec 07 19:02:30 <guilhermeblanco> weierophinney: ok
Dec 07 19:02:34 <weierophinney> we'll make helping mabe_ and intiilapa a priority this week!
Dec 07 19:02:48 <intiilapa> weierophinney: add time on my watch XD
Dec 07 19:02:55 <weierophinney> guilhermeblanco, mabe_ is spearheading cache – work with him, prolic, and myself
Dec 07 19:02:59 <mabe_>
Dec 07 19:03:02 <guilhermeblanco> weierophinney: ok
Dec 07 19:03:02 <weierophinney> intiilapa, I'm ON IT!
</pre>
]]></ac:plain-text-body></ac:macro>
><<