
<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; font-family: Calibri, sans-serif; font-size: 14px; color: rgb(0, 0, 0);"><div><img src="cid:97D4CF9C-46C7-4D8B-BCAA-44FDC2347A2A" type="image/png"></div><div><br></div><div>On 10/9/15, 7:42 AM, "mpiwg-tools on behalf of Bland, Wesley" <<a href="mailto:mpiwg-tools-bounces@lists.mpi-forum.org">mpiwg-tools-bounces@lists.mpi-forum.org</a> on behalf of <a href="mailto:wesley.bland@intel.com">wesley.bland@intel.com</a>> wrote:</div><div><br></div><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div>+1. </div><div><br></div><div>My thinking was that the mpi-1.x (and the similar branches for the side documents) would be “special” in that no one should commit to them, but they would just be mirrors of the main mpi-forum branches. If you’d like to do something like an integration branch within your repository, that is also fine.</div><div><br></div><div>For the FTWG, my plan was to just do everything inside a branch in the FTWG repository and not have internal pull requests unless someone has something they’re working on outside of the working group and want to bring it in for everyone else to see.</div><div><br></div><div><br></div><div><br></div><div><br></div><div>On 10/9/15, 9:35 AM, "mpiwg-tools on behalf of Todd Gamblin" <<a href="mailto:mpiwg-tools-bounces@lists.mpi-forum.org">mpiwg-tools-bounces@lists.mpi-forum.org</a> on behalf of <a href="mailto:tgamblin@llnl.gov">tgamblin@llnl.gov</a>> wrote:</div><div><br></div><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div>On 10/9/15, 6:57 AM, "mpiwg-tools on behalf of Bland, Wesley"</div><div><<a href="mailto:mpiwg-tools-bounces@lists.mpi-forum.org">mpiwg-tools-bounces@lists.mpi-forum.org</a> on behalf of</div><div><a href="mailto:wesley.bland@intel.com">wesley.bland@intel.com</a>> wrote:</div><div><br></div><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div>I¹m not sure this solves part two of his question though. Once you accept</div><div>the PR into the working group¹s copy of the MPIR doc, you now have an</div><div>mpir-1.x branch that¹s out of sync with the main mpi-forum/mpir document.</div><div>This means that you open a PR for</div><div>mpiwg-tools/mpir/mpir-1.x:mpi-forum/mpir/mpir-1.x. This is fine until you</div><div>have multiple tickets going at once and want to PR each of them</div><div>individually.</div><div><br></div><div>I was actually thinking that we¹d use the model that Marc-Andre</div><div>suggested. Have working groups work on their ideas in a branch on their</div><div>repositories, then PR from the WG repository to the mpi-forum repository.</div><div>I know it¹s not exactly the GitHub model, but I don¹t know that the</div><div>GitHub model is set up for the two-level system that we¹re working with.</div></blockquote><div><br></div><div>I like Wesley's idea.  It's common for teams working closely together to</div><div>use a naming scheme for topic branches within a single repository, and to</div><div>do PR's *within* that repo.  So this could work, and it would preserve</div><div>topic branches for later piece-by-piece pushes into the mainline repo.</div><div><br></div><div>It sounds like we want to use PR's for approval of tools proposals, then</div><div>use PR's to submit them again to the mainline MPI repo.  Could you use a</div><div>local integration branch in the tools repo for this, e.g. consider the</div><div>following branches:</div><div><br></div><div>mpi-forum:</div><div><span class="Apple-tab-span" style="white-space:pre">   </span>master</div><div><br></div><div>mpi-tools-wg:</div><div><span class="Apple-tab-span" style="white-space:pre">  </span>master</div><div><span class="Apple-tab-span" style="white-space:pre">       </span>integration</div><div><span class="Apple-tab-span" style="white-space:pre">  </span>topic/mpi-plugins</div><div><span class="Apple-tab-span" style="white-space:pre">    </span>topic/proposal-2</div><div><span class="Apple-tab-span" style="white-space:pre">     </span>topic/proposal-3</div><div><br></div><div>Within the tools repo someone could easily submit a topic for review with</div><div>a PR, e.g.:</div><div><span class="Apple-tab-span" style="white-space:pre">  </span></div><div><span class="Apple-tab-span" style="white-space:pre">     </span>PR: topic/mpi-plugins -> integration</div><div><br></div><div>That could be used to discuss and review the proposal.  Once the topic is</div><div>merged to integration, it can then be submitted upstream to master because</div><div>It's still nicely packaged in a branch:</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre">   </span>PR: mpi-tools-wg:topic/mpi-plugins -> mpi-forum:master</div><div><br></div><div>Then if it gets merged into the mainline, you just sync your fork's master</div><div>with the upstream master (common thing to do on github).  And you don't</div><div>have the problem of submitting a bunch of merged stuff into the upstream.</div><div><br></div><div>The integration branch and all the topic branches should be based on</div><div>master.  The integration branch itself can be transient, i.e. the tools WG</div><div>lead can rebuild it if some PR into upstream master is not accepted.</div><div>Anyone can check out the integration branch to see the current state of</div><div>all locally accepted tools proposals, but you never submit a PR from</div><div>mpi-tools-wg:integration to mpi-forum:master.  mpi-tools-wg:master is</div><div>always in sync with the upstream master.  You keep the original topic</div><div>branches around and use them as building blocks for PRs, until they're</div><div>merged to upstream master.</div><div><br></div><div>This is not unlike the way Kitware maintains the CMake repo, or the</div><div>branchy workflow described in the git manpages.</div><div><br></div><div>You can implement protections on some branches like this:</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre">  </span><a href="https://github.com/blog/2051-protected-branches-and-required-status-checks">https://github.com/blog/2051-protected-branches-and-required-status-checks</a></div><div><br></div><div>So that people besides the WG lead can't just clobber integration or</div><div>master.</div><div><br></div><div>Thoughts?</div><div><br></div><div>-Todd</div><div><br></div><div><br></div><div><br></div><div><br></div><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div><br></div><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div><br></div><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div> 2) As commented on the pull request at:</div><div> </div><div> <a href="https://github.com/mpiwg-tools/mpir/pull/1">https://github.com/mpiwg-tools/mpir/pull/1</a></div><div> </div><div> we discussed some wording that goes beyond what this current pull</div><div> requests reflects. Should we update the pull request, or merge it and</div><div> create a new branch for further updates?</div></blockquote><div><br></div><div>Yeah, sorry about that -- I had to miss yesterday's call.</div><div><br></div><div>We have two options:</div><div><br></div><div>1. Anh can file an entirely new PR that obsoletes mine, and we can close</div><div>mine.</div><div><br></div><div>2. Anh can file a pull request against</div><div>jsquyres:pr/mpir-being-debugged-fixes.  I can accept his changes, which</div><div>will then merge his changes into my branch, which will automatically</div><div>update the existing PR.</div><div><br></div><div>Either is fine.</div><div><br></div><div>(#2 may sound mind blowing to those of you to whom this is a new</div><div>concept, but it's actually quite common -- i.e., you're effectively</div><div>filing a PR against a PR, and it works exactly as you would expect it to)</div><div><br></div><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div> 3) In the call yesterday, we were all Git novices, thus I am not sure</div><div> whether we agreed on the right workflow within the working group. Our</div><div> idea was to create a branch on the working-group repo of the document,</div><div> and commit to there, so multiple people can access the text from</div><div> there, and we can also create the pull request to the mpi-forum from</div><div> there.</div></blockquote><div><br></div><div>No, let's not do that.</div><div><br></div><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div> Would one still need "personal forks" of the documents?</div></blockquote><div><br></div><div>Yes.  This is a much better practice.</div><div><br></div><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div> I could</div><div> imagine to pull from personal forks into the created branch instead of</div><div> working on the branch directly. Is that better practice?</div></blockquote><div><br></div><div>Yes.  This is pretty much The Github Way: individual people create forks</div><div>and then file pull requests against the upstream repo (e.g., in our</div><div>case, the mpiwg-tools/mpir repo, and then ultimately the mpi-forum/mpir</div><div>repo).</div><div><br></div><div>There is a bit of a new ground for us to figure out, though: since WGs</div><div>now have their own "private" working areas to create their own text,</div><div>etc., when exactly do we file a PR against our own WG repo and when do</div><div>we file a PR against the mpi-forum repo?  (I think Marc-Andre asked the</div><div>same question)  I don't have an immediate answer for this.</div><div><br></div><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div> 4) If 3 makes sense, how can I merge Jeffs pull request not into the</div><div> main branch of mpiwg-tools:mpir but into something like</div><div> mpiwg-tools:issue_6_being_debugged?</div></blockquote><div><br></div><div>No.  Once a PR has been created, the source and target repo:branches are</div><div>fixed.  If you want to change the source/target, you have to close that</div><div>PR and open a new one.</div><div><br></div><div>-- </div><div>Jeff Squyres</div><div><a href="mailto:jsquyres@cisco.com">jsquyres@cisco.com</a></div><div>For corporate legal information go to:</div><div><a href="http://www.cisco.com/web/about/doing_business/legal/cri/">http://www.cisco.com/web/about/doing_business/legal/cri/</a></div><div><br></div></blockquote><div>_______________________________________________</div><div>mpiwg-tools mailing list</div><div><a href="mailto:mpiwg-tools@lists.mpi-forum.org">mpiwg-tools@lists.mpi-forum.org</a></div><div><a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools</a></div></blockquote><div><br></div><div><br></div><div>_______________________________________________</div><div>mpiwg-tools mailing list</div><div><a href="mailto:mpiwg-tools@lists.mpi-forum.org">mpiwg-tools@lists.mpi-forum.org</a></div><div><a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools</a></div></blockquote><div>_______________________________________________</div><div>mpiwg-tools mailing list</div><div><a href="mailto:mpiwg-tools@lists.mpi-forum.org">mpiwg-tools@lists.mpi-forum.org</a></div><div><a href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools</a></div></blockquote></body></html>