Re: [ptp-dev] Merge policy reminder

[Beth Tibbitts <tibbitts@xxxxxxxxxx>]

I think the procedure on the wiki needs to clearly state thie in http://wiki.eclipse.org/PTP/environment_setup/git#Merging
It says "all changes in ptp_5_0 are regularly merged into master"   It sounds like this might happen automatically - I'll admit I didn't understand this until recently.
If we state the procedure clearly on the wiki as the steps to take when you check in something, then it's easier for people to learn how to do.

I can make the steps say
To check into 50 and master:  (Two diff workspaces assumed)
1. check in: commit and push to ptp_5_0
   2. from master: what order of Team>Merge and Team>Pull??


...Beth

Beth Tibbitts
Eclipse Parallel Tools Platform  http://eclipse.org/ptp
IBM STG - High Performance Computing Tools
Mailing Address:  IBM Corp., 745 West New Circle Road, Lexington, KY 40511

Greg Watson ---02/10/2012 10:16:56 AM---Hence my original message reminding people that they need to merge their changes. The scenario outli

From:	Greg Watson <g.watson@xxxxxxxxxxxx>
To:	Parallel Tools Platform general developers <ptp-dev@xxxxxxxxxxx>,
Date:	02/10/2012 10:16 AM
Subject:	Re: [ptp-dev] Merge policy reminder
Sent by:	ptp-dev-bounces@xxxxxxxxxxx

---

Hence my original message reminding people that they need to merge their changes. The scenario outlined below is only the case if changes have not been merged.

Typically what happens (to me) is that I commit something to ptp_5_0, then go to merge with master. At that point I find that someone has committed something to ptp_5_0 but not merged. Git does not allow selective merging, so I can either merge everything or nothing.

The only options I see are:

1. Merge everything, and notify the list that there were some un-merged commits. This has the advantage of not interrupting workflow, but could result in merge problems. It's also problematic if there are conflicts in the un-merged commits.

2. Merge nothing, and notify the list that there were some un-merged commits. The owner of the commits would then need to merge these before the merge could proceed. This is problematic if the owner is in another timezone, or on vacation, or whatever, since the merge is blocked at this point.

What do people want to do in this situation?

Greg

On Feb 10, 2012, at 9:32 AM, Jeffrey Overbey wrote:

If you find that someone else has made a change without merging it, then you have no choice but to do the merge yourself and assume that it is ok.

With all due respect, I really don't like this.  It totally disregards code ownership, it adds an unnecessary burden to the merge procedure, and it's absolutely asking for bugs caused by people modifying code they didn't write and don't fully understand.

If the technical limitations of our merge procedure are forcing us to make bad policy decisions, then there's something wrong with our merge procedure.

(Sorry, I don't have a solution, just an opinion...)

Jeff
_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev

_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev