Re: [PHP-DEV] Improving productivity of internals mailing list

On 18 September 2019 18:33:19 BST, Dan Ackroyd wrote: ># Problem 2 - Some threads are not a good fit for a mailing list. > ... >We should move as many conversations off the internals list as we can, >while still retaining ways of people finding where those conversations >are being held. > ...

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

Hi! > Another thing I feel I have to emphasize here. This has absolutely > nothing to do with successful 7.4 release. If from now on internals Unless I am missing something and we do have still unresolved issues that block the release? Then we probably should go back to figuring them out and not

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

Hi! > This is a stop-gap measure to allow us to use the internals newsgroup > to be able to ship PHP 7.4 successfully. Another thing I feel I have to emphasize here. This has absolutely nothing to do with successful 7.4 release. If from now on internals became so bad we could literally agree on

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

Hi! > Please can you look at the past 3 months of discussions on this list > and ask yourself have those conversations been productive and/or > pleasant? Do you think other people think those conversations have > been productive and/or pleasant? I've seen a lot of conversations here, both

Re: [PHP-DEV] PHP 7 + bcgen extension + PHAR extension

On Wed, Sep 4, 2019 at 8:44 AM Henrik Skov wrote: > I found a port of bcompiler here: > > https://github.com/vjardin/bcgen/ > > which is PHP7 compatible. > > By mailing here, I am trying to reach out to the authors of the PHAR > extension since the author(s) of bcgen have said that they don't

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

On Fri, Sep 20, 2019 at 2:24 PM Benjamin Eberlei wrote: > > > On Fri, Sep 20, 2019 at 11:53 AM Zeev Suraski wrote: > This style of conversation has regularly lead to contributors that don't > want the intensity quit contributing silently. It is not healthy for this > community. > > Just because

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

> On Sep 20, 2019, at 01:25, Brent wrote: > > Moderators are no dictators Maybe, maybe not. But moderators can and do play favorites, banning or silencing one voice (of whom they disapprove) for the same things that they ignore from another voice (of whom they do approve). Moderators,

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

On Fri, Sep 20, 2019 at 11:53 AM Zeev Suraski wrote: > Andreas, all, > > Speaking of 'disruptive behavior' that the antithesis of promoting 'good > will' - this pseudo RFC is a textbook example. > But some of the responses on the thread are actually more interesting and > nicely written and do

Re: [PHP-DEV] Re: Question about merged PR #937

Can you let us know what you used as it's doing the job well :) CLI git merge or another UI; which one? I'm also curious what will happen if there would be two authors on the same branch/pull request. Is it interactive or pre-configured to use author of the first commit, last commit, most of the

Re: [PHP-DEV] Re: Question about merged PR #937

On 20.09.2019 at 12:35, Alexandru Pătrănescu wrote: > Was this squash done during merging of a github pull request? Yes, it was when applying . I didn't use the Github UI, though. -- Christoph M. Becker -- PHP Internals - PHP Runtime Development

Re: [PHP-DEV] Re: Question about merged PR #937

Hi Christoph, Was this squash done during merging of a github pull request? On Fri, Sep 20, 2019 at 1:06 PM Christoph M. Becker wrote: > On 20.09.2019 at 11:22, Alexandru Pătrănescu wrote: > > > I was quick to write an answer and forgot to search for a more detailed > > explanation online,

Re: [PHP-DEV] Re: Question about merged PR #937

On 20.09.2019 at 11:22, Alexandru Pătrănescu wrote: > I was quick to write an answer and forgot to search for a more detailed > explanation online, being busy with some other work tasks. > Github explains it here: > https://help.github.com/en/articles/about-merge-methods-on-github > > Before

[PHP-DEV] Unify mail related tests for *nix and Windows

Hi all! Currently our mail related tests (in ext/standard/tests/mail/ and maybe other locations) are split for *nix and Windows (if there are even Windows versions). The basic difference is that the *nix variants set the INI directive sendmail_path to just write the email to disk (some

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

Andreas, all, Speaking of 'disruptive behavior' that the antithesis of promoting 'good will' - this pseudo RFC is a textbook example. But some of the responses on the thread are actually more interesting and nicely written and do warrant a response. On Fri, Sep 20, 2019 at 10:14 AM Andreas Heigl

Re: [PHP-DEV] Re: Question about merged PR #937

I was quick to write an answer and forgot to search for a more detailed explanation online, being busy with some other work tasks. Github explains it here: https://help.github.com/en/articles/about-merge-methods-on-github Before enabling squashing commits, consider these disadvantages: > >-

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

On Fri, 20 Sep 2019 at 06:50, Stanislav Malyshev wrote: > > I am not sure what is the purpose of this. Please can you look at the past 3 months of discussions on this list and ask yourself have those conversations been productive and/or pleasant? Do you think other people think those

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

On Fri, 20 Sep 2019 at 08:30, Midori Koçak wrote: > > A RFC that it's motivation is to prevent beginners from asking questions. Asking questions by itself is not a problem. It only becomes a problem when those questions are taking up a lot of other people's time and making it difficult to even

[PHP-DEV] Re: Question about merged PR #937

On 19.09.2019 at 19:20, guilhermebla...@gmail.com wrote: > Thanks for the clarification Christoph! > Somehow I couldn't see it when looking for the commit hash. Sorry for > the disturbance in the list here. > > PS: I find it funny that even though I'm the original author of the > code, I don't

Re: [PHP-DEV] Re: Question about merged PR #937

Hi Nikita, Yes, you are right that the author (and not the committer) is the one taken in considerations for git blame and contributor display. Committer is just technical and related to who created/recreated a commit. But, unfortunately, you are wrong in believing that the author is preserved

Re: [PHP-DEV] Should changes to EXTENSIONS be with a direct master commit?

On Fri, Sep 20, 2019 at 6:48 AM Bishop Bettini wrote: > I've got the change below staged locally, but as you can see it's direct to > master. Since that's an atypical workflow, and a first time for me, I > wanted to check before I push. > > --- BEGIN git log --- > commit

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

Hey Midory, Hey all. Am 20.09.19 um 09:30 schrieb Midori Koçak: > Wow. > > A RFC that it's motivation is to prevent beginners from asking questions. Is it? I'm citing from the RFC: > This explicitly wouldn't apply to 'positive' conversations. e.g. if someone > asks for help, and you want to

Re: [PHP-DEV] Re: Question about merged PR #937

On Fri, Sep 20, 2019 at 12:50 AM Alexandru Pătrănescu wrote: > Hi Guilherme, > > That is what is happening when squashing commits during merge. > > I noticed this also few months ago but didn't mentioned it as I though this > is one of the usual flows. > I quickly searched it now and found it

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

Wow. A RFC that it's motivation is to prevent beginners from asking questions. That's horrible. I rather prefer a CoC. What about this? https://confcodeofconduct.com/ On Thu, 19 Sep 2019 at 19:19, Dan Ackroyd wrote: > Hi internals, > > Here is an RFC to "Prevent disruptions of

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

Hey Stas, Hey All. Am 20.09.19 um 08:00 schrieb Stanislav Malyshev: > Hi! > >> taken part of). So given that track record, along with how the project >> philosophy generally is, I do not see abuse being a problem, even the >> sligtest. > > There are a lot of things that I thought our project

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

internals@ needs what every community needs: proper moderation. Moderators are no dictators who will force their opinion on how the language is shaped, nor will they silence people with fear. This is no alien concept on the internet, and nothing ground breaking or disruptive is being proposed.

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

Hi! > taken part of). So given that track record, along with how the project > philosophy generally is, I do not see abuse being a problem, even the > sligtest. There are a lot of things that I thought our project philosophy does not admit, but turns out I have been wrong. I don't see why if we