On Fri, Jul 22, 2016 at 5:39 AM, Ellison Anne Williams < [email protected]> wrote:
> I don't see point in having to get a +1 from another committer for fixing > trivial items such as merge conflicts, build breaks, etc. I also would > through trivial updates to the website like fixing typos, broken > hyperlinks, adding hyperlinks, etc. > Agree, merge conflicts, build breaks that can be resolved simply by the reviewer should be able to be done without another level of review; similarly, website changes. > My interpretation of RTC is that the author can commit their own changes > after receiving +1 from a reviewer (another committer). > Yeah, that's what I figured; I presumed it was simply necessary for another set of eyeballs to give the code a look, and that post-acceptance anyone could commit the changes. > > On 22/07/16 05:50, Andy LoPresto wrote: > > > One of the nice effects of RTC is that the community gets an > > > opportunity to gently enforce code convention and prevent rapid build > > > up of technical debt. Something else I've witnessed is that as the > > > community grows, non-committers feel more comfortable submitting PRs > > > because they've seen the same review process applied regardless of > > > the submitter's status. > > > > > > Apologies if I missed these points on an earlier thread. > > > > Sure, I don't feel strongly either way -- though I would expect a > > committer to be able to fix trivial items like a simple merge conflict, > > or backout a build breaking change without always having to get a > > backing +1 from elsewhere. > > > > Out of curiosity, does folks' interpretation of RTC mean that the author > > never commits their own changes? i.e. the reviewer always commits (as > > the original author)? > > > > Regards, > > Tim > > >
