# Outstanding php.net account requests - Thread: https://externals.io/message/101243 - Original archive: https://news-web.php.net/php.internals/101243 - Started by johannes@schlueters.de on 2017-12-05T12:49:09+00:00 - Messages: 9 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #101243 — johannes@schlueters.de — 2017-12-05T12:49:09+00:00 URL: https://externals.io/message/101243#101243 Hi, 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) johannes --- ## #101245 — mail@pmmaga.net — 2017-12-05T13:34:48+00:00 URL: https://externals.io/message/101243#101245 · In reply to: #101243 On Tue, Dec 5, 2017 at 12:49 PM, Johannes Schlüter wrote: > Hi, > > 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) > > johannes > > > -- > > > > 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. Regards, Pedro --- ## #101246 — Christoph M. Becker — 2017-12-05T13:57:07+00:00 URL: https://externals.io/message/101243#101246 · In reply to: #101245 > On Tue, Dec 5, 2017 at 12:49 PM, Johannes Schlüter > wrote: > > > […] > > 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. -- Christoph M. Becker --- ## #101247 — johannes@schlueters.de — 2017-12-05T14:21:32+00:00 URL: https://externals.io/message/101243#101247 · In reply to: #101246 > > > > […] > 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 .. For discrepancy between access rights - I assume we could extend those lists. For master the list is in http://git.php.net/?p=web/master.git;a =blob;f=include/functions.inc;h=b988e1b4a9589e186a24c44553ada7fa1b4f9b6 3;hb=HEAD#l410 and has many inactive people, out of the 25 I guess there are about 5 active ones (I'm not really active, so I don't know and would leave it to others to decide who should be added)  411   $admins = array(  412     "jimw",  413     "rasmus",  414     "andrei",  415     "zeev",  416     "andi",  417     "sas",  418     "thies",  419     "rubys",  420     "ssb",  421     "wez",  422     "philip",  423     "davidc",  424     "helly",  425     "derick",  426     "bjori",  427     "pajoye",  428     "danbrown",  429     "felipe",  430     "johannes",  431     "tyrael",  432     "salathe",  433     "cmb",  434     "kalle",  435     "krakjoe"  436   ); For granting karma the list is in http://svn.php.net/viewvc/SVNROOT/glo bal_avail?revision=343578&view=markup # Some people also have access to the configuration files in the SVNROOT. avail|sterling,goba,imajes,wez,iliaa,derick,jon,alan_k,jmcastagnetto ,mj,pajoye,helly,philip,stas,johannes,gwynne,lsmith,bjori,dsp,felipe ,tyrael,salathe,krakjoe|SVNROOT [...] # But members of the PHP Group get access to everything. avail|andi,andrei,jimw,rasmus,rubys,sas,ssb,thies,zeev,shane For PECL I'd have to figure out where this is stored :-) Overall we should try to welcome contributors - if legit contributors have to wait for a year it's bad. johannes --- ## #101269 — Peter Cowburn — 2017-12-08T16:38:20+00:00 URL: https://externals.io/message/101243#101269 · In reply to: #101246 > > > > […] > johannes@schlueters.de> > > […] I went through the outstanding "doc" group requests, there are currently only 2 of those now remaining (I'm waiting on replies to emails for those two). Of the other two groups, there are currently 11 for the "php" group and 78 for the "pecl" group. > > […] > I didn't tackle this, but I have changed master so it that shows the "note" that folks enter when applying for their account, to make it easier/quicker to scan the list (e.g. for spam, and for me to find the "[group: doc]" requests). > > […] > not > > […] > the > > […] > > 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. > You're right there, the two (approving an account, granting the appropriate commit karma) should almost always be done at the same time. Anyone looking to help with the account requests should have SVNROOT karma, or ask for it. :) > > -- > Christoph M. Becker --- ## #101336 — Thomas Hruska — 2017-12-12T15:37:08+00:00 URL: https://externals.io/message/101243#101336 · In reply to: #101247 > > > […] > > 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 .. PHP documentation access might be the deciding factor here in answering that question. -- Thomas Hruska CubicleSoft President I've got great, time saving software that you will find useful. http://cubiclesoft.com/ And once you find my software useful: http://cubiclesoft.com/donate/ --- ## #101396 — Anatol Belski — 2017-12-19T21:17:58+00:00 URL: https://externals.io/message/101243#101396 · In reply to: #101247 > -----Original Message----- > From: Johannes Schlüter [mailto:johannes@schlueters.de] > Sent: Tuesday, December 5, 2017 3:22 PM > To: Christoph M. Becker ; Pedro Magalhães > > Cc: PHP internals list > Subject: Re: [PHP-DEV] Outstanding php.net account requests > > > > […] > > 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 --- ## #101405 — johannes@schlueters.de — 2017-12-21T20:19:04+00:00 URL: https://externals.io/message/101243#101405 · In reply to: #101396 > 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 --- ## #101406 — Daniel Brown — 2017-12-21T21:36:37+00:00 URL: https://externals.io/message/101243#101406 · In reply to: #101269 > > > Furthermore, while some have karma to approve VCS accounts, they may not > > […] > > You're right there, the two (approving an account, granting the appropriate > commit karma) should almost always be done at the same time. Anyone looking > to help with the account requests should have SVNROOT karma, or ask for it. > :) That's been my stumblingblock for the last ten years. That, and laziness in not requesting access (to be fair).