Symfony leaving PHP-FIG

[Fabien Potencier]

Most of you have probably seen my pull request to remove Symfony as a 
member project,
and I wanted to follow up and clarify a few things.

Symfony has always aimed to promote and follow various standards, and many 
of the
PSRs have been absolutely instrumental in advancing PHP in this direction. 
Symfony
has supported, encouraged, and implemented these PSR's - and the people 
involved
deserve a thanks for their efforts.

However, I want to confirm that Symfony would like to be removed as a 
member project.
Interoperability & standards are still as important as ever, but we believe 
that the
direction the group is taking is diverging from Symfony's interpretation of 
the
original mission statement written on the PHP-FIG's homepage:

"We're a group of established PHP projects whose goal is to talk about
commonalities between our projects and find ways we can work better 
together."

We will continue to implement the PSRs relevant for the Symfony project.

Thank you for your understanding,
Fabien

-- 
You received this message because you are subscribed to the Google Groups "PHP 
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/ba11b567-11d6-4431-ba82-9964da20ff3c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: PSR-9/10

[Fabien Potencier]

Hi all,

I would be more than happy to participate and give my insight based on 
my experience dealing with Symfony security issues and managing the 
security advisory database 
(https://github.com/FriendsOfPHP/security-advisories).


Fabien

On 26/05/2018 18:17, Michael Cullum wrote:

Hi all,

PSR-9 and PSR-10 have been quite quiet for a long time. Michael Hess 
(Drupal security lead) has stepped back from being the Editor
and has asked if I could step up as Editor. The next step is to form a 
working group. *This thread is an appeal for people who wish to*
*join the working group *so we can get the ball rolling with a 
(re)-entance vote.


What are PSR-9 and PSR-10
---

*PSR-9 is about how to inform the public of security advisories* once 
published by a project. The previous direction of this
PSR was particularly focused on standardising a machine-readable 
advisory format but there's possibility for enhanced scope within that area.


*PSR-10 is about security reporting process* including aspects of how to 
responsibly report an issue to a project, what can
be considered reasonable response and resolution times before disclosure 
by the reporter and the process of patching security issues.


You can join the working group for both or just one of two PSRs.

Who should join the Working Group?
--
We're looking for people in a few different categories:

  * Security researchers
  * Security leads of large projects, or in their absense (or lack of a
person in such a role), a suitably qualified person from that project
  * [PSR-9] People who work on security checker tooling
  * [PSR-9] Security advisory database maintainers
  * Security advocates


Who is already on the Working Group?
-
* Michael Cullum - Editor & Symfony Security Lead
* Larry Garfield - PSR-9 CC Sponsor
* Korvin Szanto - PSR-10 CC Sponsor
* Michael Hess - Drupal Security Lead
* Adam Englander

The working group are the group of people who are involved in the 
creation and core discussions for creation of the specifications,

but there's very little active work required, just your opinion.

If you think you might be able to contribute and fit with one of the 
above categories then please get in touch through this thread or if
you want to chat first, a private email or tweeting me 
(@michaelcullumuk) is also fine!


--
Thanks,
Michael Cullum

--
You received this message because you are subscribed to the Google 
Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to php-fig+unsubscr...@googlegroups.com 
.
To post to this group, send email to php-fig@googlegroups.com 
.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAAqcDMi-zm7cqAWwNWefGAvBb-j8T%3DoFrAnsTsyCd_49AJfEBQ%40mail.gmail.com 
.

For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "PHP 
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/d80eb533-8c42-bd22-5a27-2ec661dabe1e%40potencier.org.
For more options, visit https://groups.google.com/d/optout.

Re: [VOTE][CC] Entrance vote for HTTP Client

[Fabien Potencier]

+1

On 8/3/17 20:08, Cees-Jan Kiewiet wrote:

Very much +1



On Thu, Aug 3, 2017 at 6:36 PM, Korvin Szanto > wrote:


+1

Thanks!
Korvin Szanto

On Thu, Aug 3, 2017 at 9:28 AM Samantha Quiñones
> wrote:

much +1 very yusss

-- 
You received this message because you are subscribed to the

Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from
it, send an email to php-fig+unsubscr...@googlegroups.com
.
To post to this group, send email to php-fig@googlegroups.com
.
To view this discussion on the web visit

https://groups.google.com/d/msgid/php-fig/608dfbea-b47b-4004-b642-358da6656b71%40googlegroups.com

.
For more options, visit https://groups.google.com/d/optout
.

-- 
You received this message because you are subscribed to the Google

Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to php-fig+unsubscr...@googlegroups.com
.
To post to this group, send email to php-fig@googlegroups.com
.
To view this discussion on the web visit

https://groups.google.com/d/msgid/php-fig/CANeXGWW4XjPzLhwMKe2YJ-F9X2cgnuqeSe128kOKPYaPz4Rj2A%40mail.gmail.com

.

For more options, visit https://groups.google.com/d/optout
.



--
You received this message because you are subscribed to the Google 
Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to php-fig+unsubscr...@googlegroups.com 
.
To post to this group, send email to php-fig@googlegroups.com 
.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/CAPY1sU8Vd%2BmA5rnPX3vDU12fMEB6JtgZpYzC1_fr5F4P_8nTJQ%40mail.gmail.com 
.

For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "PHP 
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/1c0e9855-735f-3b4f-87d3-2074f74dabc9%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [VOTE][Accept] PSR-11 ContainerInterface

[Fabien Potencier]

+1 Symfony

On 1/31/17 07:35, Matthew Weier O'Phinney wrote:

After a couple months of review, and no additional tweaks during the
last couple weeks, we are ready to initiate an acceptance vote for
PSR-11.

Please find the specification here:

- 
https://github.com/php-fig/fig-standards/blob/c4cbf7c1ef5052e10e776381d69670beaa59beed/proposed/container.md

and the metadocument here:

- 
https://github.com/php-fig/fig-standards/blob/c4cbf7c1ef5052e10e776381d69670beaa59beed/proposed/container-meta.md

This vote falls in the tail-end of the FIG 2.0 by-laws. As such:

- We currently have 37 voting member projects, which means
- We need 13 votes to pass quorum, and
- Half or more of all votes cast must be in favor

in order for the vote to approve acceptance of PSR-11.

Voting starts now, and will run until 23:59 UTC on 13 February 2017.

On behalf of the PSR-11 team, thanks for your attention!




--
You received this message because you are subscribed to the Google Groups "PHP 
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/112f0fc6-5fc2-8a92-1348-b42ee7f78993%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [VOTE][Accept] PSR-16: Simple Cache

[Fabien Potencier]

+1 Symfony

On 12/23/16 20:42, Cees-Jan Kiewiet wrote:

+1 from ReactPHP

On Fri, Dec 23, 2016 at 4:38 PM, Leo Feyer > wrote:

+1 from Contao

--
You received this message because you are subscribed to the Google
Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to php-fig+unsubscr...@googlegroups.com
.
To post to this group, send email to php-fig@googlegroups.com
.
To view this discussion on the web visit

https://groups.google.com/d/msgid/php-fig/494056BF-4687-4BF6-9BEE-DD0812221284%40contao.org

.
For more options, visit https://groups.google.com/d/optout
.



--
You received this message because you are subscribed to the Google
Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to php-fig+unsubscr...@googlegroups.com
.
To post to this group, send email to php-fig@googlegroups.com
.
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/CAPY1sU-C9qfFcbu%3DmNZ5_0YzuVLPomc9Q2Q-7Lj%3DgXAL3wsXxw%40mail.gmail.com
.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "PHP 
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/66a68821-61f9-80c9-c2cd-f2ed33f97130%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [VOTE] First Core Committee Elections

[Fabien Potencier]

Lukas Kahwe Smith
Beau Simensen
Larry Garfield
Sara Golemon
Tobias Nyholm
Matthew Weier O’Phinney
Marc Alexander
Graham Daniels


On 12/9/16 17:46, Michael Cullum wrote:

Beau Simensen

Cees-Jan Kiewiet

Chris Tankersley

David Négrier

Gary Hockin

Graham Daniels

Jason Coward

Jeremy Coates

Korvin Szanto

Larry Garfield

Lukas Kahwe Smith

Marc Alexander

Matthew Weier O’Phinney

Michael Heap

Samantha Quiñones

Same Minée

Sara Golemon

Stefano Torresi

Steve Winter

Tobias Nyholm



--
You received this message because you are subscribed to the Google Groups "PHP 
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/7f3f94e6-d645-5a14-ccf2-676e86302f4f%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[CC][Nomination] Lukas Kahwe Smith

[Fabien Potencier]

I hereby nominate Lukas Smith for the Core Committee. Lukas has a great 
experience talking to different communities, and he was key to some 
great collaborations between PHP projects. He was also one of the people 
who helped change the PHP development process a few years back.


I'm sure he would do a wonderful job as a member of the Core Committee.

Cheers,
Fabien

--
Fabien Potencier
@blackfireio founder/CEO - https://blackfire.io/
@SensioLabs founder/CEO - https://sensiolabs.com/
@Symfony founder/project lead - https://symfony.com/

--
You received this message because you are subscribed to the Google Groups "PHP 
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/d78e07a1-2b9c-9015-ec0a-5936b5a96a07%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Comments please: Asset Scheme

[Fabien Potencier]

I'm not saying that we should not do it (and in fact, we are doing 
something similar in Symfony), just that we should mention this 
somewhere. It's important to mention any potential security issue (even 
if it is small) so that developers can take a conscious decision.


On 10/17/16 11:21, Rasmus Schultz wrote:

Er, but, even if you mangled the filenames, all anyone would need to
do is checksum the contents of the files, and  they'd known which
vendor libraries you're using, like, immediately.

There are blatantly simple ways to sniff most popular client and
server-side libraries. Hiding package names amounts to nothing more
than security by obscurity.

If you don't trust the packages you're using, or don't trust the
people using it, IMHO, you have much bigger (unrelated) problems...


On Mon, Oct 17, 2016 at 5:13 PM, Fabien Potencier
<fabien.potenc...@gmail.com> wrote:

On 10/17/16 07:54, Rasmus Schultz wrote:


Having a direct correlation between the asset paths and the package names
means that you are leaking some interesting/"sensitive" information for a
potential hacker.



How so?



If assets are under twigphp/twig or symfony/symfony, it gives information
about which stack I'm using. I'm not saying that per se, this is enough, but
it gives some interesting hints.



The only way I can see your vendor/package name as "sensitive
information", is if you have a very serious security problem somewhere
else - otherwise, exposing the vendor/package-name should not be a
concern. It's a name. It means nothing unless you exposed the vendor
folder to the public or something - in which case the problem wasn't
created here and shouldn't affect the design, IMO.


On Mon, Oct 17, 2016 at 4:11 PM, Fabien Potencier
<fabien.potenc...@gmail.com> wrote:


On 10/17/16 00:12, Rasmus Schultz wrote:



Why do you want the folder name to be named assets itself ?




The folder has to have a name - "assets" seemed like the logical choice.

Perhaps what you're really wondering is, why a single folder and not a
map like in the Aura library?

Because it's simpler. A map would require more than a standard - it
would require at least a configuration file format specification,
and/or possible a library or interfaces.

Also, because we learned from doing something similar at work, that
being able to symlink vendored asset folders into the project's public
asset folder is really useful - it enables you to run an installation
script once, and the continue to add more files to the vendor
packages, since every file in the symlinked folder becomes
automatically available.

Another reason is that a map cannot be interpreted or resolved at
design-time, by the browser - things like source-maps of relative
paths fall apart, since the relative public URLs do not map directly
to physical files. This is perhaps the main reason we came up with
this approach - anything else has proven to be highly impractical to
work with. Having to run a build or deploy script between every change
is cumbersome.

Finally, the length or appearance of asset URLs is typically
completely irrelevant - about as irrelevant as the physical
file-system structure is to Composer packages. For the most part, no
person will ever see the URL of your CSS or JS files - wanting shorter
or neater URLs is purely vanity, it has no practical consequence.
Having a simple, predictable URL structure that prevents collissions,
is much more valuable than having pretty URLs.




I disagree. I agree that nobody cares about the FS structure of the
Composer
packages; but for assets, that's a bit different, security wise. Having a
direct correlation between the asset paths and the package names means
that
you are leaking some interesting/"sensitive" information for a potential
hacker.

Fabien



Good question though, thanks for reviewing this :-)


On Mon, Oct 17, 2016 at 3:00 AM, Hari K T <kthar...@gmail.com> wrote:



Thank you Rasmus Schultz for the nice write up.

After looking at it I think, it was something similar to what we had
for
Aura  https://github.com/friendsofaura/Aura.Asset_Bundle .

I recently added psr-7 support : https://github.com/harikt/psr7-asset (
Not
saying it is perfect )

I like some of the good things you mentioned towards the end of "A
component
responsible for the delivery of vendor-supplied assets:"



https://gist.github.com/mindplay-dk/90507eb164e74bac7bbbf9abc97a04ee#12-asset-url-scheme

Also I have question :

Why do you want the folder name to be named assets itself ? ( But I do
agree
it is good to have a folder not to expose other files ;-) )

What Aura.Asset_Bundle was using was mapping the folder with the
package
path. So it don't necessary to be in vendor folder you mentioned. It
gives
flexibility for the users to choose the path for their vendor specific
css.

Eg : In our case you can alter the css / js behaviours of the
vendor/a/b
with your own if you are mapping to /web/project-s

Re: Comments please: Asset Scheme

[Fabien Potencier]

On 10/17/16 00:12, Rasmus Schultz wrote:

Why do you want the folder name to be named assets itself ?


The folder has to have a name - "assets" seemed like the logical choice.

Perhaps what you're really wondering is, why a single folder and not a
map like in the Aura library?

Because it's simpler. A map would require more than a standard - it
would require at least a configuration file format specification,
and/or possible a library or interfaces.

Also, because we learned from doing something similar at work, that
being able to symlink vendored asset folders into the project's public
asset folder is really useful - it enables you to run an installation
script once, and the continue to add more files to the vendor
packages, since every file in the symlinked folder becomes
automatically available.

Another reason is that a map cannot be interpreted or resolved at
design-time, by the browser - things like source-maps of relative
paths fall apart, since the relative public URLs do not map directly
to physical files. This is perhaps the main reason we came up with
this approach - anything else has proven to be highly impractical to
work with. Having to run a build or deploy script between every change
is cumbersome.

Finally, the length or appearance of asset URLs is typically
completely irrelevant - about as irrelevant as the physical
file-system structure is to Composer packages. For the most part, no
person will ever see the URL of your CSS or JS files - wanting shorter
or neater URLs is purely vanity, it has no practical consequence.
Having a simple, predictable URL structure that prevents collissions,
is much more valuable than having pretty URLs.


I disagree. I agree that nobody cares about the FS structure of the 
Composer packages; but for assets, that's a bit different, security 
wise. Having a direct correlation between the asset paths and the 
package names means that you are leaking some interesting/"sensitive" 
information for a potential hacker.


Fabien


Good question though, thanks for reviewing this :-)


On Mon, Oct 17, 2016 at 3:00 AM, Hari K T  wrote:

Thank you Rasmus Schultz for the nice write up.

After looking at it I think, it was something similar to what we had for
Aura  https://github.com/friendsofaura/Aura.Asset_Bundle .

I recently added psr-7 support : https://github.com/harikt/psr7-asset ( Not
saying it is perfect )

I like some of the good things you mentioned towards the end of "A component
responsible for the delivery of vendor-supplied assets:"

https://gist.github.com/mindplay-dk/90507eb164e74bac7bbbf9abc97a04ee#12-asset-url-scheme

Also I have question :

Why do you want the folder name to be named assets itself ? ( But I do agree
it is good to have a folder not to expose other files ;-) )

What Aura.Asset_Bundle was using was mapping the folder with the package
path. So it don't necessary to be in vendor folder you mentioned. It gives
flexibility for the users to choose the path for their vendor specific css.

Eg : In our case you can alter the css / js behaviours of the vendor/a/b
with your own if you are mapping to /web/project-specific-assets .

I do understand it needs some configuration though.

And thanks for bringing this up, and it will be nice feature to have for
considering psr-7, psr-15 etc.

Thank you

Hari K T

You can ring me : +91 9388 75 8821

http://harikt.com , https://github.com/harikt ,
http://www.linkedin.com/in/harikt , http://www.xing.com/profile/Hari_KT

Skype  : kthari85
Twitter : harikt

On Mon, Oct 17, 2016 at 3:10 AM, Rasmus Schultz  wrote:


The webroot folder can have any name - a folder needs to be designated, I
thought the spec was pretty clear on this point? :-)


On Oct 16, 2016 23:00, "Christopher Pitt"  wrote:


Nice write-up. Do you think it would be possible to survey member
projects (including recently departed projects, like Laravel), to determine
things like the most common/preferred name for the webroot folder?

--
You received this message because you are subscribed to a topic in the
Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/php-fig/f4qtsS54mVY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/ad00f8f7-74f3-4a00-99aa-8b0909df7fa9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups
"PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit

Re: Output escaping PSR

[Fabien Potencier]

On 10/5/16 12:17, Larry Garfield wrote:

On 10/05/2016 05:05 PM, Korvin Szanto wrote:



On Tue, Oct 4, 2016 at 4:18 PM Sara Golemon > wrote:

On Tuesday, October 4, 2016 at 9:40:03 AM UTC-7, Korvin Szanto wrote:

Are you thinking like a text filter PSR or more of an output
management PSR? It sounds like a single interface with a
single method to me: `FilterInterface::filter($mixed): mixed;`.


There's many different forms of filtering:
* Pass filtering (removing of illegal sequences)
* Replacement filtering (transformation of illegal sequences with
placeholders)
* Panic filtering (raise an exception on illegal sequences)
* Escaping (included because it's often conflated with filtering)

There are whitelist and blacklist variants of these.   There are
also context sensitive issues for many of these; What's illegal in
a JS context isn't the same as an HTML text context, or an HTML
attribute context.

I don't know that we need standards for these permutations, but I
imagine it's a little more than "single interface with a single
method".


Fair enough, until January my head is still in FIG 2.0 mode. I still
would say that the examples you provide can fit into a single
interface, but I do see that with FIG 3.0 our scope is probably a
little bit different than lowest-common-denominator interface.

@Chris I like the idea so far. Escaping is certainly an issue we've
had in concrete5 and it's something we've tried to solve in the past
with mixed results. One thing that I'd say is it that this kind of
filtering might go hand in hand with validation as well.


I'm a bit skeptical here.  Such a standard would, it seems, need to
dictate less an interface and more what happens when you want to escape
for a given context.  How would that be realistically different than a
universal implementation, which we usually try to avoid?

The audience I'd see for such a spec would be, essentially, template
engine authors.  Vis, how would you make it easy to plug a given
template engine (where escaping should happen) into an arbitrary
framework (which provides an escaper)?  Or is the escaper part of the
template engine itself, in which case it's about what the template
syntax exposes to the user, which is... not what we usually target.

(PSR-3's equivalent question was much more straightforward; make a given
library compatible with an arbitrary framework-provided logger, which
was quite successful.  I'm not clear on what the equivalent is in this
case.)

So I think the question to ask here would be: Fabien (Twig) and Taylor
(Laravel's engine): what would help you in making your template engines
more portable to other frameworks/applications in a secure fashion, if
anything?


Escaping would not make Twig more "portable" (whatever that means), 
that's for sure.


To give some feedback from a project, Twig, that has an escaping 
mechanism, you need to keep in mind that this is very performance 
sensitive as it is potentially called hundred of times in a page. So, 
this part of the code should be highly optimized (Twig only use one 
function here, no abstraction, no classes, ... and we use some "tricks" 
to make it run fast -- we do have a pull request about extracting this 
code to make it reusable but it was never merged because of performance 
concerns). So, Twig would not adopt a PSR with interfaces to implement 
output escaping.


For those interested, you can have a look at our implementation here: 
https://github.com/twigphp/Twig/blob/1.x/lib/Twig/Extension/Core.php#L977


Moreover, I don't see how such a PSR would make projects more 
interoperable. What problems are we trying to fix here?


Fabien



--Larry Garfield

--
You received this message because you are subscribed to the Google
Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to php-fig+unsubscr...@googlegroups.com
.
To post to this group, send email to php-fig@googlegroups.com
.
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/3df62d34-af9d-c6b3-5595-07fd246ac8a5%40garfieldtech.com
.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "PHP 
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/3c9fcdaf-1344-fe3d-47a8-abecf69fcaef%40gmail.com.
For more options, visit 

Re: [VOTE] PSR-6 Errata

[Fabien Potencier]

Please, offer the alternative, let's discuss and vote

Symfony will definitely vote +1 for it as we think this is VERY 
important to "fix" this.


Thanks,
Fabien

On 9/5/16 08:39, Larry Garfield wrote:

Hm.  Well, I had been planning to offer an alternate vote on using
InvalidArgumentException should the first one fail, as that was the most
likely objection.  However, if the vote didn't even meet quorum then I
don't know if it's even worth doing that.

Hopefully should FIG 3 pass the Core Committee can take up this question
more effectively, but I don't know that there's a reason to bother if
we're not even going to make quorum.

--Larry Garfield

On 09/04/2016 10:55 AM, Michael Cullum wrote:

Hi all,

Sorry we're announcing this late. It appears the secretaries google
calendar glitched and therefore neglected to notify us of the end of
the vote.

The quorum was set at 13 with a membership of 38. Therefore with only
11 voters (29%) the vote did not pass. Even if quorum had been
achieved, a majority was not.

*Full statistics:*
*
*
Number of Non-Voters27
Positive Votes  3
Negative Votes  8
Abstain Votes   0
Voters  11
Total Number of Members 38
Quorum Number   13
Quorum Met  No
Percentage Voted29%
Percentage of Voters Positive   27%
Percentage of Voters Negative   73%
Percentage of Members Voted Positive8%
Percentage of Members Voted Negative21%
Sponsor/Vote StarterLarry Garfield
Secretary/Returning Officer Michael Cullum
Finish Date 12/08/2016
Passing (Over 50% of cast votes & Quorum)   No
Over 50% of Members Voted Positive  No


A full tally is viewable on the FIG voting sheet here


--
Michael C

On 31 August 2016 at 15:52, Larry Garfield > wrote:

+1

--Larry Garfield, Drupal

(I should probably vote on my on vote, shouldn't I...)

On 08/19/2016 01:43 PM, Larry Garfield wrote:

I hereby open a vote for the following Errata for PSR-6:

https://github.com/php-fig/fig-standards/pull/787


Basically, it's a vote to merge that PR.

The vote will be open for 2 weeks, closing on 2 September 2016
@ 23:59 UTC.

As usual, the vote is open to voting representatives only and
is a simple +1/-1 vote.

I definitely appreciate the point that an
InvalidArgumentException would have been better, and had this
issue been brought up during the Review phase I'd probably
have gone that direction.  However, adding an exception does
count as an API change, albeit a small one, so I am not
comfortable with that direction in an Errata. (Obviously if
you feel that this is a bad decision, vote -1.)

--Larry Garfield


--
You received this message because you are subscribed to the Google
Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to php-fig+unsubscr...@googlegroups.com
.
To post to this group, send email to php-fig@googlegroups.com
.
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/49fbb4ed-fba8-09f1-9dbd-c084eb0bbcea%40garfieldtech.com
.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "PHP 
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/c206698f-5132-53f5-e213-2576d61579e4%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [VOTE] [Bylaw Amendment] Do not require interface suffix on future PSR Interfaces

[Fabien Potencier]

-1 Symfony

On 9/4/16 09:26, Michael Cullum wrote:

Hi all,

The PSR-11 Editors have requested we open this vote for them as they are
unable to do so not being voting members.

*Status Quo:* The bylaw states that all interfaces in PSRs published by
the PHP FIG must have the interface name suffix of 'Interface' e.g.
`LoggerInterface`
*Change:* The proposed change is that we no longer require that
interfaces are suffixed by 'Interface' so `ContainerInterface` would
become `Container`

Arguments for/against and [two
week] *discussion*: http://bit.ly/interface-suffix-discussion
*Pull request for bylaw change*: http://bit.ly/interface-suffix-pr

Note: This will only affect future PSR production (of PSRs in draft or
not yet through an entrance vote) so will not break or change any
current PSRs. It is also not a standard or recommendation for the PHP
community or member projects, but an internal bylaw on how we name
interfaces in our own interfaces in PSRs.

Voting will close in two weeks on the 18th September at 23:59 UTC.
Voting is available to voting members and may be cast as +1 (For), -1
(Against) or 0 (Abstain).

--
Many thanks,
Michael Cullum

--
You received this message because you are subscribed to the Google
Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to php-fig+unsubscr...@googlegroups.com
.
To post to this group, send email to php-fig@googlegroups.com
.
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/CAAqcDMh4JSN1Opsiam8GgjXc1vsTfSuFJ7fEJvtoRoxBxRv_xQ%40mail.gmail.com
.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "PHP 
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/aa8f-3e0e-90d5-8edf-bef24de5af5e%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [VOTE] PSR-6 Errata

[Fabien Potencier]

-1 Symfony

Triggering a E_USER_ERROR in Symfony is a no-go. We would be more than 
happy to implement the InvalidArgumentException alternative though.


On 8/19/16 11:43, Larry Garfield wrote:

I hereby open a vote for the following Errata for PSR-6:

https://github.com/php-fig/fig-standards/pull/787

Basically, it's a vote to merge that PR.

The vote will be open for 2 weeks, closing on 2 September 2016 @ 23:59 UTC.

As usual, the vote is open to voting representatives only and is a
simple +1/-1 vote.

I definitely appreciate the point that an InvalidArgumentException would
have been better, and had this issue been brought up during the Review
phase I'd probably have gone that direction.  However, adding an
exception does count as an API change, albeit a small one, so I am not
comfortable with that direction in an Errata. (Obviously if you feel
that this is a bad decision, vote -1.)

--Larry Garfield



--
You received this message because you are subscribed to the Google Groups "PHP 
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/4446f682-861a-ddef-8f02-c035407114c3%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-11] Remove ContainerException

[Fabien Potencier]

On 8/15/16 13:13, Glenn Eggleton wrote:

I believe removal of it is going to cause a lot of BC Breaks...


They can't have BC breaks on something that is not standardized yet. 
PSR-11 is still a work in progress as far as I know.



For example in Slim we do extend from *ContainerException*
*
*
[1]: 
https://github.com/slimphp/Slim/blob/3.x/Slim/Exception/ContainerException.php

We do actually use it.

https://gist.github.com/geggleto/86d039f6f4924b416e6fb1bd1538e269

Cheers

On Monday, August 15, 2016 at 3:10:07 PM UTC-4, Matthieu Napoli wrote:

Hi,

PSR-11, aka ContainerInterface, has been sleeping for too long.
Let's get that PSR moving!

Here is a change I would like to suggest: *remove the interface
ContainerException*.

After years of using container-interop and ContainerInterface I have
not seen a use case for that exception. We initially added it to
represent any exception that could happen in a container. But as far
I can I see, it's never useful, in other words it could as well be
"\Exception" and the result would be the same. Here is the original
discussion that lead to such
interface: 
https://github.com/container-interop/container-interop/issues/3#issuecomment-33133155



Here is the pull request to remove the
interface: https://github.com/php-fig/container/pull/2


Just to be clear: I am not suggesting to remove NotFoundException,
this exception is useful.

If anyone has ever seen a use case for that exception, please let me
know :)

Matthieu

--
You received this message because you are subscribed to the Google
Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to php-fig+unsubscr...@googlegroups.com
.
To post to this group, send email to php-fig@googlegroups.com
.
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/8be1eb67-6144-4e11-854c-fa3b9e501988%40googlegroups.com
.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "PHP 
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/0931d159-e45d-b50d-f3cb-3d14211994b1%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [VOTE] Membership Application: pimcore

[Fabien Potencier]

+1 Symfony

On 7/18/16 16:00, Lukas Kahwe Smith wrote:

Aloha,

So given that there didn’t see to be any opposition (then again also no support 
by-side me) for the adoption of pimcore in the original thread requesting for 
addition to the member list, I am not calling for a formal vote on the matter. 
The intended representative is Bernhard Rusch who is part of the core team.

Voting members only, just +1/-1/abstain please.

For reference here is the link to said original thread:
https://groups.google.com/d/msg/php-fig/7qcqblUe2hk/Gtl_0gG1EgAJ

regards,
Lukas Kahwe Smith
sm...@pooteeweet.org

PS: Here for quick reference the initial email:

Hi,

I would like to submit my application for membership on behalf of Pimcore.
Pimcore is an open source CMF for building highly customized websites and 
applications.

Link: http://pimcore.org/
On Github: https://github.com/pimcore/pimcore

A little bit about myself: My name is Bernhard Rusch, I'm working with PHP 
since 14 years and worked with many different products and frameworks during 
that time, mainly in the area of content management and ecommerce.
We started pimcore 6 years ago with the mission to make enterprise web content 
management easier for developers and editors.

Thank you for your consideration.

Bernhard Rusch
https://github.com/brusch





--
You received this message because you are subscribed to the Google Groups "PHP 
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/1613d262-f06f-4aa0-28b3-eee3ffa7fef9%40gmail.com.
For more options, visit https://groups.google.com/d/optout.