I’m -1 to TBR in most cases. Exceptions may be where there is clear community consensus, and a design document that has been discussed.
> On Dec 29, 2015, at 11:48 PM, Bill Farner <wfar...@apache.org> wrote: > > Sorry for the jargon - "to be reviewed". It's a commit that is reviewed > offline, with the expectation that the committer will address any comments > in a follow-up patch. > > On Tue, Dec 29, 2015 at 8:35 PM, Henry Saputra <henry.sapu...@gmail.com> > wrote: > >> I am sorry, but what is TBR? >> >> - Henry >> >> On Tue, Dec 29, 2015 at 8:00 PM, John Sirois <j...@conductant.com> wrote: >>> I'm +1 to skipping reviews for those portions of the codebase that are >> hard >>> to test except via trail and error. >>> >>> I'm -0 to using TBR in an OSS project. In my mind TBR is for emregencies >>> of which there should be none in an OSS infra project; these should only >> be >>> in the leaves that use the OSS projects where the right answer should >>> generally be one either roll back or fork/patch/custom private release >> for >>> the emergency. >>> My experience is biased by the 1 spat of TBR I personally did as >> encouraged >>> by the core pants committers on the pants project. This was a series of >>> ~20 TBR reviews of experimental code in an exp/ dir unused by the >> mainline >>> code, but committed to master. The hope was that these reviews would be >>> looked at and they have not been ~3 months down the road. >>> >>> On Tue, Dec 29, 2015 at 8:38 PM, Jake Farrell <jfarr...@apache.org> >> wrote: >>> >>>> +1 >>>> >>>> -Jake >>>> >>>> On Wed, Dec 23, 2015 at 4:48 PM, Bill Farner <wfar...@apache.org> >> wrote: >>>> >>>>> All, >>>>> >>>>> Over the past few days, i have made several commits to the repository >>>>> without code review. Our convention has historically been to perform >> a >>>>> code review for any change, however small. Please see below for some >>>>> rationale, but i would like to propose that we allow committers to >>>> exercise >>>>> judgement on skipping code reviews for changes unrelated to build or >> test >>>>> of the main project (e.g. scheduler, executor, client, packaging). >> What >>>> do >>>>> you all think? >>>>> >>>>> As an example, i think the code review process is too much overhead >> for >>>>> commits like the ones below. With these commits i was playing >>>> whack-a-mole >>>>> to get alignment between markdown rendering on >> github.com/apache/aurora >>>>> and >>>>> aurora.apache.org. Skipping code review allowed me to fix things in >> a >>>>> much >>>>> shorter timeframe. >>>>> >>>>> commit 0d9fe18 >>>>> Author: Bill Farner <wfar...@apache.org> >>>>> Date: Wed Dec 23 08:31:27 2015 -0800 >>>>> >>>>> Fix string interpolation for release email. >>>>> >>>>> commit df5200b >>>>> Author: Bill Farner <wfar...@apache.org> >>>>> Date: Mon Dec 21 14:19:48 2015 -0800 >>>>> >>>>> Fix formatting and work around anchor link issues in >> installing.md >>>>> >>>>> commit 21c605e >>>>> Author: Bill Farner <wfar...@apache.org> >>>>> Date: Mon Dec 21 14:11:10 2015 -0800 >>>>> >>>>> Fix anchor links in installing.md. >>>>> >>>>> commit 9326fa6 >>>>> Author: Bill Farner <wfar...@apache.org> >>>>> Date: Mon Dec 21 12:21:37 2015 -0800 >>>>> >>>>> Link to install guide from docs/README.md >>>>> >>>>> commit f8e59a4 >>>>> Author: Bill Farner <wfar...@apache.org> >>>>> Date: Mon Dec 21 12:12:56 2015 -0800 >>>>> >>>>> Fix formatting issues in installing doc. >>>>> >>>> >>> >>> >>> >>> -- >>> John Sirois >>> 303-512-3301 >>
