The argument for doing "housekeeping" commits without a review is that waiting for a review is a time burden. My counter to this is that truly trivial patches require a trivial review which means the only time burden is the time it takes to find someone to do the review. If it takes a long time to find someone to do a review for a "housekeeping" patch, then I'd view that as a community problem not a process problem.
The one counter argument is that in dealing with a global community, it can be hard for folks in some timezones to find available reviewers. We've hit this before in Kite where due to timezones and vacations, there were not committers available to do a review that was blocking that release. In those cases, I asked third-party developers that had good standing in the community to do the review for me even though they weren't committers. Even better, they found a bug that I had missed in my patch development process that would have required a second patch anyway. So in summary, I'm still a strong +1 on RTC for all patches. If you want an explicit rule for "housekeeping" commits that they can be developed by a committer and then reviewed by a contributor, then I'd be in favor of that. However, we need to provide a very clear definition of a "housekeeping" commit to avoid potential confusion. -Joey On Thu, Jan 15, 2015 at 11:02 AM, Joe Witt <[email protected]> wrote: > Benson, > > For me personally, I share the view you indicate for applicability of RTC > for housekeeping items. That was the intent of my previous RTC thread - to > test those sorts of things out. > > Your comment about the branch for release and merging to master does bring > up an important curveball to our plans given that the nar maven plugin > within that same bundle. I don't see how we'll do this without splitting > it into its own Git repo. Perhaps we should just rip that bandaid off > now. I can submit an infra request tonight if this is the right play. > > Thanks > joe > > On Thu, Jan 15, 2015 at 1:24 PM, Benson Margulies <[email protected]> > wrote: > >> Personally, I can't see value in RTC on housekeeping tasks such as >> adding -incubator to the version # of the pom. And a person can't, at >> the end of the day, RTC a release. However, if there's a general >> feeling that you want to see a patch or a PR even for this, I'll of >> course go along. >> >> I also want to increase the precision of our plans for using branches >> for releases. >> >> On relatively informal projects that I'm on, the process (at least >> just for the tiny maven plugin) would be to directly do the release on >> develop. If there's a preference to start by making a pushed branch >> for the release process, and then merge that branch to develop at the >> end, I can do that. >> >> In the later case, it seems important to adopt the gitflow convention >> of using 'master' as the place where we merge the exact commit of each >> release. I confess that my git-foo may be insufficient for this and if >> someone else is willing to get the master branch to do the right thing >> afterwards I'll be grateful. >> -- Joey Echeverria
