Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures

[Larry Garfield]

On Fri, May 12, 2023, at 9:59 PM, Rowan Tommins wrote:
> On 12 May 2023 19:17:20 BST, "Máté Kocsis"  wrote:
>>Libraries have to
>>get rid of deprecated calls in any case, otherwise
>>their users will surely start to complain. 
>
> I've said it before, and I'll say it again: the solution to this is not 
> fewer deprecation messages; it's better documentation to stop people 
> confusing deprecations for errors, and better functionality for users 
> to choose which messages they see.

A better argument, I think:

The old function exists in 8.2, the new one does not.
The new one exists in 8.3.
The old one ceases to exist in 9.0.

That means it's impossible to write code that works from 8.2 to 9.0 without 
version checks.  The overlap period is only 2 releases (8.3 and 8.4).  That's 
too short of a window.

That's mitigated by these all being very uncommon cases, yes, but as a 
principle we should give people more warning than that.

I am actually tempted to propose that we do deprecations at the very start of a 
release, 9.0 and 9.1 only, and then not allow them for the rest of that major, 
for that exact reason.

--Larry Garfield

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures

[Rowan Tommins]

On 12 May 2023 19:17:20 BST, "Máté Kocsis"  wrote:
>Libraries have to
>get rid of deprecated calls in any case, otherwise
>their users will surely start to complain. 

I've said it before, and I'll say it again: the solution to this is not fewer 
deprecation messages; it's better documentation to stop people confusing 
deprecations for errors, and better functionality for users to choose which 
messages they see.


-- 
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures

[Máté Kocsis]

>
> So I would suggest rewording the options slightly:
>
> a) Deprecate in 8.3, remove in either 9.0 or 10.0
> b) Deprecate in 8.3, remove in 10.0
> c) Do not deprecate
>
> Now if the votes are a:5, b:4, c:4, we can say:
>
> - 9 people voted for deprecation in 8.3, vs 4 against
> - only 5 voted for removal in 9.0, vs 8 against
> - 9 voted for removal in 10.0, vs 4 against
>
> So we conclude that we should deprecate in 8.3, and remove in 10.0
>

While this vote format looks a bit confusing for me at the first sight, I'm
OK to apply it. Although, I don't fully agree with
the "deprecate in 8.3 and remove in 10.0" part due to the reason I wrote
about in my previous email.

In my opinion, if we want to keep a signature for around 5-7 more years
then we should really wait ~2 years with the
deprecation so that people can react voluntarily first. Libraries have to
get rid of deprecated calls in any case, otherwise
their users will surely start to complain. If they do fix these calls in
their PHP 8.x compatible code then there's much less reason
to postpone the removal with 5 more years.

The suggestion to narrow it down to a yes/no proposal in the discussion
> phase is probably even better, though.
>

I agree with this, but so far there was no feedback which functions/methods
people want to deprecate slower or faster,
so I'm eager to hear about your and everyone else's opinion!

Replying to Larry:

That these particular functions and uses are quite rare doesn't really
> change any of that; if anything it strengthens it, that we're willing to be
> graceful about it even in cases where we could probably get away with not
> being so.


I don't think this "generosity" is really necessary, even though I
appreciate your intention. For example,
in case of ldap_connect(), the signature to be deprecated is not even
documented at php.net... and it's only available on
a very specific platform. I see no reason to keep this signature for 5+
years. The same goes for IntlGregorianCalendar::__construct()
which seems to be a very underrepresented class as well.

As I already said, most of the functionality to be removed is easy to
replace, and it could be done via automation:
i.e. you add Symfony Polyfill to your project and then Rector swaps the
problematic function calls to the good ones. Sometimes
not even tooling is needed, a simple search + replace is enough. With all
that said, I think only a smaller subset
of functions may deserve the longer depreciation period.

Máté

Re: [PHP-DEV] Re: [VOTE] PHP Technical Committee

[Larry Garfield]

On Fri, May 12, 2023, at 4:10 PM, Andreas Heigl wrote:
> Hey Arvids, Hey all

>> In the modern day, people expect a very different style of communication.
>> And, sadly, those are the people who make decisions like "should we abandon
>> PHP and move to Go or JavaScript" and so on.
>> The other part that irks me a lot how php.net is developed - while it is
>> fine and it works, I have seen people lose all interest as soon as they
>> open the code. Nobody wants to touch it. And nobody wants to be responsible
>> for it too as far as I can tell.
>> The windows build machine I really don't have to explain anything here,
>> do I?
>> 
> Larry asked what alternatives those who voted "No" see.
>
> My main topic that I seem not to have been able to get across is that to 
> me there is no need to implement alternatives as everything is already 
> there.
>
> * We have rules for the list.
> * We have a workflow that should prohibit stuff getting into the core 
> from new developers without at least a second set of eyes and in case of 
> strong disagreement a separate discussion
> * We have an elected group of people that has the say about the part of 
> the source that they are responsible for

So you're basically arguing that it's an "implementation problem", not a rule 
problem.  I cannot agree.

Primarily because this

> * We have a workflow that should prohibit stuff getting into the core 
> from new developers without at least a second set of eyes and in case of 
> strong disagreement a separate discussion

isnt' true.  We have a workflow for new functionality that warrants an RFC.  
"What should the process be to re-optimize the way C includes work" is not 
something the RFC process is in any way suited for.  That sort of decision 
*needs* to have a clear voice on it, from some small, mostly agreeable set of 
voices.  (Which, again, does not include mine.  That's the point.)

That is a process gap right now, and it leads to other problems.

Expanding the role of the Release Managers to include that responsibility is 
one possibility.  I would be open to that, if others (including the RMs) are.  
However, for that to work, we'd need to elect RMs much sooner, say, 
October/November range so that they're ready to "take over leadership of HEAD" 
as soon as the branch is open for development.  Maybe sooner.

This is an approach I'm open to exploring, but as noted, would be  a scope 
change and rule change for the RMs.

--Larry Garfield

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Proposal: magic constant '::name' for properties and methods etc. like '::class' is for classes/object

[Claude Pache]

> Le 12 mai 2023 à 19:29, Lydia de Jongh  a écrit :
> 
> Hi,
> 
> Lately I made a small object initializer/builder with php Attributes.
> 
> 'Directly' accessing properties and methods of the class as a parameter in
> an Attribute is not really possible.
> You can do that for a class with: \path\to\MyClass::class, but for
> properties or methods you have to use strings, without recognition in
> editors.
> 
> It would be so nice if more items in php could be accessed with a magic
> constant as you can do with ::class.
> With magic constant an editor could recognize it and it limits typos etc.
> and it provides the developer with a list of the properties/methods in
> scope.
> 
> At the moment I implemented a kind of workaround by providing simple
> classes with the property names in class constants.
> Or add an extra property to a class with a property name that can be used
> in an attribute.
> 
> I will try to explain with examples of my code.
> 
> abstract class SaveFactoryAbstract {
> use ObjectBuilderTrait;
> 
> #[ResetValue]
> protected bool $isSaved = false;
> 
> #[InitObject] // tells the builder to initialize this property with the
> latest specs provided by (other) attributes
> #[ResetObject]
> protected ?SaveInterface $oSave = null;
> 
> public function __construct(){
> $this->buildMe(); // provided by the trait
> }
> }
> 
> 
> This is straightforward. Until you extend this class and want to set the
> class for $oSave.
> The other developer does not know which properties he can declare with an
> attribute
> 
> #[UseClass('oSave', ImageSave::class)]
> #[ResetValue('isSaved', default: true)]
> class ImageSaveFactory extends SaveFactoryAbstract { }
> 
> 
> As workaround I make classes like:
> 
> class oop { // lower character on purpose, for this is not a normal class
> 
> final public const isSaved = 'isSaved';
> 
> final public const Save = 'oSave';
> final private function __construct() {}
> }
> 
> So the extending class can be:
> This is recognized by the editor and gives the developer some clues.
> #[UseClass(oop::Save, ImageSave::class)]
> #[ResetValue(oop::isSaved, default: true)]
> class ImageSaveFactory extends SaveFactoryAbstract { }
> 
> But this is really annoying.
> 
> 
> It would be much better if we could do something like:
> #[UseClass(static::$oSave::name, ImageSave::class)] // 'static::' can be
> used, since the attribute belong to the scope of this class
> #[ResetValue(static::$isSaved::name, default: true)]
> class ImageSaveFactory extends SaveFactoryAbstract {
> }
> 
> This could also extend possibilities with/for variable variables
> Like:
> $this->myProp::name
> myClass::$staticProp::name
> 
> 
> A potential difficulty is: how to access normal properties/methods
> Maybe just as if they are static?
> Like parent::normalMethod() is working
> A normal property or method cannot have the same name as its static partner
> (sadly) so internally I hope it is not a problem.
> 
> outside scope:
> myClass::$staticProperty::name
> myClass::$normalProperty::name
> myClass::normalMethod::name
> 
> inside scope:
> static::$normalProperty::name
> self::$normalProperty::name // I do not know if 'self::' adds anything for
> this purpose, except for private properties/methods maybe
> 
> inside class/object:
> $this->normalProperty::name
> $this->normalMethod::name
> $this::$staticProperty::name
> I hope you like the idea! Greetz, Lydia


Hi,

That looks like the `nameof` operator proposed a few days ago?

https://externals.io/message/120173
https://externals.io/message/120173


—Claude

[PHP-DEV] Proposal: magic constant '::name' for properties and methods etc. like '::class' is for classes/object

[Lydia de Jongh]

Hi,

Lately I made a small object initializer/builder with php Attributes.

'Directly' accessing properties and methods of the class as a parameter in
an Attribute is not really possible.
You can do that for a class with: \path\to\MyClass::class, but for
properties or methods you have to use strings, without recognition in
editors.

It would be so nice if more items in php could be accessed with a magic
constant as you can do with ::class.
With magic constant an editor could recognize it and it limits typos etc.
and it provides the developer with a list of the properties/methods in
scope.

At the moment I implemented a kind of workaround by providing simple
classes with the property names in class constants.
Or add an extra property to a class with a property name that can be used
in an attribute.

I will try to explain with examples of my code.

abstract class SaveFactoryAbstract {
use ObjectBuilderTrait;

#[ResetValue]
protected bool $isSaved = false;

#[InitObject] // tells the builder to initialize this property with the
latest specs provided by (other) attributes
#[ResetObject]
protected ?SaveInterface $oSave = null;

public function __construct(){
$this->buildMe(); // provided by the trait
}
}


This is straightforward. Until you extend this class and want to set the
class for $oSave.
The other developer does not know which properties he can declare with an
attribute

#[UseClass('oSave', ImageSave::class)]
#[ResetValue('isSaved', default: true)]
class ImageSaveFactory extends SaveFactoryAbstract { }


As workaround I make classes like:

class oop { // lower character on purpose, for this is not a normal class

final public const isSaved = 'isSaved';

final public const Save = 'oSave';
final private function __construct() {}
}

So the extending class can be:
This is recognized by the editor and gives the developer some clues.
#[UseClass(oop::Save, ImageSave::class)]
#[ResetValue(oop::isSaved, default: true)]
class ImageSaveFactory extends SaveFactoryAbstract { }

But this is really annoying.


It would be much better if we could do something like:
#[UseClass(static::$oSave::name, ImageSave::class)] // 'static::' can be
used, since the attribute belong to the scope of this class
#[ResetValue(static::$isSaved::name, default: true)]
class ImageSaveFactory extends SaveFactoryAbstract {
}

This could also extend possibilities with/for variable variables
Like:
$this->myProp::name
myClass::$staticProp::name


A potential difficulty is: how to access normal properties/methods
Maybe just as if they are static?
Like parent::normalMethod() is working
A normal property or method cannot have the same name as its static partner
(sadly) so internally I hope it is not a problem.

outside scope:
myClass::$staticProperty::name
myClass::$normalProperty::name
myClass::normalMethod::name

inside scope:
static::$normalProperty::name
self::$normalProperty::name // I do not know if 'self::' adds anything for
this purpose, except for private properties/methods maybe

inside class/object:
$this->normalProperty::name
$this->normalMethod::name
$this::$staticProperty::name
I hope you like the idea! Greetz, Lydia

Re: [PHP-DEV] Re: [VOTE] PHP Technical Committee

[Andreas Heigl]

Hey Arvids, Hey all

On 12.05.23 17:48, Arvids Godjuks wrote:

On Fri, 12 May 2023 at 18:12, Andreas Heigl  wrote:


Hey Larry, Hey all

On 12.05.23 16:42, Larry Garfield wrote:

On Fri, May 12, 2023, at 11:57 AM, Jakub Zelenka wrote:

On Fri, Apr 28, 2023 at 11:00 AM Jakub Zelenka  wrote:


Hi,

The vote is now open for the RFC about introduction of the PHP

Technical

Committee:

https://wiki.php.net/rfc/php_technical_committee

Regards



The voting ended with 10 yes votes and 21 no votes. It means that the

RFC

has been declined. Thanks for voting.

Regards

Jakub


For those who voted no, I would kindly ask: What is your alternative?

We have an organizational/structural problem.  This isn't really

debatable.  An eager new contributor was just bullied out of contributing,
and the one process we have for dealing with it (RFCs) failed miserably to
handle the situation.


Ignoring the problem is a bad option.  If the TC proposal isn't your

preferred way to address it, OK, what is?  "Do nothing, it's OK if people
occasionally get bullied out of contributing" is not an answer.

The internals list has not only recently "failed" miserably. That is not
to say that it has been like that since time immemoriable and should
therefore stay like that. On the contrary.

But we already have a group that has "the say" in PHP. The PHP Group is
mentioned in each and every source-file as they are the licence-holder.

Instead of adding another group I would rather see that existing group
to be filled with new life.

Whether that is the right group to tell people in the internals list off
is IMO questionable.

In essence to me the internals list is a group that discusses technical
topics regarding PHPs sources. The outcome and the vote whether
something will become part of the code is then voted on in an RFC. That
is a rather democratic process. When people are not able to convince the
majority of the voters that their idea is a good idea for the PHP
sources then it might not be a good idea. Having a group of people with
elevated privileges in that process is against that long lived and
established current process. And it looks like internals is not yet at
that point.

Having a group of people that make sure that the tone on the list is
civil, on-topic and inviting to newcomers is a different story. But that
was not what the vote was about.

So for me there already is an elevated group that has a bit more to say
regarding the PHP-sources as they are the once "owning" the licence.
Adding a second group with elevated privileges regarding code-decissions
will not help in keeping the mailinglist civilised and welcoming.

On a sidenote: I'd rather try to find a new solution for the PHP Group
as licence holder. So the idea of having an elected comitee that coupd
perhaps replace the PHP Group was tempting!

So my alternative would be for everyone to every now and then reread
https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md

And as a second step to make internals more welcoming and inclusive
might be to have people keep an eye on the tone that can intervene when
the debate gets too heated. Those IMO need to be respected people and
their influence is in those matters purely on keeping the tone civilized
and not have a veto right in regards to code. The internals list and in
the end the vote on an RFC should have the last say in regards to code.

My 0.02€

Cheers

Andreas

--
,,,
   (o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl   |
| mailto:andr...@heigl.org  N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org   |
+-+
| https://hei.gl/appointmentwithandreas   |
+-+
| GPG-Key: https://hei.gl/keyandreasheiglorg  |
+-+



Hello Andreas!

I think what Larry is asking are ideas on actual solutions,  what steps
should be made and working out how those recent situations should have been
solved/handled. Really it does not matter if will it be PHP Group or some
called something else. There has been a lot of discussion off the list in
communities among PHP developers and nobody considers the recent events as
something that should have happened.

The time to "let's throw around some ideas" has passed. The current
situation highly reminds me of the year prior to the introduction of the
RFC process: this going down a hill at a rapid pace and a lot of people
yelling "la la la la" while plugging their ears.
The world has changed, and the new breed of developers has grown up in a
very different 

Re: [PHP-DEV] Re: [VOTE] PHP Technical Committee

[Jakub Zelenka]

>
>
> And the rest is pretty already nicely described in the
> CONTRIBUTING.md[1] file.
>
>
This is just a random document that has no weight in decision. Anyone can
change it without asking. Except the actual voting, then only voted in
proposal that was accepted is the one for the release process [1].


> For example:
>
>  > Discuss any significant changes on the list before committing and get
> confirmation from the release manager for the given branch.
>
> or
>
>  > If you "strongly disagree" about something another person did, don't
> start fighting publicly - take it up in private email.
>
> So in essence we already have the group of people - and they are even
> elected: The release-managers.
>
>
So it means that this is not exactly correct. Release manager can decide
only about bugs. Specifically see RMs role in [1]:

> But they are not:
> Decide which features, extension or SAPI get in a release or not

[1] https://wiki.php.net/rfc/releaseprocess

Regards

Jakub

Re: [PHP-DEV] Re: [VOTE] PHP Technical Committee

[Andreas Heigl]

Hey Larry, hey all

On 12.05.23 17:36, Larry Garfield wrote:

On Fri, May 12, 2023, at 3:12 PM, Andreas Heigl wrote:


[...]



In essence to me the internals list is a group that discusses technical
topics regarding PHPs sources. The outcome and the vote whether
something will become part of the code is then voted on in an RFC. That
is a rather democratic process. When people are not able to convince the
majority of the voters that their idea is a good idea for the PHP
sources then it might not be a good idea. Having a group of people with
elevated privileges in that process is against that long lived and
established current process. And it looks like internals is not yet at
that point.


Again, not the topic at hand.  The TC proposal did not change the feature approval RFC 
process, at all.  It was very explicit about that.  It was about non-feature decisions 
that are highly technical.  Those simply do not make sense to apply casual direct 
democracy to.  To take the recent example, there's probably only about 10 people who have 
any meaningful input to give on "should this include statement be here or over 
here."  The other 990 or so RFC voters, quite honestly, do not have anything 
meaningful or useful to say, and most probably don't even understand the question.  And I 
include myself in that category.  On decisions like that, *please do not ask me, I have 
nothing useful to contribute*.


In other projects I work on these purely technical decissions and 
discussions are solved using CodeReviews (or Pair/MobProgramming).


That doesn't indeed require an RFC.

But in the specific case that we seem to try to solve here - at least 
from what I have seen and read - I doubt that any CodeReview or entity 
could have made that less messy.


So I'm still not convinced that we need a special group of people - 
apart from the already special group of amazing people that are doing a 
shitload of great stuff for the language.


And the rest is pretty already nicely described in the 
CONTRIBUTING.md[1] file.


For example:

> Discuss any significant changes on the list before committing and get 
confirmation from the release manager for the given branch.


or

> If you "strongly disagree" about something another person did, don't 
start fighting publicly - take it up in private email.


So in essence we already have the group of people - and they are even 
elected: The release-managers.


So no need to elect another body

My 0.02€

Cheers

Andreas

[1] 
https://github.com/php/php-src/blob/master/CONTRIBUTING.md#git-commit-rules

--
  ,,,
 (o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl   |
| mailto:andr...@heigl.org  N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org   |
+-+
| https://hei.gl/appointmentwithandreas   |
+-+
| GPG-Key: https://hei.gl/keyandreasheiglorg  |
+-+


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PHP-DEV] Re: [VOTE] PHP Technical Committee

[Arvids Godjuks]

On Fri, 12 May 2023 at 18:12, Andreas Heigl  wrote:

> Hey Larry, Hey all
>
> On 12.05.23 16:42, Larry Garfield wrote:
> > On Fri, May 12, 2023, at 11:57 AM, Jakub Zelenka wrote:
> >> On Fri, Apr 28, 2023 at 11:00 AM Jakub Zelenka  wrote:
> >>
> >>> Hi,
> >>>
> >>> The vote is now open for the RFC about introduction of the PHP
> Technical
> >>> Committee:
> >>>
> >>> https://wiki.php.net/rfc/php_technical_committee
> >>>
> >>> Regards
> >>>
> >>>
> >> The voting ended with 10 yes votes and 21 no votes. It means that the
> RFC
> >> has been declined. Thanks for voting.
> >>
> >> Regards
> >>
> >> Jakub
> >
> > For those who voted no, I would kindly ask: What is your alternative?
> >
> > We have an organizational/structural problem.  This isn't really
> debatable.  An eager new contributor was just bullied out of contributing,
> and the one process we have for dealing with it (RFCs) failed miserably to
> handle the situation.
> >
> > Ignoring the problem is a bad option.  If the TC proposal isn't your
> preferred way to address it, OK, what is?  "Do nothing, it's OK if people
> occasionally get bullied out of contributing" is not an answer.
>
> The internals list has not only recently "failed" miserably. That is not
> to say that it has been like that since time immemoriable and should
> therefore stay like that. On the contrary.
>
> But we already have a group that has "the say" in PHP. The PHP Group is
> mentioned in each and every source-file as they are the licence-holder.
>
> Instead of adding another group I would rather see that existing group
> to be filled with new life.
>
> Whether that is the right group to tell people in the internals list off
> is IMO questionable.
>
> In essence to me the internals list is a group that discusses technical
> topics regarding PHPs sources. The outcome and the vote whether
> something will become part of the code is then voted on in an RFC. That
> is a rather democratic process. When people are not able to convince the
> majority of the voters that their idea is a good idea for the PHP
> sources then it might not be a good idea. Having a group of people with
> elevated privileges in that process is against that long lived and
> established current process. And it looks like internals is not yet at
> that point.
>
> Having a group of people that make sure that the tone on the list is
> civil, on-topic and inviting to newcomers is a different story. But that
> was not what the vote was about.
>
> So for me there already is an elevated group that has a bit more to say
> regarding the PHP-sources as they are the once "owning" the licence.
> Adding a second group with elevated privileges regarding code-decissions
> will not help in keeping the mailinglist civilised and welcoming.
>
> On a sidenote: I'd rather try to find a new solution for the PHP Group
> as licence holder. So the idea of having an elected comitee that coupd
> perhaps replace the PHP Group was tempting!
>
> So my alternative would be for everyone to every now and then reread
> https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md
>
> And as a second step to make internals more welcoming and inclusive
> might be to have people keep an eye on the tone that can intervene when
> the debate gets too heated. Those IMO need to be respected people and
> their influence is in those matters purely on keeping the tone civilized
> and not have a veto right in regards to code. The internals list and in
> the end the vote on an RFC should have the last say in regards to code.
>
> My 0.02€
>
> Cheers
>
> Andreas
>
> --
>,,,
>   (o o)
> +-ooO-(_)-Ooo-+
> | Andreas Heigl   |
> | mailto:andr...@heigl.org  N 50°22'59.5" E 08°23'58" |
> | https://andreas.heigl.org   |
> +-+
> | https://hei.gl/appointmentwithandreas   |
> +-+
> | GPG-Key: https://hei.gl/keyandreasheiglorg  |
> +-+
>

Hello Andreas!

I think what Larry is asking are ideas on actual solutions,  what steps
should be made and working out how those recent situations should have been
solved/handled. Really it does not matter if will it be PHP Group or some
called something else. There has been a lot of discussion off the list in
communities among PHP developers and nobody considers the recent events as
something that should have happened.

The time to "let's throw around some ideas" has passed. The current
situation highly reminds me of the year prior to the introduction of the
RFC process: this going down a hill 

Re: [PHP-DEV] Re: [VOTE] PHP Technical Committee

[Larry Garfield]

On Fri, May 12, 2023, at 3:12 PM, Andreas Heigl wrote:

>> For those who voted no, I would kindly ask: What is your alternative?
>> 
>> We have an organizational/structural problem.  This isn't really debatable.  
>> An eager new contributor was just bullied out of contributing, and the one 
>> process we have for dealing with it (RFCs) failed miserably to handle the 
>> situation.
>> 
>> Ignoring the problem is a bad option.  If the TC proposal isn't your 
>> preferred way to address it, OK, what is?  "Do nothing, it's OK if people 
>> occasionally get bullied out of contributing" is not an answer.
>
> The internals list has not only recently "failed" miserably. That is not 
> to say that it has been like that since time immemoriable and should 
> therefore stay like that. On the contrary.
>
> But we already have a group that has "the say" in PHP. The PHP Group is 
> mentioned in each and every source-file as they are the licence-holder.
>
> Instead of adding another group I would rather see that existing group 
> to be filled with new life.

That's an interesting idea.  However, the PHP Group consists, AFAIK, of a half 
dozen people, none of whom are still active in PHP in any meaningful way.  Or 
maybe one.  Its legal status is... I don't even know, honestly.  Is it an 
actual registered organization?  Or is it just "we say we're the PHP Group so 
we are" (like most OSS groups)?

That said, I'm not sure if the legal side of PHP (which is important, no doubt) 
should be the same as the technical side of PHP.  Those are separate concerns.

> Whether that is the right group to tell people in the internals list off 
> is IMO questionable.

Which is also not quite the topic at hand.  "People were mean" isn't the 
problem the TC proposal was trying to solve.  "There is no mechanism to resolve 
purely technical issues that doesn't involve people being mean" is the issue 
being addressed.  When there is a structure vacuum, it gets filled by the 
loudest and most brash voice that has the least regard for decorum.  That's 
just the nature of humans.  Rather than try to fix the loudest and most brash 
voice, the intent is to fix the structure vacuum.

> In essence to me the internals list is a group that discusses technical 
> topics regarding PHPs sources. The outcome and the vote whether 
> something will become part of the code is then voted on in an RFC. That 
> is a rather democratic process. When people are not able to convince the 
> majority of the voters that their idea is a good idea for the PHP 
> sources then it might not be a good idea. Having a group of people with 
> elevated privileges in that process is against that long lived and 
> established current process. And it looks like internals is not yet at 
> that point.

Again, not the topic at hand.  The TC proposal did not change the feature 
approval RFC process, at all.  It was very explicit about that.  It was about 
non-feature decisions that are highly technical.  Those simply do not make 
sense to apply casual direct democracy to.  To take the recent example, there's 
probably only about 10 people who have any meaningful input to give on "should 
this include statement be here or over here."  The other 990 or so RFC voters, 
quite honestly, do not have anything meaningful or useful to say, and most 
probably don't even understand the question.  And I include myself in that 
category.  On decisions like that, *please do not ask me, I have nothing useful 
to contribute*.

But the selection of those limited people to deal with matters that are, quite 
frankly, over the head of and below the radar of 99% of us, was proposed to be 
democratic.  It was basically the same process as Release Manager selection.

> So for me there already is an elevated group that has a bit more to say 
> regarding the PHP-sources as they are the once "owning" the licence. 
> Adding a second group with elevated privileges regarding code-decissions 
> will not help in keeping the mailinglist civilised and welcoming.

Again, separate issues needing separate discussions.  (I'm not getting into the 
CoC topic right now. My skin isn't *that* thick.)  We're specifically talking 
about the "technical matters mediators", to avoid revert-fights like we just 
had.  Keep the topic narrow.

> On a sidenote: I'd rather try to find a new solution for the PHP Group 
> as licence holder. So the idea of having an elected comitee that coupd 
> perhaps replace the PHP Group was tempting!

The license holder needs to be a legal entity, so the TC isn't really that.  
Whether the PHP Group should be redesigned to be a legal entity is a separate 
matter that bears discussion, but isn't the topic at hand.

--Larry Garfield

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Re: [VOTE] PHP Technical Committee

[Andreas Heigl]

Hey Larry, Hey all

On 12.05.23 16:42, Larry Garfield wrote:

On Fri, May 12, 2023, at 11:57 AM, Jakub Zelenka wrote:

On Fri, Apr 28, 2023 at 11:00 AM Jakub Zelenka  wrote:


Hi,

The vote is now open for the RFC about introduction of the PHP Technical
Committee:

https://wiki.php.net/rfc/php_technical_committee

Regards



The voting ended with 10 yes votes and 21 no votes. It means that the RFC
has been declined. Thanks for voting.

Regards

Jakub


For those who voted no, I would kindly ask: What is your alternative?

We have an organizational/structural problem.  This isn't really debatable.  An 
eager new contributor was just bullied out of contributing, and the one process 
we have for dealing with it (RFCs) failed miserably to handle the situation.

Ignoring the problem is a bad option.  If the TC proposal isn't your preferred way to 
address it, OK, what is?  "Do nothing, it's OK if people occasionally get bullied 
out of contributing" is not an answer.


The internals list has not only recently "failed" miserably. That is not 
to say that it has been like that since time immemoriable and should 
therefore stay like that. On the contrary.


But we already have a group that has "the say" in PHP. The PHP Group is 
mentioned in each and every source-file as they are the licence-holder.


Instead of adding another group I would rather see that existing group 
to be filled with new life.


Whether that is the right group to tell people in the internals list off 
is IMO questionable.


In essence to me the internals list is a group that discusses technical 
topics regarding PHPs sources. The outcome and the vote whether 
something will become part of the code is then voted on in an RFC. That 
is a rather democratic process. When people are not able to convince the 
majority of the voters that their idea is a good idea for the PHP 
sources then it might not be a good idea. Having a group of people with 
elevated privileges in that process is against that long lived and 
established current process. And it looks like internals is not yet at 
that point.


Having a group of people that make sure that the tone on the list is 
civil, on-topic and inviting to newcomers is a different story. But that 
was not what the vote was about.


So for me there already is an elevated group that has a bit more to say 
regarding the PHP-sources as they are the once "owning" the licence. 
Adding a second group with elevated privileges regarding code-decissions 
will not help in keeping the mailinglist civilised and welcoming.


On a sidenote: I'd rather try to find a new solution for the PHP Group 
as licence holder. So the idea of having an elected comitee that coupd 
perhaps replace the PHP Group was tempting!


So my alternative would be for everyone to every now and then reread 
https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md


And as a second step to make internals more welcoming and inclusive 
might be to have people keep an eye on the tone that can intervene when 
the debate gets too heated. Those IMO need to be respected people and 
their influence is in those matters purely on keeping the tone civilized 
and not have a veto right in regards to code. The internals list and in 
the end the vote on an RFC should have the last say in regards to code.


My 0.02€

Cheers

Andreas

--
  ,,,
 (o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl   |
| mailto:andr...@heigl.org  N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org   |
+-+
| https://hei.gl/appointmentwithandreas   |
+-+
| GPG-Key: https://hei.gl/keyandreasheiglorg  |
+-+


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PHP-DEV] Re: [VOTE] PHP Technical Committee

[Larry Garfield]

On Fri, May 12, 2023, at 11:57 AM, Jakub Zelenka wrote:
> On Fri, Apr 28, 2023 at 11:00 AM Jakub Zelenka  wrote:
>
>> Hi,
>>
>> The vote is now open for the RFC about introduction of the PHP Technical
>> Committee:
>>
>> https://wiki.php.net/rfc/php_technical_committee
>>
>> Regards
>>
>>
> The voting ended with 10 yes votes and 21 no votes. It means that the RFC
> has been declined. Thanks for voting.
>
> Regards
>
> Jakub

For those who voted no, I would kindly ask: What is your alternative?  

We have an organizational/structural problem.  This isn't really debatable.  An 
eager new contributor was just bullied out of contributing, and the one process 
we have for dealing with it (RFCs) failed miserably to handle the situation.

Ignoring the problem is a bad option.  If the TC proposal isn't your preferred 
way to address it, OK, what is?  "Do nothing, it's OK if people occasionally 
get bullied out of contributing" is not an answer.

--Larry Garfield

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures

[Larry Garfield]

On Fri, May 12, 2023, at 6:52 AM, Rowan Tommins wrote:

> I think it's actually very likely that voters would want to express 
> "deprecate, but do not remove before 10.0". Treating those votes as 
> "generally in favour, so enough to approve removal in 9.0" doesn't seem 
> appropriate.
>
> The other way around - "deprecate, but do not remove later than 9.0" - 
> seems less likely. I also don't see any reason to delay the deprecation 
> - the whole point of the longer period is to give people more notice.
>
> So I would suggest rewording the options slightly:
>
> a) Deprecate in 8.3, remove in either 9.0 or 10.0
> b) Deprecate in 8.3, remove in 10.0
> c) Do not deprecate
>
> Now if the votes are a:5, b:4, c:4, we can say:
>
> - 9 people voted for deprecation in 8.3, vs 4 against
> - only 5 voted for removal in 9.0, vs 8 against
> - 9 voted for removal in 10.0, vs 4 against
>
> So we conclude that we should deprecate in 8.3, and remove in 10.0
>
>
> The suggestion to narrow it down to a yes/no proposal in the discussion 
> phase is probably even better, though.

Personally I'm on team "add new functions now, deprecate old ones in 9, remove 
old ones in 10."  

1. As noted, it gives people a clean window in which to use the old or new ones 
without getting a deprecation warning, and without cutting off support for old 
but still supported PHP versions.
2. It gives people ample time to fix their code.  (Around 7-8 years.)
3. Perhaps most importantly, it's a good-faith gesture to the people who have 
objected (validly, if sometimes impolitely and crudely) to shorter deprecation 
periods in the past.  There is definitely a relationship building to be done 
with the broader user-space community, and offering a very wide grace period is 
a good way to help with that.

That these particular functions and uses are quite rare doesn't really change 
any of that; if anything it strengthens it, that we're willing to be graceful 
about it even in cases where we could probably get away with not being so.

--Larry Garfield

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: [VOTE] PHP Technical Committee

[Jakub Zelenka]

On Fri, Apr 28, 2023 at 11:00 AM Jakub Zelenka  wrote:

> Hi,
>
> The vote is now open for the RFC about introduction of the PHP Technical
> Committee:
>
> https://wiki.php.net/rfc/php_technical_committee
>
> Regards
>
>
The voting ended with 10 yes votes and 21 no votes. It means that the RFC
has been declined. Thanks for voting.

Regards

Jakub

[PHP-DEV] PHP 8.1.19 Released

[Patrick ALLAERT]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The PHP development team announces the immediate availability of PHP
8.1.19.
This is a bugfix release.

All PHP 8.1 users are encouraged to upgrade to this version.

For source downloads of PHP 8.1.19 please visit our downloads page. Windows
binaries can be found on the PHP for Windows site. The list of changes is
recorded in the ChangeLog.

Release Announcement: 
Downloads:
Windows downloads:
Changelog:
Release Manifest:


Many thanks to all the contributors and supporters!

Patrick Allaert, Ben Ramsey & Joe Watkins

php-8.1.19.tar.bz2
SHA256 hash:
64207207fda30be926a2ef1f66ff266bf1fdc7e03339bc99fbba0a1245e4279b
PGP signature:
- -BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEE8faSI4+8FmblpczUGZ+d/vb/uv0FAmRbn8QACgkQGZ+d/vb/
uv3o0g/7BRtS3JRyINjXGpHm1dz2HI9ebjCAP2whZu+mcBlEsRWuYJ/lgYwD4LGM
Qorz1B5v7+MdPzkRNvBh0ysLbwEeO39KAPzm64u7gtQ3gNUjXNPlZWQCl+YLNZYF
JVhYuBzF9Yk8QMOJDftr7/8m+r4Vnd50Yuv3ZGXr/NLbpQIRxy0Uhs1kJ0WErJNU
Rn4EtgI4buzaruxhVfHQ6JDE1RxnSGt/eCa663OyYlpu0rdUu+o9l9oL9xhygo5l
LxhQl3MHS5ubuIbAhTA5D3N/7TVU0a/RsxKVilUU85pJpNx+ABjFxa8Z/B2m2BoC
WT0JxQKaerq1apJlm9TAE8mzS4v7pb1227vIS92wr6PtM/ODS5f7F+waI4ojHxwn
H364M1uFYJ0PSY95dROSu7EKt4f4Z92FdnhsrElDHUXpfnyWI/kErPGIMAVZi7PS
535ngb3yV90I5gLu8bpSpLvNxj/YhdFQ93DZ0o3fUActQgkRMGDgdMBwYXJkNhvB
wF8jAYMdFxEhpQ9jIutKBDqqPCQKeIEWOkwFey1FM3rFi2r4cVntkEqjLnC3NggS
cmnuw2OQKRO2ZKbz5ADptoC+BWzxlDBO/0CCa9PCUC3t+0ZdFys9UlunU7sSs2O0
692BP3aoykuzjOPdFyOUAR4oGqOPtZ6z8Q2guD1iWuSmNZOUMrY=
=EuNI
- -END PGP SIGNATURE-

php-8.1.19.tar.gz
SHA256 hash:
0ebb6b0ecf5d8e355c2f1362807f9b73c6e803d496c5ad3e4fb00be989988372
PGP signature:
- -BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEE8faSI4+8FmblpczUGZ+d/vb/uv0FAmRbn8QACgkQGZ+d/vb/
uv0KxQ//VJF8T/fScPf6XSRpDmUu4z3gIZuVcj/jREf3419gLy73Y/on0JKsa56C
4Gd88CTLnJQgH6DzzlNQq2pMtnW1W12Tm5N1Jq1I0nJQStBSC6Z508pMMUnT9d96
2uYT423l6vMJGwnPC3NfUGNyNK0tLXRB8V9cj/SibCIRSC3GCDScx7vLI7ySKh/x
V+0XYqtkVj0eOjFDTvi5iKCCex1Qhg3dnDOkwOUYtRpyc4CkHSj7n7nHfsDIaMpP
373Ec3t0kA/TtUHHYazLCYmdPzoWAKKtv7YMOc6AXQOmxuJOcfolqTx2Hlw0zAVe
ATFJ6Fim4DAtK52KqTsSSYCyNkMyJ8c466xmev+hDHQevT2TYbsn0UGd5HKuwrCO
oK0AynPrS1daSyt9V2ugAIJCTucrxKnQuYMPebD5u08k62+ntEIJ1IuYlWjtqs17
BbaFUqSJYOZL/koTOauG80zPn7CgAadrF8GjSZe3uWzg9CAN9FQorwiewtxbD+mk
8R3P79tyNv69QR1vHLG/kk2oOakpiLHaNq6455Dmep3SOzDFLOCTmfhkrp+6ooHT
Bt9z/H8ZcUumkyA86j+uSYZpqlvgwmQU8+rt9WMXkTfbepXP/hJ/n/koSBXzzl0Y
XUkX7vXd3flmOTZC/CQ1rDvRHsWff5I0eeaZ/cCw34lJPM51hUo=
=J+I4
- -END PGP SIGNATURE-

php-8.1.19.tar.xz
SHA256 hash:
f42f0e93467415b2d30aa5b7ac825f0079a74207e0033010383cdc1e13657379
PGP signature:
- -BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEE8faSI4+8FmblpczUGZ+d/vb/uv0FAmRbn8QACgkQGZ+d/vb/
uv1yfQ//X5wQv/RcHyxLG45mMcpuV/H6YxE5QCbthTDIISwvuSbqyBvxzjxteqbX
JeOT0NQQ6NlIzgtvPIp5nVPFcejSUtXu8TidmVTSwTu/D2sHdAyUgxu9D2IM/Rj0
8TDEoPMHjSeE730fsvfs4kf/JEu0f4iGG/iVdUfjiRgxTtN+er4GW003EMHmiByS
aduiKMojwHMNNNH2YsdE832HU+Pf0hO4XYXVGmCsHJ+t4cMfC0NhlJOpYpMQFVf/
kxHfGl2lcGicCobvVyycZpIlNaewre5DiQIfj6UgTjBMDKt6YBzqB7VgxPz8CPrC
C/QwYIKfrc18EwESd16qo3IEkKjy7UgrcC7Pls+QqjabXbFZC7qRupVQDycC7TNA
GyJo8fGHHCcjbyGfcE/fEl8R6ay1HpXOD0gz8xoZa0lpLNKi7sWpojh7sG1ug+Co
JN6/cxFClMCeKiNrkf3RJZT91CZw8seTVPLe6mf5huCfZpciCFAUO4lEmBd2Xkzo
r+JIyhFhZQ/t7ziWtyN4Iq5vQ5U5Hvby9H6OqtZKPd5TnrEX5elUqxgtYvKm8/Wu
7SWWN5geOV73jKpc8/Kq618Mb7kdWDheWVhB19sX6iLepKM5fmMQ/drxGZDivobh
lE7oZaRBSd7Ug9yh7ZtOXmFYZ5xtL+zLDGycHFZ3HEXvDHb4PKU=
=FRtl
- -END PGP SIGNATURE-
-BEGIN PGP SIGNATURE-
Version: FlowCrypt Email Encryption 8.4.7
Comment: Seamlessly send and receive encrypted email

wsFzBAEBCgAnBYJkXfFUCZAZn53+9v+6/RYhBPH2kiOPvBZm5aXM1Bmfnf72
/7r9AADJsw/8CA6pKU31FsbH6vUNUBi+KHX9+OIwqTRwD5ohgirZ3GikDb7t
zsRbzyRmKjAyExvAjRAgh2IJXSLH5/qcz/nc5KHz6lV1wSWVDA66A8gZYbto
WEzi+OLFvV5KOT8fNRSA9RKGd4CD57AL+ONsNZkR39Z439W+hZmDxpnun8Ml
v5fsTPqW25UKJr4325RS8I/cUzH4aXR+mBh/5BjWOwFVaWCvktt072ph4EYQ
/yi+I1i/lMklkXpQUy2OvOyOhTZkkhfv+MjEMRgpFLtyy8Q1SoaOwoXV7JWd
UQN56UiKvUnc1ODQL/fmrFv3SScuDWJLmmTS4GEvlS9QfQNYXxT+JVL8asCE
/OLjZWRJDGqH9cfRhasGYDMBxch+mAWmxHmpYcbJMrLn/m2Dua3R4U1VlDhg
W56njcSJNkiDLil5G8eTtkJjZgO5AabwRPukO6v8Nw/Ou4HLl/vXAkMRRU2n
XVrCVFCifsa+TBaZ4QCEU6p61WyEWtnREF2hH6C9qZPU2UFS6LhvdzuoO2rH
wL/WMfMCerNnI8V5r2xIFMhVTDRcr4Ud4GY885N2y2TT2G0YKUBmXGHF/Mch
MHXAMAXiU4FLbwUzY60qDMO1REnQLn2bT0i/JZmlJUNWA/YrF4VEDTMEFgEM
tvxoiv9luh/r6My1p6qBiXIZYnofarXZSaM=
=KO+h
-END PGP SIGNATURE-

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures

[Rowan Tommins]

On 11 May 2023 18:06:44 BST, Dan Ackroyd  wrote:
>On Thu, 11 May 2023 at 10:36, Tim Düsterhus  wrote:
>>
>> I believe this vote format ("three options") is not really compatible
>> with the voting rules (https://wiki.php.net/rfc/voting).
>>
>> For example it's not entirely clear what would happen here:
>>
>> 5 votes to deprecate in 8.3 / remove 9.0
>> 4 votes to deprecate in 9.0 / remove 10.0
>> 4 votes to not deprecate.
>
>The RFC author could just say that yes votes for deprecation and
>eventual removal will be added together, with the timescale being a
>preference vote.
>
>I think the only people who would object to that are people who would
>vote yes to "deprecate and remove" but only if it matches their
>preferred timescale, and would otherwise vote no. Which probably isn't
>a thing.


I think it's actually very likely that voters would want to express "deprecate, 
but do not remove before 10.0". Treating those votes as "generally in favour, 
so enough to approve removal in 9.0" doesn't seem appropriate.

The other way around - "deprecate, but do not remove later than 9.0" - seems 
less likely. I also don't see any reason to delay the deprecation - the whole 
point of the longer period is to give people more notice.

So I would suggest rewording the options slightly:

a) Deprecate in 8.3, remove in either 9.0 or 10.0
b) Deprecate in 8.3, remove in 10.0
c) Do not deprecate

Now if the votes are a:5, b:4, c:4, we can say:

- 9 people voted for deprecation in 8.3, vs 4 against
- only 5 voted for removal in 9.0, vs 8 against
- 9 voted for removal in 10.0, vs 4 against

So we conclude that we should deprecate in 8.3, and remove in 10.0


The suggestion to narrow it down to a yes/no proposal in the discussion phase 
is probably even better, though.

Regards,

-- 
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php