I'm +1 RTC for admin/overhead activities and -1 on RTC for release process commits.
Basically, if anything is going into the main develop branch, I think it should be reviewed. One of the major benefits of this is it puts new contributors and committers on an equal footing when it comes to *developing* patches. Committers of course have the ability to also push patches that they've *reviewed*. Release process commits are mostly coming from an automated tool (i.e. the maven release plugin) so I don't see how we could review those commits prior to going through the release process. -Joey On Thu, Jan 15, 2015 at 10:24 AM, 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
