I'm actually very likeminded with Joe & Benson here. I can understand Joey's argument, but at some point the process is much more expensive than the task itself. If you fix a typo, for instance, and you need to get a review, the typo fix was likely less than 3 seconds. Getting a review, even it involves saying to the person next to you "Hey, check this. And comment +1 on the ticket." will like take 3-4 minutes. If the "process" around getting something done takes long (especially an order of magnitude longer in this case) than the task itself, I think the process is a problem. And while waiting 3-4 minutes may not seem like a big deal, this sometimes happens many times in one day, and the simple distraction itself can be frustrating and can take away a great deal of time (Your Brain at Work by Dr. David Rock, as well as many other publications suppose "Another study, published in October 2005, found that employees spent an average of 11 minutes on a project before being distracted. After an interruption it takes them 25 minutes to return to the original task, if they do at all.") So while I can understand Joey's point entirely I am very much +1 for skipping the RTC for housekeeping commits... though I agree that it's crucial that we define (early on) what is a "housekeeping" commit. Thanks-Mark
> Date: Thu, 15 Jan 2015 11:25:44 -0800 > Subject: Re: RTC for overhead activities, and git branches versus releases > From: [email protected] > To: [email protected] > > 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
