Re: [PHP-DEV] Changing PECL signup flow.

[Johannes Schlüter]

On Thu, 2019-09-19 at 13:06 +0100, Dan Ackroyd wrote:
> Johannes wrote:
> > I think we should clarify what PECL actually is.
> > Without such a tool the need for a central distribution
> > site goes away
> 
> I think there is still a large amount of value in PECL being 'merely'
> a distribution channel. My understanding is that downstream
> maintainers find it far easier to pickup versions from pecl than
> picking up individual repos.

Correct. One thinking is that we make PECL a simple directory, where we
allow everybody to register stuff and don't care further (modulo
legal/abuse issues)

At the moment PECL is in some weird between state. In the past, when I
was more involved, I tried to do basic reviews and use PECL as vehicle
to help getting developers into php-src, by teaching some best
practices and where to look and having some personal relationship to
the people. PECL historically, as said, also was about php.net taking
at least co-ownership.

> Plus of course it helps prevent extensions from disappearing.

Good point - while the question is what it's worth to keep it around in
unmaintained state.

> Johannes wrote:
> > from php-src point of view PECL is the graveyard
> > where extensions go for their final rest.
> 
> ಠ_ಠ
> 
> Some of us maintain extensions on PECL quite happily thank-you. /s
> 
> Seriously though, I think one of the main reasons why that view isn't
> totally wrong is that it's just been so hard for people to create
> pecl
> accounts that it's caused people to not publish their extensions
> there.

To be clear that was overstated and was in order to describe the
contrast to a previous use as incubator. php-src also wasn't meant to
refer to people but literally the code repo. (in CVS days incubating in
PECL worked in the way that extensions was developed in PECL and after
some time the repo was moved into php-src with a single literal `mv` on
the CVS server)

> Arnold Daniels wrote:
> 
> > As an alternative, maybe we can create a new channel
> 
> I strongly support anyone that wants to work on that, particularly
> since PECL is deprecated due to it's reliance on PEAR. However that
> really needs to be a separate topic than just fixing the immediate
> problem of the PECL signup process being too much of a gate-keepered
> experience currently.

Not sure what "channel" means - especially as we are losing out current
installer ;-)

> Johannes wrote:
> > Or is ffi the big push for those 95% making pecl actually mostly
> > obsolete,
> 
> I also haven't had time to investigate FFI yet, however the feedback
> I
> have seen from other people is that there are quite a few issues
> around the ecosystem when trying to use it, that are going to limit
> how useful it is for a while. But that is a conversation that other
> people will need to pickup.

Interesting.

> I'm not sure the idea I suggested actually requires an RFC, and I'm
> in

I don't participate in that debate.

johannes

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

Re: [PHP-DEV] Changing PECL signup flow.

[Dan Ackroyd]

Johannes wrote:
> I think we should clarify what PECL actually is.
> Without such a tool the need for a central distribution
> site goes away

I think there is still a large amount of value in PECL being 'merely'
a distribution channel. My understanding is that downstream
maintainers find it far easier to pickup versions from pecl than
picking up individual repos.

Plus of course it helps prevent extensions from disappearing.

Johannes wrote:
> from php-src point of view PECL is the graveyard
> where extensions go for their final rest.

ಠ_ಠ

Some of us maintain extensions on PECL quite happily thank-you. /s

Seriously though, I think one of the main reasons why that view isn't
totally wrong is that it's just been so hard for people to create pecl
accounts that it's caused people to not publish their extensions
there.

Arnold Daniels wrote:

> As an alternative, maybe we can create a new channel

I strongly support anyone that wants to work on that, particularly
since PECL is deprecated due to it's reliance on PEAR. However that
really needs to be a separate topic than just fixing the immediate
problem of the PECL signup process being too much of a gate-keepered
experience currently.

Johannes wrote:
> Or is ffi the big push for those 95% making pecl actually mostly obsolete,

I also haven't had time to investigate FFI yet, however the feedback I
have seen from other people is that there are quite a few issues
around the ecosystem when trying to use it, that are going to limit
how useful it is for a while. But that is a conversation that other
people will need to pickup.


I'm not sure the idea I suggested actually requires an RFC, and I'm in
the middle of a few too many things to pursue it right now, but I've
added it to the list at:
https://github.com/Danack/RfcCodex/blob/master/project_coordination.md#smoother-pecl-signup-process
so it doesn't get forgotten.

cheers
Dan
Ack

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

Re: [PHP-DEV] Changing PECL signup flow.

[Johannes Schlüter]

On September 18, 2019 3:32:38 PM GMT+02:00, "Christoph M. Becker" 
 wrote:
>On 18.09.2019 at 15:22, Johannes Schlüter wrote:
>
>> The Windows builds are also a relevant factor in the discussions
>> regarding the PECL site. Afaik (Anatoliy and others know better than
>> me) packages uploaded to the pecl site are being built in the same
>> setup as our official PHP runtime Windows builds.
>
>The PECL builds are done on another VM than the Windows builds.


Good to know. If not done another got thing is if each build runs in its own 
container or from a clean VM snapshot or whatever capabilities there are for 
Windows ...

Anyways different topic in itself. Just came to mind while thinking about the 
pickle tool. And possible future paths. 

One thought in my head (also away from the initial question) is also whether we 
could provide Linux builds - since removing TSRM it came closer to being 
feasible to have a stable common interface for 95% of extensions. (There are 
the ones which go deep ... but for most the only thing they have to interact 
with is a zval which is relatively stable and a class_entry+zend_object where 
most things should be wrapable behind accessor functions with stable API) If we 
just need one single build with static dependencies covering most systems (some 
(g)libc dependency ... while glibc has versions APIs and quite good 
compatibility these days) this could cover the 80/20 case.

Or is ffi the big push for those 95% making pecl actually mostly obsolete, 
solving the whole thing that way round? (I admit - I never looked at FFI) Then 
only extensions "going deep" (xdebug, mysqlnd stuff, runkit-like, ...) need 
some distribution channel, while ffi code could use packagist/composer.

johannes

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

Re: [PHP-DEV] Changing PECL signup flow.

[Christoph M. Becker]

On 18.09.2019 at 15:22, Johannes Schlüter wrote:

> The Windows builds are also a relevant factor in the discussions
> regarding the PECL site. Afaik (Anatoliy and others know better than
> me) packages uploaded to the pecl site are being built in the same
> setup as our official PHP runtime Windows builds.

The PECL builds are done on another VM than the Windows builds.

> Not sure how well
> that image is protected against bad actors doing nasty stuff in their
> build scripts. Thus some oversight about who can push code up there
> might be good.

Indeed, something to consider.  The build code is publicly available,
btw.: .

--
Christoph M. Becker

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

Re: [PHP-DEV] Changing PECL signup flow.

[Johannes Schlüter]

On Mon, 2019-09-16 at 11:13 +0200, Christoph M. Becker wrote:
> 
> For the record, there is already
> , but that project looks like
> it has fallen asleep.
> 


Right and contrary to the old PECL/PEAR tool this  can also fetch the
precompiled Windows binaries afaik.

The Windows builds are also a relevant factor in the discussions
regarding the PECL site. Afaik (Anatoliy and others know better than
me) packages uploaded to the pecl site are being built in the same
setup as our official PHP runtime Windows builds. Not sure how well
that image is protected against bad actors doing nasty stuff in their
build scripts. Thus some oversight about who can push code up there
might be good.

johannes

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

Re: [PHP-DEV] Changing PECL signup flow.

[Christoph M. Becker]

On 16.09.2019 at 10:30, Arnold Daniels wrote:

> As an alternative, maybe we can create a new channel which works more like 
> [packagist.org](https://packagist.org/). For now, it could still work with 
> the `pecl` cli.
>
> For community acceptance, it would be good if the channel was configured by 
> default, similar to pecl.php.net.
>
> Where packagist only shows the README, the site of this channel could support 
> showing the full documentation written in Docbook, markdown, html and other 
> formats.
>
> From there, we can start thinking about / discussing phasing out pecl.php.net.

For the record, there is already
, but that project looks like it
has fallen asleep.

--
Christoph M. Becker

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

Re: [PHP-DEV] Changing PECL signup flow.

[Arnold Daniels]

As an alternative, maybe we can create a new channel which works more like 
[packagist.org](https://packagist.org/). For now, it could still work with the 
`pecl` cli.

For community acceptance, it would be good if the channel was configured by 
default, similar to pecl.php.net.

Where packagist only shows the README, the site of this channel could support 
showing the full documentation written in Docbook, markdown, html and other 
formats.

From there, we can start thinking about / discussing phasing out pecl.php.net.

[Arnold Daniels - Chat @ 
Spike](https://www.spikenow.com/?ref=spike-organic-signature&_ts=5wbzz)
[5wbzz]

On September 16, 2019 at 2:40 GMT, Johannes Schlüter  
wrote:

Re: [PHP-DEV] Changing PECL signup flow.

[Johannes Schlüter]

On Sun, 2019-09-15 at 18:11 +0100, Dan Ackroyd wrote:
> HI internals,
> 
> Currently, it is quite difficult to signup to get a PECL account.
> 
> We have a somewhat deliberately obtuse form to signup through, which
> then needs to be manually approved by someone with the appropriate
> karma.

I think we should clarify what PECL actually is. Classically, in the
pre-GitHub days, PECL was not only a distribution channel for PHP
extensions, but part of the PHP project. This meant that "we" (php.net
community) as owners of the content could handle passing maintenance
over to other people, had the commit list for doing passive code
reviews and could do mass edits as in 
http://svn.php.net/viewvc?view=revision&revision=297236 on API changes.

PECL was also incubator where extensions could be developed before
being merged. By already being on php.net this was easy from license
and similar things. Nowadays we're less likely to bundle extensions,
but from php-src point of view PECL is the graveyard where extensions
go for their final rest.

With splitting from the single svn repo to multiple git repos and with
rising popularity of GitHub this changes and PECL merely becomes a
distribution platform ... 

However we recently deprecated the distribution tool (pecl installer
aka. pear installer)  without having a replacement. Without such a tool
the need for a central distribution site goes away and common code
ownership already went away in practice.

Also many recent extensions don't use our Docbook based docs for their
documentation but use Markdown or something in the GitHub repo.

Also mind that in the current model we have global package names with
no vendor prefix or similar. Thus names could conflict. A review by a
"trusted" person therefore could be worthwhile.

Thus questions are:

- What is PECL? (directory? platform? community? incubator? siberia?)
- What is the extension install process in future? (clone repo and go
from there? Right now `pecl install foo` will go to our server, fetch
the tgz with pregenerated autoconf configure)
- how do we transition old packages to new way (whatever that new way
is)


> # Change voting rights
> 
> Getting a pecl account would explicitly no longer give or require a
> php.net account, and wouldn't confer voting karma. To be clear, I am
> actually unsure whether it's intended for people with PECL accounts
> should get voting karma; I know some people did but apparently not
> all
> have.

PECK account doesn't give voting rights. But in the old model users
registered on PECL and on php.net at the same time to put the code into
PHP's VCS (CVS, svn, git), add docs and use bugs.php.net (see the
checkbox "do you need VCS account?) that account is separated and
requires independent approval via master.php.net.

Before voting impact was low ... a rogue contributor had little writing
permission in VCS and worst they could do was manipulating bug status
etc. which we never had to recover, yet ... but could if it came to it.

johannes

P.S. If somebody I know pings me I typically approve accounts, both for
PECL and php.net but we could spread the powers to other, more active,
people.

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

Re: [PHP-DEV] Changing PECL signup flow.

[Thomas Hruska]

On 9/15/2019 10:11 AM, Dan Ackroyd wrote:

HI internals,

Currently, it is quite difficult to signup to get a PECL account.

We have a somewhat deliberately obtuse form to signup through, which
then needs to be manually approved by someone with the appropriate
karma.

Over the past year two people who I know from the community have
reached out to me to ask "we've submitted our account application, how
do we get approved now", after their application has sat un-actioned
for weeks. And only after I spoke to someone with the appropriate
karma was their account approved.

I would like to suggest the following changes both to allow it easier
to publish PECL extensions, and also prevent that causing problems.

# Allow a new signup method

Allow people who want a PECL account to submit a link to github repo
(or alternative VCS provider) that contains a 'ready-to-ship' PHP
extension repo.

We (or probably, I) will provide a tool that allows people to check
that their repo is ready to be submitted to PECL, including all the
appropriate things like buildconf works, the name of the project is
set in the appropriate place.

On signup, when someone submits a 'ready-to-ship' extension we will
have code that checks the extension for conformance, and if the
extension looks ready to go, their application is listed on a page
where anyone with PECL karma can approve or reject the application.

This would remove the bottleneck of only a few people being able to
approve the PECL accounts, while still blocking most inappropriate
signup attempts.

# Change voting rights

Getting a pecl account would explicitly no longer give or require a
php.net account, and wouldn't confer voting karma. To be clear, I am
actually unsure whether it's intended for people with PECL accounts
should get voting karma; I know some people did but apparently not all
have.

Although giving those a php.net account and voting karma is
appropriate for extensions that are widely used, it is not appropriate
for extensions that belong to a company and don't represent a wider
community interest to automatically get a php.net account and/or
voting rights.

For example, there are multiple extensions that allow Application
Performance Monitoring. Those extensions are not 'owned' by the
community, but instead represent a commercial interest.

Those two changes should allow extensions to be listed on PECL much
more easily, without being too disruptive to the PECL site.

Thoughts?


Sounds good to me.

I thought the php.net account was for incorporating new documentation?

--
Thomas Hruska
CubicleSoft President

I've got great, time saving software that you will find useful.

http://cubiclesoft.com/

And once you find my software useful:

http://cubiclesoft.com/donate/

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

[PHP-DEV] Changing PECL signup flow.

[Dan Ackroyd]

HI internals,

Currently, it is quite difficult to signup to get a PECL account.

We have a somewhat deliberately obtuse form to signup through, which
then needs to be manually approved by someone with the appropriate
karma.

Over the past year two people who I know from the community have
reached out to me to ask "we've submitted our account application, how
do we get approved now", after their application has sat un-actioned
for weeks. And only after I spoke to someone with the appropriate
karma was their account approved.

I would like to suggest the following changes both to allow it easier
to publish PECL extensions, and also prevent that causing problems.

# Allow a new signup method

Allow people who want a PECL account to submit a link to github repo
(or alternative VCS provider) that contains a 'ready-to-ship' PHP
extension repo.

We (or probably, I) will provide a tool that allows people to check
that their repo is ready to be submitted to PECL, including all the
appropriate things like buildconf works, the name of the project is
set in the appropriate place.

On signup, when someone submits a 'ready-to-ship' extension we will
have code that checks the extension for conformance, and if the
extension looks ready to go, their application is listed on a page
where anyone with PECL karma can approve or reject the application.

This would remove the bottleneck of only a few people being able to
approve the PECL accounts, while still blocking most inappropriate
signup attempts.

# Change voting rights

Getting a pecl account would explicitly no longer give or require a
php.net account, and wouldn't confer voting karma. To be clear, I am
actually unsure whether it's intended for people with PECL accounts
should get voting karma; I know some people did but apparently not all
have.

Although giving those a php.net account and voting karma is
appropriate for extensions that are widely used, it is not appropriate
for extensions that belong to a company and don't represent a wider
community interest to automatically get a php.net account and/or
voting rights.

For example, there are multiple extensions that allow Application
Performance Monitoring. Those extensions are not 'owned' by the
community, but instead represent a commercial interest.

Those two changes should allow extensions to be listed on PECL much
more easily, without being too disruptive to the PECL site.

Thoughts?

cheers
Dan
Ack

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