Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101405
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain schlueters.de from 84.19.169.162 cause and error)
Message-ID: <1513887544.16381.12.camel@schlueters.de>
To: Anatol Belski <ab@php.net>, "Christoph M. Becker" <cmbecker69@gmx.de>, 
	Pedro =?ISO-8859-1?Q?Magalh=E3es?=
	 <mail@pmmaga.net>
Cc: PHP internals list <internals@lists.php.net>
Date: Thu, 21 Dec 2017 21:19:04 +0100
In-Reply-To: <AM3PR02MB101093A9C0CE32375B671D00BA0F0@AM3PR02MB1010.eurprd02.prod.outlook.com>
References: <1512478149.2069.40.camel@schlueters.de>
	 <CAJd4=YazXbSVA-hedu5Vf5Kfn5aiin04Wk-Zj+Wucq8n4RbjDg@mail.gmail.com>
	 <19331e5c-d82a-2d60-4f26-755da11fc576@gmx.de>
	 <1512483692.2069.58.camel@schlueters.de>
	 <AM3PR02MB101093A9C0CE32375B671D00BA0F0@AM3PR02MB1010.eurprd02.prod.outlook.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Outstanding php.net account requests
From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

On Di, 2017-12-19 at 21:17 +0000, Anatol Belski wrote:

> IMO it is a strategical question and we should keep up with the real
> world. It was one of the reasons for Pickle to come to life, which
> however didn't come to the optimal end implementation meanwhile.
> There's github, bitbucket, etc. As a usage example - an extension
> could be accepted on PECL, but indeed be released on GitHub only. The
> PECL site could sync that release to PECL, the pecl tool could be
> aware there were some release outside at the places we'd define as
> safe. Similar thoughts would be if it came to the Composer
> integration - the more it'd ease access to the extensions, the more
> profit it would be in the end. Perhaps it's just me, but reading on
> an arbitrary PHP project page something like "no extensions required"
> sounds really amiss. 

The issue with composer integration is, that composer is build around a
"project" whereas extensions are installed for a runtime and those not
necessarily overlap. i.e. it is possible to run "composer install foo"
via CLI from one PHP runtime and then execute the installed code using
a php-fpm with different ini locations.

If we build a pecl installer replacement we should see how we can
integrate with composer on one side and the php7enmod stuff from Ubuntu
on the other side. (and maybe also Windows ;-) )

> Basically, I'd suggest we don't pretend there's no world outta PECL
> and make things easy for use case scenarios where fe people only work
> on GitHub. For instance, we could also accept authentication with
> GitHub and others on PECL, with all the logical consequences. There's
> already quite some work with the regard to PR handling on GitHub for
> qa.php.net. Of course, it wouldn't deny the classic PECL use case
> scenario.

The underlying questions have to be looked at. PECL once aimed to be
(among other things) an incubator for PHP extensions, which would later
be bundled. This has higher requirements (on license, copyright etc.)
also the old model (back when CVS/SVN were the source of truth) allowed
us to take over maintenance of "important" extensions once the author
went away. If we're just a frontend to external repos we loose that to
some degree (while we could change the repository pointer) This needs
some thinking.

I'd really like to see more opinions on this.

johannes