Re: [Internals][FIG 3.0] Extending Nomination Period & Delaying FIG 3.0 Transition

[Paul Dragoonis]

Hi Michael,

I am happy with this. I think it is the right call to make.

Many thanks,
Paul

On 9 Nov 2016 17:09, "Michael Cullum"  wrote:

Hi all,

Does anyone have any objections to extending the Core Committee nomination
period one month and pushing the FIG 3.0 implementation timetable back a
month (so the new implementation date will be 1st February)?

There are still a number of people looking to be nominated or considering
standing; meanwhile right now we only have 7 candidates when 15-20 would be
a much more appropriate number for a fair election and we think at least 12
at a minimum is still achievable if given a little more time.

--
FIG Secretaries

-- 
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/CAAqcDMhSgM3qMZAnV9674xuLuLF3YQtx_otOv53ANJHsk%2Bq%2B7Q%
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/CAKxcST8%2BvEMBw2_Xm__MB0cEFDtm9t-D3HDrDbvN5BX9J_Fg7Q%40mail.gmail.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: [CC][Nomination] David Négrier

[David Négrier]

Woot! Thanks a lot Michiel. I obviously accept your nomination. :)

--
David.

Le mercredi 9 novembre 2016 20:43:01 UTC+1, Michiel Rook a écrit :
>
> I hereby nominate David Négrier for the Core Committee!
>
> Michiel
>

-- 
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/30176e6e-ef1e-48e9-871d-6e2cf7ae4498%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[CC][Nomination] David Négrier

[Michiel Rook]

I hereby nominate David Négrier for the Core Committee!

Michiel

--
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/ccd2dfc7-c35e-f0f4-fa71-e92fefd6884b%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [CC][Nomination] Matthew O'Phinney

[Michael Cullum]

Thanks Larry & Matthew. Recieved.

http://bit.ly/cc-election-candidates

--
Michael C

On 8 November 2016 at 17:38, Matthew Weier O'Phinney <
mweierophin...@gmail.com> wrote:

> On Nov 8, 2016 4:33 PM, "Larry Garfield"  wrote:
> >
> > Since no one else seems to be doing so, I'll go ahead and do it. :-)
> >
> > I hereby nominate Matthew "MWOP" O'Phinney for the Core Committee. His
> reputation, skill, and existing and ongoing contributions to FIG should
> speak for themselves and require no further explanation.
>
> Thank you for the kind words, Larry!
>
> I humbly accept!
>
> --
> 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/CAJp_myWpPAynOStceSFNbXEgLejG9LLoqo
> uPFHOjOaqNCo8SWw%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/CAAqcDMgyMRso2hWCht4-qtmE0HOq%2BuGmmFmMpcsGkb2E6-MOmw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Internals][FIG 3.0] Extending Nomination Period & Delaying FIG 3.0 Transition

[Michael Cullum]

Answering this required me working backwards so I just did the full
timetable. The new FIG 3.0 transition timetable would be as follows:

1st November: CC Nominations open
*7th December: CC Nominations close* (Initial nominations, people can
accept nominations after this so long as voting hasn't started)
*9th December: CC Election voting begins*
*23rd December: CC voting ends*
24th December: CC results announced
25th December: CC takes post
16th January: Recommended date for PSRs to have working groups fully formed
with a CC sponsor
17th January: Latest date for any FIG 2.0 votes to start except acceptance
votes
17th January: Latest date for any PSRs to enter review under the old system
31st January: Latest date for any PSRs to start approval votes under the
old system
31st January: Final deadline for PSRs to have full working groups formed
with a CC sponsor
*1st February: All votes and actions take place under new system; full
transition*
14th February: Latest possible date for any FIG 2.0 approval votes to have
finished by
28th February: Deadline for any PSRs which entered review before the 17th
December to form a Working Group with a CC sponsor if they failed their
approval vote/didn’t get to their approval vote in time
May 2017: Next Secretary and CC election

--
Michael C

On 9 November 2016 at 12:53, Larry Garfield  wrote:

> Under the circumstances, I do not object.  What end-date are you proposing
> for nominations?  Early December?
>
> --Larry Garfield
>
>
> On 11/09/2016 11:08 AM, Michael Cullum wrote:
>
> Hi all,
>
> Does anyone have any objections to extending the Core Committee nomination
> period one month and pushing the FIG 3.0 implementation timetable back a
> month (so the new implementation date will be 1st February)?
>
> There are still a number of people looking to be nominated or considering
> standing; meanwhile right now we only have 7 candidates when 15-20 would be
> a much more appropriate number for a fair election and we think at least 12
> at a minimum is still achievable if given a little more time.
>
> --
> FIG Secretaries
> --
> 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/CAAqcDMhSgM3qMZAnV9674xuLuLF3YQtx_otOv53ANJHsk%2Bq%2B7Q%
> 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/bf316ec9-a158-a358-b310-5ba364a17add%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/CAAqcDMhOwpMH%3D%3Di5Az41Y_UQhA-so_02k6z2sF6DDjZMAW6a4A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [VOTE][Accept] PSR-13: Link Definition Interfaces

[Lukas Kahwe Smith]

+1 from Jackalope

> On 31 Oct 2016, at 22:15, Matthew Weier O'Phinney  
> wrote:
> 
> Per the by-laws, the required review period has passed for the
> proposed standard PSR-13 (Link Definition Interfaces). No changes have
> been made in the past two weeks since re-opening the review period.
> 
> The specification is here:
> 
> - 
> https://github.com/php-fig/fig-standards/blob/a47c644f9d0f914bb0a9777eeaec157f2d51dbff/proposed/links.md
> 
> And the meta document is here:
> 
> - 
> https://github.com/php-fig/fig-standards/blob/a47c644f9d0f914bb0a9777eeaec157f2d51dbff/proposed/links-meta.md
> 
> As coordinator, as of 21:20 UTC, I hereby open voting to accept the
> proposed standard.
> 
> There are currently 37 voting member projects, which means we must
> have 13 votes to pass quorum, with half or more of all votes cast in
> favor, in order to approve acceptance of PSR-13.
> 
> --
> Matthew Weier O'Phinney
> mweierophin...@gmail.com
> https://mwop.net/
> 
> --
> 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/CAJp_myXK4gb9b4%2Bph4Oac979bW0RpCDy5HbC4e70ght5xeeFcQ%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

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



-- 
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/DC6E2549-DF68-4420-BCD8-2A153AF965CF%40pooteeweet.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Internals][FIG 3.0] Extending Nomination Period & Delaying FIG 3.0 Transition

[Korvin Szanto]

We definitely need to delay this. Thank you for raising the issue Michael
and Roman.

On Wed, Nov 9, 2016 at 9:53 AM Larry Garfield 
wrote:

> Under the circumstances, I do not object.  What end-date are you proposing
> for nominations?  Early December?
>
> --Larry Garfield
>
>
> On 11/09/2016 11:08 AM, Michael Cullum wrote:
>
> Hi all,
>
> Does anyone have any objections to extending the Core Committee nomination
> period one month and pushing the FIG 3.0 implementation timetable back a
> month (so the new implementation date will be 1st February)?
>
> There are still a number of people looking to be nominated or considering
> standing; meanwhile right now we only have 7 candidates when 15-20 would be
> a much more appropriate number for a fair election and we think at least 12
> at a minimum is still achievable if given a little more time.
>
> --
> FIG Secretaries
> --
> 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/CAAqcDMhSgM3qMZAnV9674xuLuLF3YQtx_otOv53ANJHsk%2Bq%2B7Q%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/bf316ec9-a158-a358-b310-5ba364a17add%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/CANeXGWUZs0VOFZ4pcSXtqvecKtFGYM5s4Ku0KtKC_Jw808oBgg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Internals][FIG 3.0] Extending Nomination Period & Delaying FIG 3.0 Transition

[Chuck Burgess]

No objection from PEAR...
CRB

On Nov 9, 2016 11:09 AM, "Michael Cullum"  wrote:

> Hi all,
>
> Does anyone have any objections to extending the Core Committee nomination
> period one month and pushing the FIG 3.0 implementation timetable back a
> month (so the new implementation date will be 1st February)?
>
> There are still a number of people looking to be nominated or considering
> standing; meanwhile right now we only have 7 candidates when 15-20 would be
> a much more appropriate number for a fair election and we think at least 12
> at a minimum is still achievable if given a little more time.
>
> --
> FIG Secretaries
>
> --
> 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/CAAqcDMhSgM3qMZAnV9674xuLuLF3YQtx_otOv53ANJHsk%2Bq%2B7Q%
> 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/CANsgjnstqpiZt71XFw-JFSJ9SSXqCdEjTkjfUL7B8apVLGY0JQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Internals][FIG 3.0] Extending Nomination Period & Delaying FIG 3.0 Transition

[David Négrier]

Hi Michael,

The PHP-FIG Core Commitee deserves to have the best members we can find. 
The 10 days timeline was certainly too short and if we need to choose 
between the respecting the fixed timeline or giving us more time to find 
the best people, I'm definitely for the later solution.

I'm not a voting member but I'm +1 on extending the Core Committee 
nomination period.

--
David.



Le mercredi 9 novembre 2016 18:09:44 UTC+1, Michael Cullum a écrit :
>
> Hi all,
>
> Does anyone have any objections to extending the Core Committee nomination 
> period one month and pushing the FIG 3.0 implementation timetable back a 
> month (so the new implementation date will be 1st February)?
>
> There are still a number of people looking to be nominated or considering 
> standing; meanwhile right now we only have 7 candidates when 15-20 would be 
> a much more appropriate number for a fair election and we think at least 12 
> at a minimum is still achievable if given a little more time.
>
> --
> FIG Secretaries
>

-- 
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/a45013d0-7c30-4cfc-906d-26a6921a82f8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[CC Nomination Request] David Négrier

[David Négrier]

To all FIG project representatives:

I'm writing to the list today to request a nomination to the FIG 3.0 Core 
Committee.

If you read this list regularly, you probably already know me as the 
co-editor of PSR-11 and container-interop. I'm also the lead developer of 
Mouf  (a graphical DI framework) and Packanalyst 
 (the search engine that let's you find all 
classes implementing a given interface). Being a "small framework" author, 
I grew pretty fond of PHP-FIG as I see in its mission a great way to rely 
on others code without "vendor lock-in". I'm pretty sure the PHP-FIG is 
going in the right direction with FIG 3.0 as working groups are quite close 
to what we did with container-interop (test first, grow a user base, then 
standardize).

Just like Jason, I am asking for this nomination through the mailing list 
as I do not have a lot of strong personal relationships with any other FIG 
members at this time (even if I have interacted with many of you in the 
past months). I used to speak a lot with Beau, but he left the group a year 
ago. Also, to be honest, I probably would not ask for a nomination if there 
were dozens of framework leaders applying for the CC (that would really be 
the ideal situation for PHP-FIG). But there are currently some free seats 
at the table, so here I am! Any member project would be kind enough to 
endorse me? :)

Best regards,
David.

-- 
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/fe46aecc-4840-4a1c-88fb-92351aad5e3e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-11] Review: should the container ALWAYS return the same instance?

[Pedro Cordeiro]

Hi, Matthew! Thanks for replying :)

Larry and I presented a few cases where the framework relies on its 
components having a shared instance, instead of exclusive ones. Every 
framework component that fetches services that handles connections, IO 
sockets, in-memory caches, and others HAVE to be given shared instances. 
Being fed new (empty) in-memory caches every time is crazy, right? :) If 
you could address how we can deal with these cases with factory-only 
containers, maybe it could be clearer to me.

I don't really agree that most services are only fetched once by the 
framework -- an event dispatcher (that traditionally has an in-memory 
registry of listeners that must be shared) could be fetched various times 
by various different components - to register new listeners or to simply 
dispatch events. It would depend on the framework here. Maybe a 
microframework tends to fetch less, but a fullstack framework could really 
differ in that aspect.

Like I said before, I would agree that it's an application/configuration 
issue if all containers were interoperable on a behavior level. If the user 
had misconfigured a container to act as factory for a specific service, 
where it should be retrieving shared instances, ok, that's a bug, not this 
PSR's fault. However, once we decide to allow factory-only containers, we 
define that there is no way to configure these containers properly for 
components that need shared instances (such as the ones I mentioned 
previously). Hence, we have a compatibility issue.

Again, choosing the right containers for my use is not a 
configuration/application issue. PSR-11's goal SHOULD be container 
interoperability. Which means containers should agree on a minimum behavior 
to be interoperable. If we need to code to specific implementations, than a 
standard is not needed at all.

I won't dwell any more into this issue, because I feel like I'm bashing the 
same key over and over again. I feel like I've said all I had to say in 
that aspect, and I only have the best intentions in mind for this PSR. If 
you all feel like it's not a big issue, then let's move on. I do feel like 
it's a big issue, though.

Em terça-feira, 8 de novembro de 2016 17:54:08 UTC-2, Matthew Weier 
O'Phinney escreveu:
>
>
>
> On Tue, Nov 8, 2016 at 6:55 AM, Pedro Cordeiro  > wrote:
>
>> Hi, Matthew!
>>
>> I understand everything you said. About the configuration responsibility, 
>> this PSR's scope and the fact that it's coherent to have non-shared 
>> services in some contexts. I never disagreed with any of that.
>>
>> I'll try to be more objective here.
>>
>> Given two containers: 
>>
>> a) "ContainerShared", that implements PSR-11 and ONLY returns shared 
>> instances, no option to configure non-shared services;
>> b) "ContainerFactory", that implements PSR-11 and ONLY returns non-shared 
>> instances, acts as a factory always.
>>
>> Do you agree that:
>>
>> 1) These implementations are perfectly fine PSR-11 implementations, as 
>> it's phrased right now?
>> 2) These implementations are incompatible between themselves for pretty 
>> much every use case, including zend-expressive, that is currently the most 
>> successful case of container interoperability?
>> 3) The incompatibility between these two containers is not an 
>> application/configuration issue, but plain lack of interoperability between 
>> them?
>>
>> If you agree with (1), (2) and (3), the final question that stands is: is 
>> it still OK to have container implementations that are NOT interoperable 
>> implementing an interoperability standard?
>>
>
> I don't agree with your assessment at all.
>
> I agree with point 1. I don't agree with either point 2 or point 3.
>
> In the majority of use cases I've encountered, the workflow goes something 
> like this:
>
> - Application composes a container.
> - Application does some sort of request routing to determine what service 
> to dispatch
> - Application pulls that service from the container and dispatches it
>
> This means that, regarding point 2, whether or not instances are shared is 
> typically moot. They are pulled from the container generally once, and once 
> only, in any given request. (Yes, there are times when multiple retrieval 
> may happen, particularly in large, event-based applications where multiple 
> listeners may use the same services.)
>
> However, this leads to point 3: it's absolutely an 
> application/configuration issue. You need to choose the container that 
> suits your application needs and configure it accordingly. The PSR-11 
> specification is only around *retrieving* services. It is specifically not 
> detailing how those services are stored within, whether or not the service 
> MUST return the same instance, etc. The point is that if you have a 
> container, can you (a) test if the service is present, and then (b) 
> retrieve it?
>
> The *behavior* aspect — if the service is shared or not, and how to 
> configure services in