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
On Tue, Dec 5, 2017 at 12:49 PM, Johannes Schlüter johannes@schlueters.de
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. :-DIf 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
On Tue, Dec 5, 2017 at 12:49 PM, Johannes Schlüter johannes@schlueters.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. :-DIf 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.
--
Christoph M. Becker
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. :-DIf 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 ..
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
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. :-DIf 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 ..
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.
And once you find my software useful:
-----Original Message-----
From: Johannes Schlüter [mailto:johannes@schlueters.de]
Sent: Tuesday, December 5, 2017 3:22 PM
To: Christoph M. Becker cmbecker69@gmx.de; Pedro Magalhães
mail@pmmaga.net
Cc: PHP internals list internals@lists.php.net
Subject: Re: [PHP-DEV] Outstanding php.net account requestsOn 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. :-DIf 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
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
On Tue, Dec 5, 2017 at 12:49 PM, Johannes Schlüter <
johannes@schlueters.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?
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.
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
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).
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.
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
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.
:)
That's been my stumblingblock for the last ten years. That, and
laziness in not requesting access (to be fair).