On Sat, Jan 17, 2015 at 12:09 AM, Dan Ackroyd <dan...@basereality.com> wrote: > On 16 January 2015 at 00:03, Pierre Joye <pierre....@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
