Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78552
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zort.net designates 96.241.205.2 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
In-Reply-To: <CAH-PCH4goC=4AqZ3KvwoKpGg-ks9Mgt311i704ZPCZnqJFiDkA@mail.gmail.com>
Date: Sat, 1 Nov 2014 16:18:05 -0400
Cc: Florian Anderiasch <ml@anderiasch.de>,
        Peter Cowburn <petercowburn@gmail.com>,
        PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <4C5D9E8A-951F-45C0-A6F4-3F606738CAB5@zort.net>
References: <EB032A39-EB24-4BBE-A2D3-14BF63809873@zort.net> <CAPg3Xx+TSgeYwayLoobZbjdg2tyDMJ8igmndEY5Xy+PStwJT+Q@mail.gmail.com> <5453990D.3040902@anderiasch.de> <CAH-PCH4goC=4AqZ3KvwoKpGg-ks9Mgt311i704ZPCZnqJFiDkA@mail.gmail.com>
To: Ferenc Kovacs <tyra3l@gmail.com>
Subject: Re: [PHP-DEV] [RFC] GitHub Pull Requests Triage Team
From: jbafford@zort.net (John Bafford)


On Oct 31, 2014, at 12:15, Ferenc Kovacs <tyra3l@gmail.com> wrote:

> On Fri, Oct 31, 2014 at 3:13 PM, Florian Anderiasch <ml@anderiasch.de>
> wrote:
>=20
>> On 31.10.2014 09:58, Peter Cowburn wrote:> On 30 October 2014 21:57,
>> John Bafford <jbafford@zort.net> wrote:
>>>=20
>>>> Hi,
>>>>=20
>>>> I would like to propose the creation of a team to triage the pull
>> requests
>>>> 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
>>>> approved.
>>>>=20
>>>=20
>>> Slightly off-topic, but how about the same thing for bugs.php.net =
and
>>> patches?
>>=20
>> This implies that on bugs and with PRs it's the same issue.
>> My cautious guess is that permissions to merge PRs on GitHub (which =
not
>> all developers can do) are not the main reason that stuff doesn't get
>> merged.
>>=20
>=20
> when qa.php.net is not dead, anybody with a php.net account is allowed =
to
> comment/close github PRs.
> for merging them, you are still required to have the appropriate karma =
to
> be able to push it to git.php.net.
>=20
>=20
>> Whereas on the bug tracker, afaik everyone with a php.net account can
>> triage, edit, assign, etc bugs. And still there are open ones.
>>=20
>=20
> I think that from the who can do what perspective those two are =
similar,
> anybody can help to review/debug and propose a improvements/solution =
or
> close the bogus reports/PRs, but at the end of the day, only those =
with
> approrpiate karma can merge the PR/patch for the fix.


I think what=92s on bugs.php.net and what=92s in a GitHub PR are largely =
two very different things, requiring two separate skill sets.

bugs.php.net is a bug and feature request database, and is a primary =
interface for *users* of PHP to ask for things. While you can provide a =
patch or a GitHub PR with an entry, the triage process for the bug =
database is likely to revolve around attempting to reproduce or confirm =
problems, de-duping, and then eventually getting someone to actually fix =
the bug or implement the feature.

A PR in GitHub, on the other hand, comes with (presumably working) code, =
so it jumps to the end of the line: validation that the code is correct =
and (in the case of new features, which should have an accompanying RFC) =
is the sort of thing we want in PHP.

I agree that there needs to be a triage team for bugs (there are 5,219 =
open bugs in the db since 1999, a large number of which I=92m guessing =
are actually dups, invalid, already fixed, or wontfix), and while it=92s =
also an important job, it=92s also outside the scope of the problem I=92m =
trying to solve (actual written code that could go in, but is =
languishing instead). I=92d like to get the GitHub triaging set up first =
since in theory all the PRs are actionable, and if we want to set up a =
formal triage team/process for bugs, we can discuss how best to manage =
that without biting off too much at one time. (PR triaging can =
realistically be done by one person; but going through the bugs backlog =
really is going to require a several person team, and probably one that =
collectively has experience with the entire PHP feature set.)



>> So, if it's only a permissions issue and people are active hindered =
to
>> get stuff done, go ahead and propose changes. If it just feels like
>> stuff doesn't get done... maybe no one's around to do it.
>>=20
>>=20
> personally I think that we lack people for both triaging/reviewing and
> merging/pushing the changes.
> So anybody willing to look into bugs/PRs are more than welcome, and =
even if
> he/she don't have the knowledge or karma to fix/merge the issue, it =
will
> already make it easier for those who do to do the last step.

Yes, this exactly. And I=92m envisioning that at some point, the GitHub =
PR Triage Team would also have the karma to commit the simple, =
non-controversial items, which would allow the more senior devs to focus =
on the larger/controversial/more important items.


> ps: if you need help for getting something looked at, org merged, feel =
free
> to ping the RMs and/or complain on internals@, because it is easy for =
us to
> miss things because of the already huge backlog of open bugs/PRs. I
> personally think that we should make some drastic measures to bring =
down
> the open bugs/feature requests to a managable level (see
> http://www.joelonsoftware.com/items/2012/07/09.html) as currently we =
have
> all the bugs/features reported since 1999.

We can avoid declaring bankruptcy on the PRs since there=92s relatively =
few of them, and getting a triage team off the ground will help us from =
ever having to do that. I don=92t know that we should declare bug =
bankruptcy, but if we do, we should first figure out how we=92re going =
to go forward to make sure we never have such a huge backlog again.

But I also think that dealing with the bugs situation is a separate =
discussion. Let=92s get GitHub PR triage going first, and we can apply =
any lessons we learn to the other problems.

-John=