> On Mar 29, 2021, at 1:25 PM, Ilija Tovilo wrote:
>
> Hi Matthew
>
>> Ondřej Mirtes and I present an RFC for the noreturn type:
>> https://wiki.php.net/rfc/noreturn_type
>>
>> The feature already exists in Hack (the primary inspiration) and is
>> currently supported by our static analysis too
Hi!
On 3/29/21 4:49 AM, Max Semenik wrote:
On Mon, Mar 29, 2021 at 1:53 AM Nikita Popov wrote:
changes should be pushed directly to GitHub rather than to git.php.net.
Would it also make sense if direct pushes (bypassing the pull requests
system) were disallowed completely? I can see multip
Den 2021-03-29 kl. 23:10, skrev Benjamin Morel:
Hi everyone,
Yesterday (2021-03-28) two malicious commits were pushed to the php-src
repo [1] from the names of Rasmus Lerdorf and myself. We don't yet know how
exactly this happened, but everything points towards a compromise of the
git.php.net s
>
> Hi everyone,
>
> Yesterday (2021-03-28) two malicious commits were pushed to the php-src
> repo [1] from the names of Rasmus Lerdorf and myself. We don't yet know how
> exactly this happened, but everything points towards a compromise of the
> git.php.net server (rather than a compromise of an
Hi Matthew
> Ondřej Mirtes and I present an RFC for the noreturn type:
> https://wiki.php.net/rfc/noreturn_type
>
> The feature already exists in Hack (the primary inspiration) and is
> currently supported by our static analysis tools inside docblocks, and we
> feel there's a good argument for it
If there are no more questions, we plan to open up voting for this on Tuesday
March 30. There will be two votes — a 2/3 majority required for the feature,
and a simple majority required for the name — “noreturn” vs “never”.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, v
On Mon, 29 Mar 2021 at 12:50, Max Semenik wrote:
> On Mon, Mar 29, 2021 at 1:53 AM Nikita Popov wrote:
>
> > changes should be pushed directly to GitHub rather than to git.php.net.
>
>
> Would it also make sense if direct pushes (bypassing the pull requests
> system) were disallowed completely?
On Mon, Mar 29, 2021 at 1:53 AM Nikita Popov wrote:
> changes should be pushed directly to GitHub rather than to git.php.net.
Would it also make sense if direct pushes (bypassing the pull requests
system) were disallowed completely? I can see multiple problems with direct
pushes:
1) Someone tr
> For userland, there are already ways to declare the planned return type
> (aka @return in phpdoc), so we might not need any new way to declare this
> from the engine pov.
>
Yes, I think I agree, but I'd be curious about Nikita's opinion as well,
since he brought up this problem first.
> We sho
On Mon, 29 Mar 2021, 08:51 Paul Dragoonis, wrote:
>
>
> On Mon, 29 Mar 2021, 02:30 Rasmus Lerdorf, wrote:
>
>> On Sun, Mar 28, 2021 at 17:15 Sara Golemon wrote:
>>
>> > On Sun, Mar 28, 2021 at 6:57 PM Paul Crovella
>> > wrote:
>> >
>> >> You might consider requiring commits be signed while you
On Mon, 29 Mar 2021, 02:30 Rasmus Lerdorf, wrote:
> On Sun, Mar 28, 2021 at 17:15 Sara Golemon wrote:
>
> > On Sun, Mar 28, 2021 at 6:57 PM Paul Crovella
> > wrote:
> >
> >> You might consider requiring commits be signed while you're at it.
> >>
> >>
> > I suggested this as well, and even if we
Den man. 29. mar. 2021 kl. 01.52 skrev Nikita Popov :
> While previously write access to repositories was handled through our
> home-grown karma system, you will now need to be part of the php organization
> on GitHub. If you are not part of the organization yet, or don't have access
> to a repo
I think you only need to handle merges locally if the pull request author
didn't sign their commits:
> You can always push local commits to the branch if the commits are signed
and verified.
> You can also merge signed and verified commits into the branch using a
pull request on GitHub.
> However,
13 matches
Mail list logo
