Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80682
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CA+kxMuTLvo+B8wSvWDD2che9KsHBkjK6Zr9_VAEJrNgoj0U+7w@mail.gmail.com>
References: <CAMUwpuTUP0SUYHeJ6qTTsLFX=YXbsAatZwHgBL5-M3yZs1eHeg@mail.gmail.com>
	<2sifbatnqq22e8pfunkh575o1plj81rk7j@4ax.com>
	<CAEPJdu=Xy_geky4xXT7Kc8+HmxcDqc8ezexAHM=15PbeZU4eBQ@mail.gmail.com>
	<colfbadhcfc3c98ssbds8evfmtk59drkan@4ax.com>
	<CAEPJdu=q2_YB-LW3GAaCXouRtoBszjVGdeyfD51VX=AdAG23BA@mail.gmail.com>
	<CAEZPtU580KpAwXQe7GVS4H7_ogSj63TBKw4PWkp83FJ9KC0B4g@mail.gmail.com>
	<CA+kxMuTLvo+B8wSvWDD2che9KsHBkjK6Zr9_VAEJrNgoj0U+7w@mail.gmail.com>
Date: Sat, 17 Jan 2015 07:00:41 +0100
Message-ID: <CAEZPtU5v7ftMxRcM+uRx6y5MykoQyzxtT3qPH9EQsw02kcgiTQ@mail.gmail.com>
To: Dan Ackroyd <danack@basereality.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Re: Top 10 Pecl extensions PHP7 compatibility
From: pierre.php@gmail.com (Pierre Joye)

On Sat, Jan 17, 2015 at 12:09 AM, Dan Ackroyd <danack@basereality.com> wrote:
> On 16 January 2015 at 00:03, Pierre Joye <pierre.php@gmail.com> wrote:
>> It is also important to note that I would like to push the usage of install
>> from git/other VCS in the near term, using pickle, and use the website only
>> for the meta info but not (or much less) for hosting the releases.
>
> As well as that, I think more of the ecosystem of extensions needs to
> be thought about, in particular where the issue tracker for extensions
> lives. Although it made sense in the past to have all issues tracked
> on bugs.php.net (due to the difficulty of hosting an issue tracker) it
> is not optimal now, and has a couple of problems.
>
> i) Because the issues are away from the code repository, it's far
> harder for people to contribute to extensions that it would be if
> everything is in one place.
>
> It's also difficult for people to make a code fix in their own fork
> and let other people be aware that the fix exists and use it. This is
> obviously much easier on Github where the entry barrier to commenting
> on issues is much lower, as well the barrier to making your code
> available to other people.
>
> This would be very useful where the alledged maintainers of an
> extension are no longer responding to emails.
>
> ii) Most of the issues related to a particular PECL package can only
> be handled by someone who is actively maintaining the extension. For
> example, the Gearman extension is a relatively modern extension that
> is actively maintained and yet still has 21 open issues, some dating
> back years.
>
> Having those issues open in the PHP bug tracker rather than in the
> Gearman repository on Github does not help anyone, and just clogs up
> the PHP bug tracker with items that PHP developers can't help with.
>
> A couple of examples of other PECL extensions:
>
> https://bugs.php.net/bug.php?id=66194
> https://bugs.php.net/bug.php?id=59171
>
> It's a waste of time having these things open in bugs.php.net. I think
> it would be better to require extensions that don't ship as part of
> the PHP official packages to have their issues hosted elsewhere -
> which would probably be Github for the majority of extensions.
>
> Changing the ecosystem shouldn't be a decision rushed into, but it
> would be good to think about how to make it better.

I mentioned that many times but I feel ike I will simply create a new
thread + wiki pages (RFC) to describe a possible roadmap.

But basically, I would really move pecl from a package hosting site to
a packagist like application. The new pickle tool, based on the same
concepts than composer, without requiring package.xml or multiple
definitions of the same meta info, supports all protocols composer
does, install/update from VCS included. That means there will be no
more requirement to actually create a release tgz, a simple tag will
be just fine.

For the issues tracker, I would rather leave it to the developers to
decide. In any case there is some work to do to make bugs.php.net
easier to deal with from a pecl pov.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org