Changing PECL signup flow.

  107112
September 15, 2019 17:11 Danack@basereality.com (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
  107129
September 16, 2019 00:05 thruska@cubiclesoft.com (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/
  107132
September 16, 2019 02:39 johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)
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.
  107149
September 16, 2019 08:30 arnold.adaniels.nl@gmail.com (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 <johannes@schlueters.de> wrote:
  107156
September 16, 2019 09:13 cmbecker69@gmx.de ("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 <https://github.com/FriendsOfPHP/pickle>, but that project looks like it has fallen asleep. -- Christoph M. Becker
  107202
September 18, 2019 13:22 johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)
On Mon, 2019-09-16 at 11:13 +0200, Christoph M. Becker wrote:
> > For the record, there is already > <https://github.com/FriendsOfPHP/pickle>, 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
  107203
September 18, 2019 13:32 cmbecker69@gmx.de ("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.: <http://git.php.net/?p=web/rmtools.git;a=summary>. -- Christoph M. Becker
  107207
September 18, 2019 14:53 johannes@schlueters.de (=?ISO-8859-1?Q?Johannes_Schl=FCter?=)
On September 18, 2019 3:32:38 PM GMT+02:00, "Christoph M. Becker" <cmbecker69@gmx.de> 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
  107230
September 19, 2019 12:06 Danack@basereality.com (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
  107231
September 19, 2019 13:42 johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)
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