Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78902
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.45 as permitted sender)
MIME-Version: 1.0
Sender: julienpauli@gmail.com
In-Reply-To: <EB032A39-EB24-4BBE-A2D3-14BF63809873@zort.net>
References: <EB032A39-EB24-4BBE-A2D3-14BF63809873@zort.net>
Date: Fri, 14 Nov 2014 10:37:53 +0100
Message-ID: <CAMUwpuSKDUCdabvKU8V9N1EgPvJzTZXrwsHemLcu4JXLQ30Mbw@mail.gmail.com>
To: John Bafford <jbafford@zort.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] GitHub Pull Requests Triage Team
From: jpauli@php.net (Julien Pauli)

On Thu, Oct 30, 2014 at 10:57 PM, John Bafford <jbafford@zort.net> wrote:
> Hi,
>
> I would like to propose the creation of a team to triage the pull request=
s on GitHub, to help ensure that the pull requests are handled in a timely =
manner. I am also volunteering to lead such a team, should the RFC be appro=
ved.
>
> https://wiki.php.net/rfc/github-pr
>
> PHP=E2=80=99s GitHub repository has over 180 open pull requests. Many of =
these are bug fixes or new tests that should be incorporated into PHP, but =
have not been because the PRs aren=E2=80=99t being regularly monitored. As =
a result, the large number of open pull requests may also be discouraging c=
ontributions, as potential contributors may see that pull requests are not =
being acted on and decline to submit changes.
>

Hi,


I like the label idea, it will help having a nice overall look on the PRs.

When I myself find some time, I mainly browse through bugs.php.net and
fix things and close issues.

Everything is matter of time and knowledge.

Having people with time to review PRs, and knowledge about internals
code and the PR code quality, is pretty hard to find.
Like Tyrael said, one could always ping an RM to finally merge the PR,
or even review it.
We (as RMs) have already been pinged back in time by people pushing
their PR. This is normal situation, I think everyone is responsible of
his own PR, nd responsible of pushing it into the final step. But as
we all volunteer into the PHP project, it may sometimes be hard to
find time for. Not bad, a PR is obviously never lost until cleaned.

PS : our merging strategy as well is not easy to get, knowing some PRs
may conflict while merge into the diverging master code.


Julien.P