On Oct 31, 2014, at 12:15, Ferenc Kovacs <tyr...@gmail.com> wrote: > On Fri, Oct 31, 2014 at 3:13 PM, Florian Anderiasch <m...@anderiasch.de> > wrote: > >> On 31.10.2014 09:58, Peter Cowburn wrote:> On 30 October 2014 21:57, >> John Bafford <jbaff...@zort.net> wrote: >>> >>>> Hi, >>>> >>>> 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. >>>> >>> >>> Slightly off-topic, but how about the same thing for bugs.php.net and >>> patches? >> >> 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. >> > > 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. > > >> Whereas on the bug tracker, afaik everyone with a php.net account can >> triage, edit, assign, etc bugs. And still there are open ones. >> > > 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’s on bugs.php.net and what’s 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’m guessing are actually dups, invalid, already fixed, or wontfix), and while it’s also an important job, it’s also outside the scope of the problem I’m trying to solve (actual written code that could go in, but is languishing instead). I’d 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. >> >> > 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’m 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’s relatively few of them, and getting a triage team off the ground will help us from ever having to do that. I don’t know that we should declare bug bankruptcy, but if we do, we should first figure out how we’re 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’s get GitHub PR triage going first, and we can apply any lessons we learn to the other problems. -John -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
