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/

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.