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. >
