Backporting instructions in Contributing guide

I’m probably going to help backport some code from master onto 3.2, and the suggested process in the Contributing guide doesn’t actually look like the best approach to me. Wouldn’t it make more sense to just check out the branch you want to patch, cherry-pick the change(s) from master, make any additional commits necessary to get it working?

Not only is that simpler than what is suggested, it easily handles changes that were committed to master long ago and/or are spread across multiple non-consecutive commits.

Assuming that sounds right, shall we update the guide?

I’m probably going to help backport some code from master onto 3.2, and the suggested process in the Contributing guide doesn’t actually look like the best approach to me. Wouldn’t it make more sense to just check out the branch you want to patch, cherry-pick the change(s) from master, make any additional commits necessary to get it working?

Yes. This is exactly what I do. But, you should not add more commits. Just cherry-pick and amend the commits. This will make easier to track backports. Also, I usually cherry-pick the merge commit when it exists so it will point to the pull request too.

I don’t know if the others Rails committers agree but this is my workflow to backports.

Not only is that simpler than what is suggested, it easily handles changes that were committed to master long ago and/or are spread across multiple non-consecutive commits.

Assuming that sounds right, shall we update the guide?

Yes, please.

+1

I think I wrote the original guide on back porting and this definitely sounds like a better approach.

Godfrey

Sounds good.