[PHP-DEV] Re: Bugsnet

[Pierre Joye]

Hi Joe,

On Sun, May 9, 2021, 1:49 PM Joe Watkins  wrote:

> Morning internals,
>
>
> Having moved our workflow to github, now seems to be the time to seriously
> consider retiring bugsnet for general use, and using the tools that are
> waiting for us - Github Issues.
>

yes! yes! yes!

and we could you projects/roadmap too together with gh APIs and the RFC.

>

Re: [PHP-DEV] Bugsnet

[Jakub Zelenka]

On Thu, 21 Oct 2021, 22:46 Nikita Popov,  wrote:

> On Thu, Oct 21, 2021 at 10:42 PM Jakub Zelenka  wrote:
>
>> On Thu, Oct 21, 2021 at 4:07 PM Nikita Popov 
>> wrote:
>>
>>>
>>> I'm proposing the following label structure (the list at
>>> https://github.com/nikic/test-repo/labels is incomplete though): Each
>>> report has either a bug or feature label. Additionally it starts out with
>>> the T-needs-triage label. Once a project member triages the report, the
>>> label is removed and a category label is added instead, e.g. C-OpenSSL
>>> for
>>> issues relating to the OpenSSL extension.
>>>
>>> I also have a few more triage labels (T-needs-feedback, T-verified,
>>> T-invalid, T-wontfix, T-duplicate), but I'm not sure we actually need any
>>> but the first one or the first two -- I personally don't see a lot of
>>> value
>>> in having a label for why exactly an issue has been closed, the fact that
>>> it is closed is usually sufficient.
>>>
>>>
>> Have you considered custom fields that are now in beta with some other
>> features in https://github.com/features/issues ? That seems a bit nicer
>> to me...
>>
>
> Yes, I tested this as well (the PHP organization is signed up for the
> beta). Unfortunately, I found this functionality rather awkward and don't
> think it would work well for us. The key problem is that the new
> functionality is not an improvement for issues -- it's an improvement for
> "projects". You can add an issue to a project (manually) and then you can
> add extra metadata to the issue in that project. It's not possible to add
> custom fields to issues themselves.
>
>
Ah ok. That's a bit useless then. :) I agree that it wouldn't probably work
well for us though.

+1 on your proposal. I think that makes sense and could work well.

Regards

Jakub

Re: [PHP-DEV] Bugsnet

[Nikita Popov]

On Thu, Oct 21, 2021 at 10:42 PM Jakub Zelenka  wrote:

> On Thu, Oct 21, 2021 at 4:07 PM Nikita Popov  wrote:
>
>>
>> I'm proposing the following label structure (the list at
>> https://github.com/nikic/test-repo/labels is incomplete though): Each
>> report has either a bug or feature label. Additionally it starts out with
>> the T-needs-triage label. Once a project member triages the report, the
>> label is removed and a category label is added instead, e.g. C-OpenSSL for
>> issues relating to the OpenSSL extension.
>>
>> I also have a few more triage labels (T-needs-feedback, T-verified,
>> T-invalid, T-wontfix, T-duplicate), but I'm not sure we actually need any
>> but the first one or the first two -- I personally don't see a lot of
>> value
>> in having a label for why exactly an issue has been closed, the fact that
>> it is closed is usually sufficient.
>>
>>
> Have you considered custom fields that are now in beta with some other
> features in https://github.com/features/issues ? That seems a bit nicer
> to me...
>

Yes, I tested this as well (the PHP organization is signed up for the
beta). Unfortunately, I found this functionality rather awkward and don't
think it would work well for us. The key problem is that the new
functionality is not an improvement for issues -- it's an improvement for
"projects". You can add an issue to a project (manually) and then you can
add extra metadata to the issue in that project. It's not possible to add
custom fields to issues themselves.

Regards,
Nikita

Re: [PHP-DEV] Add ReflectionFunctionAbstract::isAnonymous()

[Aaron Piotrowski]

> On Oct 20, 2021, at 6:12 PM, Dylan K. Taylor  wrote:
> 
> Hi all, 
> 
> Given the addition of Closure::fromCallable() and the upcoming first-class 
> callable syntax in 8.1, it seems slightly problematic that there's no simple 
> way to tell by reflection if a Closure refers to an anonymous function or 
> not. ReflectionFunctionAbstract::isClosure() (perhaps somewhat misleadingly) 
> returns whether the closure is literally a \Closure instance, so it's not 
> useful for this purpose. 
> 
> The only way to do this currently (that I know about) is to check if the name 
> of the function contains "{closure}", which is a bit unpleasant and depends 
> on undocumented behaviour. 
> 
> I'm proposing the addition of ReflectionFunctionAbstract::isAnonymous(), 
> which would fill this use case, and may be able to offer an implementation. 
> 
> Thanks, 
> Dylan Taylor. 
> 
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
> 

Hi Dylan,

I recently wrote some code checking for “{closure}”: 
https://github.com/amphp/amp/blob/27219ddbc0bbc3fd0db4d7380eaed6489c7291ed/lib/functions.php#L135
 


I agree, it is a bit unpleasant and looks like a hack. I would welcome an 
isAnonymous() method.

Cheers,
Aaron Piotrowski

Re: [PHP-DEV] Bugsnet

[Jakub Zelenka]

On Thu, Oct 21, 2021 at 4:07 PM Nikita Popov  wrote:

>
> I'm proposing the following label structure (the list at
> https://github.com/nikic/test-repo/labels is incomplete though): Each
> report has either a bug or feature label. Additionally it starts out with
> the T-needs-triage label. Once a project member triages the report, the
> label is removed and a category label is added instead, e.g. C-OpenSSL for
> issues relating to the OpenSSL extension.
>
> I also have a few more triage labels (T-needs-feedback, T-verified,
> T-invalid, T-wontfix, T-duplicate), but I'm not sure we actually need any
> but the first one or the first two -- I personally don't see a lot of value
> in having a label for why exactly an issue has been closed, the fact that
> it is closed is usually sufficient.
>
>
Have you considered custom fields that are now in beta with some other
features in https://github.com/features/issues ? That seems a bit nicer to
me...

Regards

Jakub

Re: [PHP-DEV] Bugsnet

[Nikita Popov]

On Sun, May 9, 2021 at 8:49 AM Joe Watkins  wrote:

> Morning internals,
>
> We have a spam problem on bugsnet, it's not a new problem. Nikita had to
> waste time deleting 20 odd messages from bugsnet yesterday and this is a
> common, daily occurrence. We clearly don't have time for this.
>
> Quite aside from spam problems, bugsnet is hidden away in a dark corner of
> the internet that requires a special login, doesn't integrate with source
> code or our current workflow (very nicely), and doesn't get updated or
> developed.
>
> Having moved our workflow to github, now seems to be the time to seriously
> consider retiring bugsnet for general use, and using the tools that are
> waiting for us - Github Issues.
>
> I'm aware that bugsnet serves as the disclosure method for security bugs
> and github doesn't have a solution to that. Leaving that to one side for
> now ...
>
> I'm also aware that bugsnet carries with it 20 years worth of crusty old
> feature requests and bugs, that are never realistically going to be dealt
> with. In the past I've spent time trying to close very old bugs that no
> longer seem relevant, the fact is that there are so many of these that I
> don't think I made a dent.
>
> It seems obvious that we don't want to migrate all of the data on bugsnet,
> but nor do we want to loose the most recent and relevant reports.
>
> I propose that we disable bugsnet for all but security issues leaving
> responsible disclosure method to be handled in some other way at a later
> date. Leaving bugsnet in a (mostly) readonly mode.
>
> We then send a notification to all bugs that were opened against a specific
> and supported version of PHP, notifying the opener of the change and
> requesting that they take a couple of minutes to open their issue on
> github.
>
> I think we might get quite a good response here - anyone suffering the
> worst consequences of bugs - production servers can't be upgraded and so on
> - are already waiting for a notification from bugsnet, I'm sure the
> majority of them will do as we ask.
>
> In some set number of weeks (to be decided), and depending on the response
> to our switching over to github, we can try to determine at that time if
> it's worth trying to import any data from bugsnet. We can also consider at
> this time when it might be appropriate to retire bugsnet entirely.
>
> We will not be free of spam simply by moving, but github has the tools we
> need to moderate the content properly - you can block people. In addition,
> I feel people are less likely to misbehave if they think their co-workers
> or employers might be able to see what they are doing, which may have an
> effect also.
>
> It may be over optimistic, but we might get better engagement with bugs on
> github than anywhere else also - Github is where people are tending to do
> their business today.
>
> Github is maintained, hosted, developed, and free, and while it isn't the
> perfect tool for the job, nothing else is either. We could spend time
> (which we don't have) developing bugsnet, or installing some other solution
> in a dark corner of the internet, and solve no problems at all, and be
> burdened with the ongoing maintenance of that solution.
>
> The people who have to spend the most time on this are release managers,
> and so while I'm talking to everyone, it is release managers opinions that
> I'm most interested in, they are the people who will be and have been most
> effected by the shortcomings in bugsnet, whose opinions are most relevant
> in this space.
>
> I don't think a vote is appropriate, this decision should be made by the
> people whose "jobs" are directly effected - with input from the community,
> of course. Not least of all, it will take a month to close a vote, by which
> time we will have wasted another (working) day or more of Nikitas time.
> Having said all that, I am looking for a consensus before we take any
> action. My arm can be twisted, but this is my current position and I think
> it's a reasonable one.
>
> On the issue of responsible disclosure ... we can treat this separately,
> with the recent change in the workflow, this process is in need of review
> anyway. How that is handled should be decided by the people who have a hand
> in that process, and so it seems prudent to leave it aside for now.
>
> Cheers
> Joe
>

To follow up on this proposal: We have been using GitHub Issue for docs for
a while now (https://github.com/php/doc-en/issues) and I'm about to disable
submission of new docs issues on bugs.php.net. I think it's time to switch
non-security bugs for PHP proper as well, for all the reasons that have
already been discussed.

For docs we didn't really do anything special in terms of labels etc. I
think for the php-src repo we do want to introduce some more structure for
categorization and triage, as the volume tends to be higher there.

For that purpose I've created a prototype of how things could look like
here: https://github.com/nikic/test-repo/issues/new

[PHP-DEV] PHP 8.0.12 Released

[Gabriel Caruso]

The PHP development team announces the immediate availability of PHP
8.0.12. This is a security fix release.

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

For source downloads of PHP 8.0.12 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: <
https://gist.github.com/carusogabriel/6ff51a8439014e0e1f8fb2c0fb3edd4f>

Many thanks to all the contributors and supporters!

Gabriel Caruso & Sara Golemon

php-8.0.12.tar.gz
SHA256 hash:
a5b78f04a89d3b401465febf449c7ea9de48681f92803dd8dc2bf922812d572b
PGP signature:
-BEGIN PGP SIGNATURE-

iQJKBAABCAA0FiEEv93ShkKCT4EY73eQm2elwSIpEY8FAmFuoGoWHGNhcnVzb2dh
YnJpZWxAcGhwLm5ldAAKCRCbZ6XBIikRj8UXEADaHKhWR+TIn5zI0TVrEwOMmgr6
JcaRCqrpsyj050CZCFd50gMRhZx6wXzGlUSMM8dk0ahTbFB63k2/YAvKDfJKVwKc
Ce580V1i1lZNtK3s0GgBkf2QKeKUU27sNNXJIdbbGdWACtqNDsiqR3OMYkZYrcvz
+tGs59UN/tKSK9Uv0O57huQ/8LZKNmIAiDD9RnF1dq/yR6wOYrdkVvrIkern+UUK
rx35+oWzhyPfSxbi1zpULwnJPJenPGvei6SIMYUFC2lZYQCit9EKbafiUmC2Ak4s
Qaybbw0AHbj2I8EVmbnbLnICI3uDE4hSgKJJFed9eYfNZM5/vj/bsx21uPdl16AF
0+bTsb95ReLWF6+OHQyL2JM6/VqT443f/yMW4+Z8xLFmn89idaESH9/yRHSTx4Of
zCBttMF0yPSP2fgEJlRZnE82bl81obwacBzo0ZPU6HWxPgzQAnIcsIzxDEaqdxrh
+ls4Yv6ewRUnuKwWk1qqt4LzI/Ym5mDjT1GDkScc/4n4CXe9G4cVOGpnWhHbNQfx
TZBHD4vjdDh/0huuC/h64dGorNQMdQwC/BCpzhDLDDE/ZScEeEgRtPr7wR5aw5fq
HPepEfJtMVF0LILeWjj8CTfy7pZMzB2XK85xLAvIih0sE42ZNdCzokoPSKel7sWI
PfFW0/8F4hVLpFl6Bw==
=SdLN
-END PGP SIGNATURE-

php-8.0.12.tar.bz2
SHA256 hash:
b4886db1df322dc8fb128d8b34ae7e94f6fc682ecb29ff4f5a591d4de9feadbf
PGP signature:
-BEGIN PGP SIGNATURE-

iQJKBAABCAA0FiEEv93ShkKCT4EY73eQm2elwSIpEY8FAmFuoGwWHGNhcnVzb2dh
YnJpZWxAcGhwLm5ldAAKCRCbZ6XBIikRj9HBD/9rePwk9BNLoRnJGhAjO0th+6LI
HcT88z4KBznM/jKsBMYSdr8TJ9OdiZsOj4rmNSD288nDD7MayH169jhDGSezS2Ze
Ywi4KUU41STIfOKBv9pzLYV4Q6QJkicNxf2yRbk1x5pKbQlXPU1ddPJK2Vy+xKZQ
XMUKrd5p1Dlp06ER7YDochKKa9VS2cq9Hpztv8MBdH7z6TTvUl3Tvynh/bpSLd43
rlTHJ00+M1ngugzbwTVayR0lEcr8s5ffHS60yxytglGeahRtan6SBV+51Uh0NZ3s
wToOhFkqW9JBuLHLUTpwf3fhYTD06P117VW9NMGsoZ3OkvL4cjn+M04rbG1QUhWu
QvlU3apapEZQjEmAuU0MCKnQ+4oodt8oWzniHLCA/l7c/6HqKvWfdEE5uDhrKuro
XRIsNeLs6sKTQRQ/0wrCoL+E4ch5g9W2v7es4MVIyPCqsXv0HErV/o6+GxS/WA4M
X1sbAX2WSzURXZI68K6n8T3dr9D3p8EHGjjhsu/7+gzugrYZ2y4lDgfiEV2+fJVl
80ex2uReJ9glgB31pXFf1ljSwffW+ACYfEOo4M3IlXt8HbR3XepD7ACCk9XkLuWh
i3hlg+hRq1aq3JXxMumgy2Nc7a7Lb3Vy+EFS3e20AvaVRcwN5WsspJIrxy9el5YL
pYigU5ALcXCA46tphg==
=7ZXs
-END PGP SIGNATURE-

php-8.0.12.tar.xz
SHA256 hash:
a501017b3b0fd3023223ea25d98e87369b782f8a82310c4033d7ea6a989fea0a
PGP signature:
-BEGIN PGP SIGNATURE-

iQJKBAABCAA0FiEEv93ShkKCT4EY73eQm2elwSIpEY8FAmFuoG0WHGNhcnVzb2dh
YnJpZWxAcGhwLm5ldAAKCRCbZ6XBIikRjxjQD/sGTgFpSKoagCXxAogMlkgZCSLT
3vC3LgxJN942k/gAhKRsUlm/hyaFa2va6AeC32MQGZbXStReuYdt+CgdyWdfe9qq
b26DaOS5+aIlhTm4pJZM8roRByCC3qFFjvV4MeUzSyeOd9HQskBc4X9Ti7qOjfqa
xOrRPcBSdqlNsPIdQfOxMM1LG3h1814/Frbxr1nmXNdaAExgYy6Z6nYZGpfKS2V6
v9ATxYyL2MA7jWSAQVrNy9S71iZm0A3LKjZRtWBjsAxguZz/oEEwzxKV7rDvBbeS
GLYx6Rir2WkVDF6yBhVVoYI41k+I7ocEVoj4gJG6Jrom3oQeJOMSA9TNKGtiCJzq
LQ49OnAqoh0+GME+uGDSvCUBS5PGebbK5gb18tOkjj694sEUZwdyXKW1N5o/pn4J
FtVYTZVKNnX/1iEf6bV25C3DWor0bg2jhsJRk5gS0lFmXG66RHC2iAiry0JQEWJ4
RWAUeCzBhDWUBj2bF9DIv/03xjCIzKF/sozJwlwP1E/ah8/V5PAwkuCiprmVcpOt
wojFYNboUsA/69weuRMcEKZs116m3sjWGG/cym2vMIphmKShGDknsVpaUv7GqSJB
kyUk6+hMEqe8VMhnvbtD10kK9ffTT6ps5U2mRmDh1tngAWb8NEy2pzms4IcM4Q6e
DfTGg14dPVpbl4CeXQ==
=T8N9
-END PGP SIGNATURE-

Re: [PHP-DEV] Add ReflectionFunctionAbstract::isAnonymous()

[Nikita Popov]

On Thu, Oct 21, 2021 at 1:12 AM Dylan K. Taylor  wrote:

> Hi all,
>
> Given the addition of Closure::fromCallable() and the upcoming first-class
> callable syntax in 8.1, it seems slightly problematic that there's no
> simple way to tell by reflection if a Closure refers to an anonymous
> function or not. ReflectionFunctionAbstract::isClosure() (perhaps somewhat
> misleadingly) returns whether the closure is literally a \Closure instance,
> so it's not useful for this purpose.
>
> The only way to do this currently (that I know about) is to check if the
> name of the function contains "{closure}", which is a bit unpleasant and
> depends on undocumented behaviour.
>
> I'm proposing the addition of ReflectionFunctionAbstract::isAnonymous(),
> which would fill this use case, and may be able to offer an implementation.
>

Sounds reasonable to me!

Nikita