Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107132
Message-ID: <61ab41b2e7eb74c23bc0dc4a307d1045863966fc.camel@schlueters.de>
To: Dan Ackroyd <Danack@basereality.com>, PHP internals
	 <internals@lists.php.net>
Date: Mon, 16 Sep 2019 04:39:43 +0200
In-Reply-To: <CA+kxMuTvOjnV18LwVP=n_JXwm66932uGV-m9zRSsFgiX9Jcy7g@mail.gmail.com>
References: 
	<CA+kxMuTvOjnV18LwVP=n_JXwm66932uGV-m9zRSsFgiX9Jcy7g@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Changing PECL signup flow.
From: 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.