Thanks for the reply. 1) Major point is that commit's changeset size will be completely relied on > JIRA issue's size, and we can have another pain point when changeset > becomes huge.
I am planning adding JIRA title as the commit message. Its what we do any way. 2) Additional point is how we leave multiple commits' log messages into one. > Headline of log can contain useful information which describes code > change, > and applying this approach improperly we can lose them. If you are fixing something even if its a small issue, One should file a JIRA and fix it send a PR. This mean each fix is one JIRA even if there are multiple commits thats gone in , in the end the patch fixes a JIRA. This is not going to apply for bigger contributions like a connector or a new component. But for those we can also squash lot of commits instead of pulling all of the commit messages into storm. We can treat these contributions bit differently than regular JIRAs. > Furthermore, we're also having huge PR. (for example, STORM-561 > <https://github.com/apache/storm/pull/546>) I wonder we can apply same > approach to this, or go with exception. Yep we can definitely make exceptions to bigger contributions. As I said above we can definitely bring down number of commits for the bigger contributions as well. Thanks, Harsha On Fri, May 8, 2015, at 04:19 PM, 임정택 wrote: > Hi. > > FYI, Spring Data Redis used your approach now, so we can take a look. > https://github.com/spring-projects/spring-data-redis > > At first, I like your approach. > > Major point is that commit's changeset size will be completely relied on > JIRA issue's size, and we can have another pain point when changeset > becomes huge. > I sought some of merged PRs from Storm repo, and their changesets seems > small enough to leave just one commit per PR. > > Additional point is how we leave multiple commits' log messages into one. > Headline of log can contain useful information which describes code > change, > and applying this approach improperly we can lose them. > > Furthermore, we're also having huge PR. (for example, STORM-561 > <https://github.com/apache/storm/pull/546>) I wonder we can apply same > approach to this, or go with exception. > > Btw, real pain point from cherry-picking is conflicts. > Jedis uses same approach, and we have to believe collaborators and unit > tests, and we did some mistakes while cherry-picking and unit tests > couldn't catch it. > It would be not resolved though we squash commits into one. > Have to make cherry-picking branch and post a PR related to merging > cherry-picked branch into specific version? > > Sincerely, > Jungtaek Lim (HeartSaVioR) > > > 2015-05-09 6:14 GMT+09:00 Harsha <[email protected]>: > > > Hi, > > Today we are merging into storm master branch using PRs. These PRs > > are usually contain multiple commits on different time lines . > > There are few issues with this approach , the major pain point is if we > > want cherry-pick a single JIRA current approach makes it harder as we have > > track down all the commits that went in for a particular JIRA. > > I am proposing we should squash these multiple commits into one singe > > commit before merging into trunk and associate the STORM JIRA in commit > > message. > > Let me know what you think. > > > > Thanks, > > Harsha > > > > > > > > > > > > > -- > Name : 임 정택 > Blog : http://www.heartsavior.net / http://dev.heartsavior.net > Twitter : http://twitter.com/heartsavior > LinkedIn : http://www.linkedin.com/in/heartsavior
