On 1 Feb 2019, at 18:30, Larry Garfield
mailto:la...@garfieldtech.com>> wrote:
I'm... not sure how that answers my question? I'm saying "if we had a VM+JIT,
and the JIT part made feature X acceptably fast but it wasn't acceptably fast
with just the VM, is that a problem?" Or is that a situatio
> On 3 Feb 2019, at 7:17, Ben Ramsey wrote:
>
>> On Thu, Jan 31, 2019, at 11:04, Zeev Suraski wrote:
>> I'm honestly a bit perplexed by how many people here viewing Windows
>> support as a must have, while at the same time I think we all agree PHP is
>> very scarcely found on production Windows
On Fri, Feb 1, 2019 at 7:14 PM Dan Ackroyd wrote:
> On Thu, 31 Jan 2019 at 13:44, Zeev Suraski wrote:
> >
> > Without further ado, an RFC that’s attempting to comprehensively solve
> many of the issues that have plagued our RFC process since it was hastily
> introduced in 2011:
>
> Hi Zeev,
>
>
> -Original Message-
> From: Nikita Popov
> Sent: Saturday, February 2, 2019 6:24 PM
> To: PHP internals
> Subject: [PHP-DEV] Alternative voting reform: Streamlining the RFC process
>
> Hi internals,
>
> After discussing the topic with a number of current and former contributors, I
>
On Thu, Jan 31, 2019, at 11:04, Zeev Suraski wrote:
> I'm honestly a bit perplexed by how many people here viewing Windows
> support as a must have, while at the same time I think we all agree PHP is
> very scarcely found on production Windows servers, and JIT is a
> predominantly production featur
On Sat, Feb 2, 2019 at 1:06 PM Peter Kokot wrote:
> >> 3. Do you know where is the source code of these two scripts? When the
> >> upstream script gets updated it would be then useful to copy/paste
> >> changes into php-src. So the main development should be happening
> >> upstream anyway. Meanin
Now THIS is a sensible proposal! It resolves the biggest issues in a very
simple and straightforward manner. And unlike the other RFC, this proposal
does not feel like an exclusionary power grab.
--Kris
On Sat, Feb 2, 2019, 8:24 AM Nikita Popov Hi internals,
>
> After discussing the topic with
I think I heard some stat that over 50% of Azure now runs Linux (and I am sure
PHP is primarily running on Linux). So given JIT probably helps 95% of
production PHP installations I wouldn’t hold this back. If Windows ends up
being important to folks some (and possibly msft) will contribute that.
On Sa, 2019-02-02 at 01:20 -0500, Bishop Bettini wrote:
> So, how do we identify those who are currently the most contributory?
> Commits mostly, though we can't ignore other qualities. In a 2003
> paper[1], Scacchi (UC Irvine) defined a F/OSS meritocracy pyramid in
> which those at the top had the
>> 3. Do you know where is the source code of these two scripts? When the
>> upstream script gets updated it would be then useful to copy/paste
>> changes into php-src. So the main development should be happening
>> upstream anyway. Meaning away from the PHP.
>
>
> I don't know what to say on that.
On Sa, 2019-02-02 at 21:52 +0100, Legale.legale wrote:
> For example:
> phpenmod mysqli
> will try to find an extension and if it exists, script will create
> related ini file in the conf.d directory.
> phpdismod mysqli
> will remove ini file from the conf.d dir.
>
> It makes a world a bit more co
For example:
phpenmod mysqli
will try to find an extension and if it exists, script will create related ini
file in the conf.d directory.
phpdismod mysqli
will remove ini file from the conf.d dir.
It makes a world a bit more comfortable for me. :-)On Feb 2, 2019 21:39,
Stanislav Malyshev wrote:
Hi!
On 2/2/19 12:34 PM, Legale Legage wrote:
> These scripts allow you to enable/disable php shared extensions.
What you mean by enable/disable? Could you describe a use case for why
this script would be used by a developer? Or is this meant for the user
- then why the script would be used by the
These scripts allow you to enable/disable php shared extensions.
On Sat, 2 Feb 2019 at 21:00, Stanislav Malyshev wrote:
> Hi!
>
> >> I want to propose including to the bundle phpenmod/phpdismod scripts.
> These
>
> I'm sorry but what these scripts are? What do they do?
>
> --
> Stas Malyshev
> s
On Sat, 2 Feb 2019 at 20:57, Peter Kokot wrote:
> On Sat, 2 Feb 2019 at 20:24, Legale Legage
> wrote:
> >
> > Hello, internal.
> >
> > I want to propose including to the bundle phpenmod/phpdismod scripts.
> These
> > scripts are included to the standard deb/rpm packages. What do you think
> > ab
Hi!
>> I want to propose including to the bundle phpenmod/phpdismod scripts. These
I'm sorry but what these scripts are? What do they do?
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
As a man, being a user at 99%. it has always been very important to have
such useful things.
At the moment bundle is already generating init.d and systemd scripts. So
why not phpenmod / phpdismod?
I think usability can not be too much.
Sincerely,
Ruslan
On Sat, 2 Feb 2019 at 20:37, Joe Watkins
On Sat, 2 Feb 2019 at 20:24, Legale Legage wrote:
>
> Hello, internal.
>
> I want to propose including to the bundle phpenmod/phpdismod scripts. These
> scripts are included to the standard deb/rpm packages. What do you think
> about including them to the bundle?
>
> If the idea is worthwhile, I w
Hi Legale,
In general we leave the packaging of PHP to the packaging experts. So I
doubt if there's much need to include these in php-src, but let's see what
others have to say ?
Cheers
Joe
On Sat, 2 Feb 2019 at 20:24, Legale Legage wrote:
> Hello, internal.
>
> I want to propose including to
Hello, internal.
I want to propose including to the bundle phpenmod/phpdismod scripts. These
scripts are included to the standard deb/rpm packages. What do you think
about including them to the bundle?
If the idea is worthwhile, I will make the RFC.
Saluti, Ruslan
Hi Nikita,
I can't be helpful here at all, because (shamefully) allergic to and bad at
windows, and no experience at all with azure.
But I would really like our CI to be restored to a thing that's useful,
instead of running two jobs on travis, and more or less nothing on av (most
of the time).
I
Hi!
> I just learned about the Azure Pipelines (
> https://azure.microsoft.com/en-us/services/devops/pipelines/) offering,
> which offers open source projects 10 parallel builds with unlimited
> minutes. Assuming there's no other catch here, it might be worthwhile to
> migrate our Windows CI jobs
On 02/02/2019 01:08, Alice Wonder wrote:
That version has vulnerability, developer fixed it in newer release,
but composer keeps pulling in the older version because that is what
composer provides.
Have you seen
https://packagist.phpcomposer.com/packages/roave/security-advisories ?
It's a
Just a quick note ...
I should say that bug fixes should not require an RFC at all, but the line
between bug, quick fix and feature is blurry. Sometimes it is necessary to
gather consensus and voting is the most effective way we have to do that.
Cheers
Joe
On Sat, 2 Feb 2019 at 18:13, Joe Watkin
Hi Legale, internals,
> I want to say that even a small and fairly
simple code change,
which I proposed to push through the bureaucracy, was difficult.
This, I am afraid is all too common. Many many times, while working through
github issues, I will be uncomfortable with making a merge for someon
Hello, internals.
I am with you recently. But as a person with a fresh look, let me insert my
5 penny coin.
About half a year ago, I knew about the C language only that such a
language exists.
The reason I decided to contribute is curiosity. So I'm probably not as
motivated
as some of other interna
сб, 2 февр. 2019 г. в 18:24, Nikita Popov :
> Hi internals,
>
> After discussing the topic with a number of current and former
> contributors, I feel that the workflow & voting RFC currently under
> discussion is moving us in the wrong direction. I will not comment on the
> rather questionable pro
On 02.02.2019 at 16:32, Lester Caine wrote:
> On 02/02/2019 14:28, Peter Kokot wrote:
>
>> About PECL, then I assume we keep it as is for this period also.
>> Unclear, required to install PEAR to be able to run the pecl command,
>> and optionally moving this part elsewhere out of the PHP. Speciall
Afternoon Nikita, internals,
In stark contrast to the proposals being made to make contributing to PHP
more complex, slower, and burdened with bureaucracy: These are elegant
proposals that I think will invite new contributors to join our ranks,
which we no doubt need. They will allow current contr
Hi internals,
After discussing the topic with a number of current and former
contributors, I feel that the workflow & voting RFC currently under
discussion is moving us in the wrong direction. I will not comment on the
rather questionable proposed changes to voting eligibility, as these are
alread
Insofar as conversation started what do you think about CI service that
supports big endian platform?On Feb 2, 2019 15:09, "Christoph M. Becker"
wrote:
>
> On 02.02.2019 at 14:31, Nikita Popov wrote:
>
> > On Sat, Feb 2, 2019 at 2:06 PM Christoph M. Becker
> > wrote:
> >
> >> On 02.02.2019
On 02/02/2019 14:28, Peter Kokot wrote:
About PECL, then I assume we keep it as is for this period also.
Unclear, required to install PEAR to be able to run the pecl command,
and optionally moving this part elsewhere out of the PHP. Specially,
to package maintainers (Linux distros), another repos
Hello,
I understand we won't be able to reach common understanding about
PEAR. But anyway, first of all, thanks for all the answers and
informational feedback.
I'd just like to remind everyone one thing. We're now on a good way to
reach another 7+ years [1] of keeping PEAR in the PHP core with al
On 02.02.2019 at 14:31, Nikita Popov wrote:
> On Sat, Feb 2, 2019 at 2:06 PM Christoph M. Becker
> wrote:
>
>> On 02.02.2019 at 13:18, Nikita Popov wrote:
>>
>>> I just learned about the Azure Pipelines (
>>> https://azure.microsoft.com/en-us/services/devops/pipelines/) offering,
>>> which offer
On Sat, Feb 2, 2019 at 2:06 PM Christoph M. Becker
wrote:
> On 02.02.2019 at 13:18, Nikita Popov wrote:
>
> > Since some time ago (not sure how long) our AppVeyor builds have been
> > timing out more often than not, to the point that I've started ignoring
> > failing AppVeyor builds entirely.
>
>
On 02.02.2019 at 13:18, Nikita Popov wrote:
> Since some time ago (not sure how long) our AppVeyor builds have been
> timing out more often than not, to the point that I've started ignoring
> failing AppVeyor builds entirely.
Indeed, this is particularly annoying for RMs.
> I just learned about
Hi internals,
Since some time ago (not sure how long) our AppVeyor builds have been
timing out more often than not, to the point that I've started ignoring
failing AppVeyor builds entirely.
I just learned about the Azure Pipelines (
https://azure.microsoft.com/en-us/services/devops/pipelines/) of
On 2.02.19 г. 3:41 ч., Johannes Schlüter wrote:
On Do, 2019-01-31 at 14:28 -0500, Bishop Bettini wrote:
2. Core developers are defined as the top 13 committers within the
period of two years since voting began. A core developer is a de
facto
community member, but caucuses as a core
I was precisely hoping there was a WeakRef implementation the other day.
This would be very useful for a simple data mapper, where you could keep
references to loaded objects and a cache of their original properties, to
compute the changeset to sync to the DB when save()ing them.
WeakRefs would all
On 02/02/2019 02:10, Peter Kokot wrote:
Composer is like static linking compared to PEAR which is liked shared
linking.
Composer can install things globally. I'm not sure I understand why is
this even a discussion Composer vs. PEAR core installer script at the
moment. The pull request is about
On Fri, Feb 1, 2019 at 12:27 PM Nikita Popov wrote:
> Hi internals,
>
> I would like to suggest that installation of PEAR is disabled by default
> in PHP 7.4. PR: https://github.com/php/php-src/pull/3781
>
> I think the reasons for this should be obvious. It's not really the recent
> security bre
Hi!
> 1) Please see my earlier message. The way FIG is structured, one could
> extend
> voting rights to project representatives, the core committee, both, or
> neither. The core committee is 12 people. Project reps are ~36 currently.
> Adding 12 people to the voting pool would not "effect
Morning internals,
Some time ago I brought this up for discussion, and last night was reminded
of it's existence, and so this morning rebased and reworked the patch a
little based on the feedback I got back then.
Since it was long ago, and there's no particular rush, I don't intend to
open voting
> Composer took over the role of such installer in PHP community.
But sadly "composer" is NOT an installer.
(it is a Dependency Manager for PHP)
Ex: not having "role" for files is a nightmare, and make necessary to
use terrible workaround (such as using .gitattributes), and thus making
PHP dev
44 matches
Mail list logo
