It is important to ensure that code coming in is good quality, I think we can all appreciate that.
I don't think that is separate or instead of the ability to be agile, which we also see as a positive for this community. From what I have read on this thread, it sounds like our ability to be agile and address bugs quickly might be hampered by not having efficient mechanisms for getting feedback and bugs back from the user base? -- Ken Wallis Product Manager – WebWorks BlackBerry 289-261-4369 ________________________________________ From: m...@google.com [m...@google.com] on behalf of Max Woghiren [m...@chromium.org] Sent: Wednesday, June 12, 2013 7:35 AM To: dev Subject: Re: We need better contributions from new people I agree with Ian—reviewing and testing just needs to be more thorough. On Wed, Jun 12, 2013 at 10:17 AM, Michal Mocny <mmo...@chromium.org> wrote: > Before we go changing process, is this really a systemic issue? Bugs > happen, and people sometimes land code, I'de rather be nimble in fixing > those issues than rigid in preventing them. Personal opinion. > > -Michal > > > On Wed, Jun 12, 2013 at 9:54 AM, Ian Clelland <iclell...@chromium.org > >wrote: > > > That's not an issue of "we need better contributions from new people", > > that's "We, the committers, need to be more diligent in reviewing and > > testing before committing". > > > > We shouldn't be discouraging contributions from anyone, but we don't have > > to accept every pull request as-is, either. We can push back on the patch > > if it isn't clean enough, or if it isn't clear that it's the right > > solution, or even if it doesn't come with tests / docs. > > > > I'd have no problem with a lot more pull requests, if there was healthy > > discussion on JIRA for each one, including the core committers and the > > original reporter, before accepting (or rejecting) them. > > > > Regarding this particular commit, the original patch is ugly, and > probably > > shouldn't have been accepted without some cleanup, review, and attached > > tests. The additional issue that it caused, though, is obviously > something > > that wasn't covered by our existing tests. It was only noticed a couple > of > > months later, in a post on StackOverflow, and as far as I can tell, it > was > > only mentioned in Github 18 days ago, and Andrew was right on it. (He's > not > > working on it currently, for other reasons) > > > > That regression doesn't seem to me to be a failure in process, so much > as a > > gap in our test framework (which we can rectify easily enough) and maybe > an > > issue of not-paying-enough-attention-to-stackoverflow, or > > not-having-a-clear-channel-to-report-bugs. Maybe if it were easier for > > people to tell us when something broke and we didn't catch it, we might > > have fixed this a month sooner. > > > > > > > > On Wed, Jun 12, 2013 at 2:09 AM, Joe Bowser <bows...@gmail.com> wrote: > > > > > Hey > > > > > > I decided to check my e-mail and respond to an issue. It turns out > > > that we're not properly testing or even checking the pull requests > > > that we're getting into the project. The bug in question is CB-3766, > > > which was caused by a patch accepted to fix CB-2458. The error isn't > > > totally obvious, and doesn't get easily picked up on unit test (our > > > CordovaWebView test mostly works, but fires a TIMING ERROR), but if > > > you use an emulator, due to the emulator's crappiness, it apparently > > > creates an ugly stack trace. > > > > > > Honestly, there's no way that this should have made it in. I > > > personally think that I'm going to have to rename loadUrlIntoView to > > > initAndLoadUrl or something more obvious, since it's too similar to > > > loadUrl. That being said, we need to be more strict about quality > > > while at the same time encouraging people to contribute. I'd rather > > > deal with hundreds of pull requests than hundreds of issues where > > > people know the answer but don't tell you. > > > > > > Any ideas how we can accomplish this? Has anyone else seen pull > > > requests get in that shouldn't have? > > > > > > Joe > > > > > > --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
