Tips for the merge work

• Do not modify the file configure directly. Modify configure.in and then generate configure.

• If the change applies to master, create a PR on master to get more feedback.

• Code/Test conflict resolving: Should be careful.

• Refactor related code to make future merge easier (e.g. align more with upstream code; try to decouple GP and PG code.). This could be done before, during or after merge. Create a master PR if needed.

• Try to learn about the new features of this iteration in advance. People should think about what we should do for those features on gpdb in advance.

• For some unsure fix, ask people to peer review. You can create a PR on merge repo also especially for big changes.

• Try to peer review code for others even nobody asks.

• Add FIXME only when needed, and the FIXME should be with details (like a Tracker story).

• Add gpdb specific tests if needed.

• Be VERY CAREFUL on modifying test answer files.

• When debugging an issue, you can check future PG code to see whether there has already a fix.

• We don't create PR for most cases, but writing meaningful and detailed commit message is still helpful.

• Merge repo: Do not force-update.

• For issues which are not sure how to fix, post them to gpdb dev mailing list for discussion.

• Merge from the green master as often as possible, at the very least weekly.

• Keep questioning GPDB enhancements found during merge if they are necessary or upstream equivalent is good for the same

• Flag out painful tests encountered during merge as post work to simplify (difficult to reproduce or often have different plans than expected, etc).