Re: Alternative to FIG 3.0 - Is it time to call FIG complete?

[Paul Jones]

> On Aug 29, 2016, at 17:37, Larry Garfield  wrote:
> 
> Is there a reason you excluded PSR-13, which recently entered Review stage?

My bad -- I regret the oversight.

To update the PSR listing:

"- PSR-13 has seen continuing, recent, and regular activity. As a side note, 
this too would be an excellent *-interop project."

And to update the conclusion:

"I think only 11, 13, 15, and 17 (and perhaps 12) meet that criteria; of those 
five, three are already *-interop projects, and I think would thrive even in 
the absence of the FIG. PSR-13 might or might not thrive as a *-interop; making 
it one would be a good test to see how widely it is actually needed."


-- 

Paul M. Jones
http://paul-m-jones.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/27A02924-EFB5-4FCF-B8F9-CB1046116759%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Alternative to FIG 3.0 - Is it time to call FIG complete?

[Woody Gilk]

On Mon, Aug 29, 2016 at 5:06 PM, Paul Jones  wrote:

> - The following started as PSR drafts, and have since also become
> *-interop projects.
>
> - 15 HTTP Middlewares
> - 17 HTTP Factories
>

To be clear, the reason for creating http-interop was to allow
experimentation with the draft interfaces to see if they would work in Real
World Projects. Depending on how ongoing discussions (FIG-3.0 among them)
play out, http-interop would be folded back into FIG later in the process.

--
Woody Gilk
http://about.me/shadowhand

-- 
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/CAGOJM6LRJX97XCz8a%2B1W2WRug3Afxxg%2BKu1ngyUxjdc5YpG3yw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Alternative to FIG 3.0 - Is it time to call FIG complete?

[Larry Garfield]

On 08/29/2016 05:06 PM, Paul Jones wrote:

On Aug 28, 2016, at 17:01, Christopher Pitt  wrote:


FIG has served its purpose and should be archived.

You mean aside from the ongoing PSR work? The 10 or so PSRs, approved by vote, 
to be worked on? Seems a bit premature to say FIG is purposeless and/or 
useless...

"Ongoing" is true, but fails to capture the entirety of the situation, perhaps misleadingly so. 
Let's take a look at those 10 or so PSRs, roughly from what I will call "arguably least-active" to 
"arguably most-active".

- I think we can dispense with "8 Huggable Interface" as "a funny idea at the 
time" that should probably be withdrawn without vote.

- Regarding the following PSRs, I do not recall much recent activity on this 
list; perhaps they are being actively discussed elsewhere?  Some are new; 
others are years old.

 - 5 PHPDoc Standard
 - 9 Security Advisories
 - 10 Security Reporting Process
 - 14 Event Manager
 - 16 Simple Cache

   (Incidentally, each of these seems like a very good candidate for a 
*-interop project.)

- The following started as PSR drafts, and have since also become *-interop 
projects.

 - 15 HTTP Middlewares
 - 17 HTTP Factories

- There has been a welcome surge of recent activity on "11 Container 
Interface". Interestingly enough, it is already a *-interop project.

That leaves "12 Extended Coding Style Guide". In my opinion, that ought to be 
delayed until there are more in-the-field examples to draw from. (It might or might not 
make a good *-interop project.) However, there does seem to be regular activity on this 
list regarding it.

So, to say that there is ongoing work on 10 or so PSRs is true in the sense 
that there has been activity in the past, and we may expect activity in the 
future.  But it is not true in the sense that there is continuing, recent, and 
regular (not even monthly!) activity on them all. I think only 11, 15, and 17 
(and perhaps 12) meet that criteria; of those four, three are already *-interop 
projects, and I think would thrive even in the absence of the FIG.



Is there a reason you excluded PSR-13, which recently entered Review stage?

--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/b69f5c7b-f107-df1a-e68d-43830940dec3%40garfieldtech.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-11] Remove ContainerException

[Krzysiek Piasecki]

W dniu poniedziałek, 29 sierpnia 2016 15:24:56 UTC+2 użytkownik David 
Négrier napisał:
>
> Do you mean we should rename it to something more specific, like 
> EntryNotFoundExceptionInterface?
>
>
Yes, I do.
 

> I strongly disagree with you here. Each framework has its own hierarchy of 
> exceptions. Requiring an existing framework to throw an exception provided 
> by this PSR would likely cause breaking changes in the framework. 
>
Have a look at Symfony for instance. The container has already a "has" and 
> a "get" method. Implementing PSR-11 would be a breeze (if they want to). If 
> however we require them to use a ContainerException "class" (instead of an 
> interface), that adoption could not be done before Symfony 4 (because 
> Symfony currently has its own NotFoundException and it cannot change it 
> without breaking the API).
>


No, if you provide for the consumers additional functionality with 
re-throwing non-standard exception as standard exception. Next major is 
enough and is must be in every case.

-- 
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/3cdcbafa-9d42-423a-a46e-82a0f55e8337%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Alternative to FIG 3.0 - Is it time to call FIG complete?

[Paul Jones]

> On Aug 28, 2016, at 17:01, Christopher Pitt  wrote:
> 
>> FIG has served its purpose and should be archived.
> 
> You mean aside from the ongoing PSR work? The 10 or so PSRs, approved by 
> vote, to be worked on? Seems a bit premature to say FIG is purposeless and/or 
> useless...

"Ongoing" is true, but fails to capture the entirety of the situation, perhaps 
misleadingly so. Let's take a look at those 10 or so PSRs, roughly from what I 
will call "arguably least-active" to "arguably most-active".

- I think we can dispense with "8 Huggable Interface" as "a funny idea at the 
time" that should probably be withdrawn without vote.

- Regarding the following PSRs, I do not recall much recent activity on this 
list; perhaps they are being actively discussed elsewhere?  Some are new; 
others are years old.

- 5 PHPDoc Standard
- 9 Security Advisories
- 10 Security Reporting Process
- 14 Event Manager
- 16 Simple Cache

  (Incidentally, each of these seems like a very good candidate for a *-interop 
project.)

- The following started as PSR drafts, and have since also become *-interop 
projects.

- 15 HTTP Middlewares
- 17 HTTP Factories

- There has been a welcome surge of recent activity on "11 Container 
Interface". Interestingly enough, it is already a *-interop project.

That leaves "12 Extended Coding Style Guide". In my opinion, that ought to be 
delayed until there are more in-the-field examples to draw from. (It might or 
might not make a good *-interop project.) However, there does seem to be 
regular activity on this list regarding it.

So, to say that there is ongoing work on 10 or so PSRs is true in the sense 
that there has been activity in the past, and we may expect activity in the 
future.  But it is not true in the sense that there is continuing, recent, and 
regular (not even monthly!) activity on them all. I think only 11, 15, and 17 
(and perhaps 12) meet that criteria; of those four, three are already *-interop 
projects, and I think would thrive even in the absence of the FIG.


-- 

Paul M. Jones
http://paul-m-jones.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/43FA75C2-D1CA-4107-A50F-0C60597148CD%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-11] Remove ContainerException

[Krzysiek Piasecki]

W dniu poniedziałek, 29 sierpnia 2016 15:24:56 UTC+2 użytkownik David 
Négrier napisał:
>
>
> I'm not sure I understand your comment. Do you mean we should rename it to 
> something more specific, like EntryNotFoundExceptionInterface?
>

Yes, I do. 

 

> I strongly disagree with you here. Each framework has its own hierarchy of 
> exceptions. Requiring an existing framework to throw an exception provided 
> by this PSR would likely cause breaking changes in the framework. Have a 
> look at Symfony for instance. The container has already a "has" and a "get" 
> method. Implementing PSR-11 would be a breeze (if they want to). If however 
> we require them to use a ContainerException "class" (instead of an 
> interface), that adoption could not be done before Symfony 4 (because 
> Symfony currently has its own NotFoundException and it cannot change it 
> without breaking the API).
>
>
I think, there is a possibility to re-throw an exception in PSR wrapper 
without breaking API. Next minor as a new functionality is enough.


Best regards,
Krzysiek.

-- 
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/89928e00-d6d3-4cd4-9731-f90b49cebe59%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Google Group Closed?

[Samantha Quiñones]

It seems to have happened all on its own. It came back while I was clicking 
through settings screens, though, so it's possible I unknowingly smacked 
the jukebox in just the right spot. ¯\_(ツ)_/¯

--Samantha

On Monday, August 29, 2016 at 2:04:01 PM UTC-4, pmjones wrote:
>
>
> Excellent. Was a switch flipped somewhere, or did it just disappear and 
> reappear on its own? 
>
>

-- 
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/6c35c5bc-4999-404b-9dbc-10f94dac2670%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Google Group Closed?

[Paul Jones]

> On Aug 29, 2016, at 12:57, Samantha Quiñones  wrote:
> 
> Seems to be in order now! :)

Excellent. Was a switch flipped somewhere, or did it just disappear and 
reappear on its own?


-- 

Paul M. Jones
http://paul-m-jones.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/EA237A9C-D57B-450E-A883-700F786401E8%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Google Group Closed?

[Paul Jones]

All,

I saw on Reddit that the Google Group appears to be closed; I signed out of 
Google and went to the mailing list page at 
https://groups.google.com/forum/#!forum/php-fig and I get a "permission denied."

Has anything been changed lately?


-- 

Paul M. Jones
http://paul-m-jones.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/FBE997C9-97E1-4EAD-9996-83ECB4D2A9EA%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Alternative to FIG 3.0 - Is it time to call FIG complete?

[Lukas Kahwe Smith]

tl;dr

the bulk of the community doesn’t care about our by-laws, they are about PSRs, 
so to the community “disbanding” FIG will just be confusion about why suddenly 
PSRs would live on another site/github repo ..

> A clean slate. Green fields. Adopt the the work that FIG has completed and 
> start fresh with fresh and old faces with a new mission statement. FIG 3.0 is 
> a major refactor where the points I've tried to make in this thread are 1: 
> Maybe it's time to call FIG complete and 2: FIG is still active, but the work 
> it's doing doesn't really seem to fit the "Framework" portion of the mission. 
> 3: A new organization solves many problems.


"it's time to call FIG complete"

actually I very much disagree. saying this would imply that there isn’t 
anything that could sensibly be done based on the old mission statement, let 
alone any new mission statement.

also from the “community” perspective the difference between FIG 1.0, 2.0 and 
3.0 don’t matter much. the evolution away from "just” framework to more was one 
driven by the community more so than by us I would say. as such arguing that 
3.0 is for some reason a too big a change seems entirely arbitrary and will 
lead to confusion in the community which will affect thousands of developers.

the issues regarding the definition of who we are and how to proceed are, if 
they are even so fundamental, only on this mailing list and maybe some reddit 
threads. but the general community isn’t pondering our mission statements, they 
are looking at the PSRs that come out and not how they were crafted.

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/C3C4EED8-3109-4FE8-819D-B868D3C66B83%40pooteeweet.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Review][Discuss] FIG 3.0 Upcoming Vote

[GeeH]

I have a few points I'd like to raise here - thanks to all involved in pull 
vote this time around. Obviously, all of the below comments are my 
opinions, and should be taken as such.


## Mission Statement


I really dislike it. I would prefer something short and catchy than this 
statement which I think is woolly and doesn't really tell anyone anything. 
I would prefer something like "Promoting good standards in PHP", something 
short that immediately tells people what this new FIG is about, rather than 
I don't think the mission statement needs to worry about how the mission is 
achieved (others will disagree here, and that's fine). This is the kind of 
overwritten statement I've come to hate.


## Secretaries


- Acting throughout their term essentially as Developer Advocates for the 
PHP FIG 
I believe the this is out of the scope of a secretary of the FIG, and 
should be removed, I see no need for a competent secretary to submit talks 
on the FIG, blog about it, or promote it in any way.

I would also like to see some accountability added into the secretaries 
role so that phrases like "we have been dealing with this behind the 
scenes" become a thing of the past. I'd like to see publically visible 
records of email chains sent by the secretaries on behalf of the FIG, and 
records of other conversations. While this may seem like we are not 
trusting the secretaries, it's certainly not a matter of trust for me. It's 
a case of everyone being able to see exactly what is going on, so efforts 
are not duplicated, and surprises are never seen when discussions are 
raised on this list. If secretaries are having discussions on the 
interpretation of a bylaw, for example, that discussion should be visible 
to the members they represent in my opinon.


## Working Groups
### Sponsors
"A PSR must be sponsored by a member of the Core Committee."
Why? Only 12 people can be sponsors of PSRs? Why can't member projects 
sponsor PSRs anymore? I don't understand what this brings to the table 
apart from shrinking the pool of people who may sponsor a PSR.

## Votes
"A secretary may trigger any type of vote if appropriate and necessary."
I disagree, only Core Committee members and Project Representatives should 
be able to call a vote after the mandatory discussion period. I would like 
to see all votes have a mandatory two week minimum discussion period marked 
with a set titled thread such as [Discussion].


Overall
I'm undecided, this still doesn't feel like a great idea to me, but I have 
nothing better to offer and accept that something needs to change. I'm 
particularly worried about the Core Committee, basically, the 12 most 
popular people will be voted into a position of power in the FIG, and under 
the current implementation, only those 12 will be able to sponsor a PSR. 
This feels confusing to me. It also feels that the member projects take a 
big back-seat role then, only able to vote in secretaries and core 
committee members. Of course, this doesn't preclude them from being 
involved in working groups at all, but really their job is only to decide 
who staffs the various roles if I'm reading this right (on second reading, 
that might be a good thing). I also think that two years seems like a hell 
of a long period for someone to be voted onto the core committee - I would 
prefer to see this reduced to a maximum of one year. 

I may have missed it, but there doesn't appear to be anywhere that 
regulates the location that working groups should have discussions. I'm all 
for letting the working groups have their own communication methods, but it 
should be public and have a historical record somewhere for everyone to 
read. It should also be made clear where discussions take place on the 
website (or in the README of the PSR) so finding these places are easy, and 
anyone can later read what discussion happened. Let's take this opportunity 
to get more transparency all around.

Kudos to Larry and Michael for all the hard work you both did in getting 
this to the table.

-- 
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/a751d941-2d94-454b-af7a-f3bad9df92eb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [VOTE] PSR-6 Errata

[Korvin Szanto]

+1 concrete5

On Sat, Aug 27, 2016 at 5:31 PM Chuck Burgess  wrote:

> -1 from PEAR
>
> CRB
> *about.me/ashnazg *
>
> On Mon, Aug 22, 2016 at 10:43 AM, Fabien Potencier <
> fabien.potenc...@gmail.com> wrote:
>
>> On 8/22/16 00:09, Lukas Kahwe Smith wrote:
>>
>>> -1 from Jackalope
>>>
>>> not sure here what to do .. feels a bit like a precedent .. its a clear
>>> omission, yet any fix is a BC break (classic bug fix is kinda always a BC
>>> break). so if we do a BC break, then rather the exception .. if we don’t
>>> want to break BC, we release a new PSR with this fix (since just versioning
>>> the PSR to 6.1 isn’t’ semver for a BC break)?
>>>
>>
>> I think we need to see what current implementations do. From what I
>> understand reading the code:
>>
>> * Stash already throws an InvalidArgumentException (467 981 Packagist
>> installs)
>> * Symfony already throws an InvalidArgumentException (48 233 Packagist
>> installs)
>> * php-cache injects the value without any check (43 786 Packagist
>> installs)
>>
>> That's for the implementations with the most installations on Packagist.
>> Having a look at the other implementations, most of them do like php-cache.
>>
>> So, as most of (2 is probably not significant but Stash has many
>> installs) the "major" implementations already throws an
>> InvalidArgumentException, why not just document that in PSR-6? I understand
>> the BC break and all, but can't we be a bit pragmatic here (or is it just a
>> classic French/latin way of thinking)?
>>
>> Fabien
>>
>> On 19 Aug 2016, at 20: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/e9508662-70c7-e91a-05ff-82c8dfb59884%40garfieldtech.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/d039869b-f515-f0d9-e2d4-89802a533a5d%40gmail.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/CANsgjnu3dMBPxRj4V1a-JgPz9QJwAr-iO868TpOgH4jS4fMP%2Bg%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/CANeXGWWK5ULxWsENzP2SnfEzPZGJT0HH6%2BHCZ6nqpTRZU-kVxQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Alternative to FIG 3.0 - Is it time to call FIG complete?

[Korvin Szanto]

On Mon, Aug 29, 2016 at 8:06 AM Joe Ferguson  wrote:

> For another group to be successful I believe FIG would have to close up
> shop. Disband sounds like the wrong word to me. I do like "Archive" that
> Woody mentioned previously.
>
> A potential new organization road map for what FIG may need to do & what a
> new organization would need to do:
>
> FIG's agenda:
>
> * Formal 2 week discussion to discuss the following points:
> * Do voting reps want to close up / disband / archive FIG? - If Yes,
> continue
> * Allow transfer of all in progress work to any new organization that
> is willing to pick it up
> * Set end date for FIG (~4-6 weeks after passing vote closes)
> * End date allows time for any formal last minute business & lead time
> for new organization.
> * Stop opening votes for FIG members to vote on (So that this vote is the
> last closed vote)
> * Open 2 week voting period
>
>
> New Org Agenda:
>
> * Get your ducks in a row asap
> * Write your bylaws / Figure out who and how your membership works
> * Formally declare your intentions to FIG voting members
> * Start talking to everyone currently working on in progress work and
> inform them of your intentions
>
>
I just don't see why this is at all necessary, what does this get us other
than a new name? To me it seems like this is just a semantic runaround for
what old fig will be once fig 3.0 passes. IMO once FIG 3.0 is around for a
little bit of time, FIG 2.0 will become just a slide on someones
presentation and that's all. What does it matter if that slide says "Gone:
Disbanded then remade into FIG 3.0" vs "Gone: Reformed as FIG 3.0"?


>
> IMHO a competing organization to FIG would struggle. I feel like the best
> path forward in this scenario *requires* FIG to no longer be active.
>
>
Definitely agree here, FIG is not much without the people that make it
happen and those people need whatever extra time they have to be devoted to
the most current organization instead of being split unnecessarily.


> --
> 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/d0b62cfa-ceda-44bf-8da3-a1c30794ee6a%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/CANeXGWWG75xUBTUhwMifyakuBr29u-KK9UmU0aYowSorWQWqNQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Alternative to FIG 3.0 - Is it time to call FIG complete?

[Joe Ferguson]

For another group to be successful I believe FIG would have to close up 
shop. Disband sounds like the wrong word to me. I do like "Archive" that 
Woody mentioned previously.

A potential new organization road map for what FIG may need to do & what a 
new organization would need to do:

FIG's agenda:

* Formal 2 week discussion to discuss the following points:
* Do voting reps want to close up / disband / archive FIG? - If Yes, 
continue
* Allow transfer of all in progress work to any new organization that 
is willing to pick it up
* Set end date for FIG (~4-6 weeks after passing vote closes)
* End date allows time for any formal last minute business & lead time 
for new organization.
* Stop opening votes for FIG members to vote on (So that this vote is the 
last closed vote)
* Open 2 week voting period


New Org Agenda:

* Get your ducks in a row asap
* Write your bylaws / Figure out who and how your membership works
* Formally declare your intentions to FIG voting members
* Start talking to everyone currently working on in progress work and 
inform them of your intentions


IMHO a competing organization to FIG would struggle. I feel like the best 
path forward in this scenario *requires* FIG to no longer be active.

-- 
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/d0b62cfa-ceda-44bf-8da3-a1c30794ee6a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Alternative to FIG 3.0: Encourage *-interop projects

[FGM at GMail]

Chiming in on the "no legal entity". I'm not sure of which legal system is
involved here and what its limitations are, but in french law, for
instances, FIG would be an "association de fait" (de facto association),
with limited legal capability, but existing nonetheless and able to act in
some ways.

2016-08-26 15:52 GMT+02:00 Larry Garfield :

> It's not that we're transferring copyright ownership to FIG, as FIG isn't
> a legal entity.  It's that by working on it under the FIG umbrella, it's
> clearer that contributors are individually offering whatever they're doing
> under MIT, as opposed to something else or not at all.  There's no transfer
> of ownership, just a clarity about the license used by the individual
> contributors collectively.
>
> --Larry Garfield
>
> On 08/26/2016 08:47 AM, Keith Casey wrote:
>
>
> On Thursday, August 25, 2016 at 1:11:04 PM UTC-5, Larry Garfield wrote:
>>
>> It's not that FIG needs to own the code per se; strictly speaking there
>> is no legal entity called FIG, so it cannot own copyright on anything.
>>
>
> Then you're assigning copyright to an entity that have standing or process
> for determining who can represent it where and how? Sounds like that's a
> bigger problem to solve first.
>
>
>
>> However, bear in mind that under copyright law you own any non-trivial
>> work you produce immediately upon doing so, and no one else has any legal
>> right to copy it, much less use it, without your explicit consent (modulo
>> fair use).
>>
>
> Adding a license - any license - governs the terms of contribution, usage,
> etc, which the MIT (or BSD or Apache) covers as is.
>
> The "entity" only has to own the copyright if there's a need to relicense
> it or transfer ownership later and you don't want to contact all the
> contributors. Are you planning to transfer ownership?
>
>
> * I ran a GPL->BSD relicense a few years back after forking a project:
> http://web2project.net/2011/01/web2project-license-change/ and worked
> through all the details with extensive legal and technical advise.
>
> keith
> --
> 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/760607af-4fef-427f-afd7-6d17bd1d9e85%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/7975ecaf-b65d-86c4-7ba5-9bac90ed3163%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/CANqRZ1MRnVGLkOhZexkjkXGMnVhayKZB0q9fb%3D4yH%2B2TnqRs2g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PSR-11] Remove ContainerException

[David Négrier]

Hey Krzysiek!


>
> 1. ContainerException
>
> - One interface to represents a runtime and logic exceptions so at the end 
> we should always base on the implementation. - No clear context. - Enforces 
> exception implementation.
>
>
I do agree that the fact that the ContainerExceptionInterface can be 
implemented by both runtime and logic exception makes it very impractical 
to use. I think everybody here agrees with this point of view (even the 
proponents for keeping this interface). I you read carefully Matthew's 
mail, his point is that the exception could be used for some reporting 
tools (like Zend's Z-Ray or Blackfire). He would like to keep the exception 
in place for these use cases.

 

>
> 2. NotFoundException
>
> - Not found what? Container was not found? - No clear context.
>
>
The current PSR draft is quite clear:

A call to the get method with a non-existing id MUST throw a 
Psr\Container\Exception\NotFoundExceptionInterface 

.

I'm not sure I understand your comment. Do you mean we should rename it to 
something more specific, like EntryNotFoundExceptionInterface?

 

>
> The whole idea to use interfaces with exceptions to mark 'something' is 
> totally impractical. If we think that something is very important we should 
> provide the exception classes derived from standard exception hierarchy, 
> just like we do providing PSR interfaces, because classes are just 
> interfaces.
>
>
I strongly disagree with you here. Each framework has its own hierarchy of 
exceptions. Requiring an existing framework to throw an exception provided 
by this PSR would likely cause breaking changes in the framework. Have a 
look at Symfony for instance. The container has already a "has" and a "get" 
method. Implementing PSR-11 would be a breeze (if they want to). If however 
we require them to use a ContainerException "class" (instead of an 
interface), that adoption could not be done before Symfony 4 (because 
Symfony currently has its own NotFoundException and it cannot change it 
without breaking the API).


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/cef2ebf6-8d01-4417-98c1-2f8508370644%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Review][Discuss] FIG 3.0 Upcoming Vote

[Michael Cullum]

Paul,

The intention of the vote is that it will resolve contention, not create
it; and this should be the case so long as people don't intend to create
drama as a result of the vote. Right now there is contention of ideas as to
what the FIG is about and FIG 3.0 is a proposal to resolve that, as are
other proposals. It is up to the member projects to decide if they wish the
FIG to transition into FIG 3.0 or not. If the vote fails, then voting
members will have spoken they do not wish the FIG to transition into FIG
3.0 and would prefer other options (dropping the idea of any change all
together, FIG 3.0 in it's own organisation in a similar or different manner
to that which you suggest). On the other hand, if it passes, then member
projects will have decided that they would prefer the FIG to transition.

It is not up to you, Larry, myself or any other single individual to define
what the FIG 'is' or 'should be' or 'is not'. It is up to the member
projects to decide by majority vote, as is our way.

--
Michael C

On 28 August 2016 at 22:07, Paul Jones  wrote:

>
> > On Aug 24, 2016, at 00:13, Michael Cullum  wrote:
> >
> > Hi all,
> >
> > I pulled the vote for FIG 3.0 in order to give people a chance to
> provide more feedback as people expressed a wish to give it a bit more
> time. The vote will open on the 10th September.
>
> I'll say it again: this proposal is effectively a re-constitution of the
> FIG, and is better suited to an entirely new organization.
>
> Further, this vote leads in only one direction: more contention. Whether
> it passes or fails, the different sets of vision holders will continue to
> champion their opposing causes.
>
> If the vote fails, the "grand" vision holders will continue to try to pass
> it in other ways. If it passes, the "founding" vision holders will try to
> roll it back. (Indeed, I am interested in rolling back some of the more
> recent changes, such as the over-empowering of secretaries, if not the
> position itself.)
>
> One way out of this contention is for one of visions is explicitly and
> permanently retract itself. But neither do I expect to retract the
> "founding" vision, nor do I expect Larry & Michael (et al.) to retract the
> "grand" vision. (If they do, so much the better for the group and its
> way-of-working.)
>
> The only other way out is for the group to dissolve, its mission being
> largely accomplished, and now experiencing scope-creep. Disband the group;
> let there be an archivist appointed to safeguard the FIG name and the
> finished PSRs; encourage *-interop projects to form in the FIG's place; and
> if Larry & Michael (et al.) wish to start a new group based on FIG 3.0,
> they can do so without a pre-existing FIG as competition.
>
>
> --
>
> Paul M. Jones
> http://paul-m-jones.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/569E1E9F-C321-4F55-B063-9BE28F6628FE%40gmail.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/CAAqcDMjN%3DrHT2gXTb34HUk799zDiZ5sb61ARoc00_k0Y8mAd-w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.