> -----Original Message----- > From: Johannes Schlüter [mailto:[email protected]] > Sent: Tuesday, December 5, 2017 3:22 PM > To: Christoph M. Becker <[email protected]>; Pedro Magalhães > <[email protected]> > Cc: PHP internals list <[email protected]> > Subject: Re: [PHP-DEV] Outstanding php.net account requests > > On Di, 2017-12-05 at 14:57 +0100, Christoph M. Becker wrote: > > On 05.12.2017 at 14:34, Pedro Magalhães wrote: > > > > > > > > On Tue, Dec 5, 2017 at 12:49 PM, Johannes Schlüter <johannes@schlue > > > ters.de> > > > wrote: > > > > > > > > > > > we currently have 118 outstanding php.net account requests going > > > > back to October 2016. If you recently tried to onboard somebody > > > > could you verify whether they are still unapproved? If somebody > > > > creates a > > > > mass- > > > > edit interface this would also be great, as the CSRF protection > > > > makes deleting obvious spam requests a bit more annoying than it > > > > neeeded. :-D > > > > > > > > If you see legit requests drop me (or somebody else with powers) a > > > > note (including what kind of svn/git karma is needed) and I can > > > > set it up. > > > > > > > > https://master.php.net/manage/users.php?search=&order=&forward=0&; > > > > begin= > > > > 0&max=20&unapproved=1 (I believe this is visible to all @php.net > > > > account holders) > > > To add to that, AFAIK new requests via http://php.net/git-php.php > > > are not sending the e-mail they should to this mailing list (PHP > > > Group). > > > Hence the > > > large number of outstanding requests without follow-up. > > An additional issue is that many account requests are made for PECL > > accounts as well, and not everybody who has karma to approve or reject > > VCS account requests has karma to handle PECL account requests. > > Furthermore, while some have karma to approve VCS accounts, they may > > not have karma to grant karma – so approving the accounts without > > granting actual karma does not really make sense. > > One question we need to answer there is "what should pecl be"? Do we want to > bring PECL extensions onto php infrastructure (shared bug tracker, git.php.net > which gives control to php.net i.e. for finding > successors) or should PECL be a repository with pointers to github and > therelike? > In the first case we should work on unifying the accounts. > In the later case we should look into sizing the PECL site down and try to > have an > "pecl" installer which can fetch stuff directly from git, similar to > packagist.org, > then we could simplify the process there .. > 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.
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. Regards Anatol
