[mpiwg-tools] Changes from Bordeaux to MPIR

[Todd Gamblin]

On 10/9/15, 6:57 AM, "mpiwg-tools on behalf of Bland, Wesley"
<mpiwg-tools-bounces at lists.mpi-forum.org on behalf of
wesley.bland at intel.com> wrote:

>I¹m not sure this solves part two of his question though. Once you accept
>the PR into the working group¹s copy of the MPIR doc, you now have an
>mpir-1.x branch that¹s out of sync with the main mpi-forum/mpir document.
>This means that you open a PR for
>mpiwg-tools/mpir/mpir-1.x:mpi-forum/mpir/mpir-1.x. This is fine until you
>have multiple tickets going at once and want to PR each of them
>individually.
>
>I was actually thinking that we¹d use the model that Marc-Andre
>suggested. Have working groups work on their ideas in a branch on their
>repositories, then PR from the WG repository to the mpi-forum repository.
>I know it¹s not exactly the GitHub model, but I don¹t know that the
>GitHub model is set up for the two-level system that we¹re working with.

I like Wesley's idea.  It's common for teams working closely together to
use a naming scheme for topic branches within a single repository, and to
do PR's *within* that repo.  So this could work, and it would preserve
topic branches for later piece-by-piece pushes into the mainline repo.

It sounds like we want to use PR's for approval of tools proposals, then
use PR's to submit them again to the mainline MPI repo.  Could you use a
local integration branch in the tools repo for this, e.g. consider the
following branches:

mpi-forum:
	master

mpi-tools-wg:
	master
	integration
	topic/mpi-plugins
	topic/proposal-2
	topic/proposal-3

Within the tools repo someone could easily submit a topic for review with
a PR, e.g.:
	
	PR: topic/mpi-plugins -> integration

That could be used to discuss and review the proposal.  Once the topic is
merged to integration, it can then be submitted upstream to master because
It's still nicely packaged in a branch:

	PR: mpi-tools-wg:topic/mpi-plugins -> mpi-forum:master

Then if it gets merged into the mainline, you just sync your fork's master
with the upstream master (common thing to do on github).  And you don't
have the problem of submitting a bunch of merged stuff into the upstream.

The integration branch and all the topic branches should be based on
master.  The integration branch itself can be transient, i.e. the tools WG
lead can rebuild it if some PR into upstream master is not accepted.
Anyone can check out the integration branch to see the current state of
all locally accepted tools proposals, but you never submit a PR from
mpi-tools-wg:integration to mpi-forum:master.  mpi-tools-wg:master is
always in sync with the upstream master.  You keep the original topic
branches around and use them as building blocks for PRs, until they're
merged to upstream master.

This is not unlike the way Kitware maintains the CMake repo, or the
branchy workflow described in the git manpages.

You can implement protections on some branches like this:

	https://github.com/blog/2051-protected-branches-and-required-status-checks

So that people besides the WG lead can't just clobber integration or
master.

Thoughts?

-Todd




>
>>
>>> 2) As commented on the pull request at:
>>> 
>>> https://github.com/mpiwg-tools/mpir/pull/1
>>> 
>>> we discussed some wording that goes beyond what this current pull
>>> requests reflects. Should we update the pull request, or merge it and
>>> create a new branch for further updates?
>>
>>Yeah, sorry about that -- I had to miss yesterday's call.
>>
>>We have two options:
>>
>>1. Anh can file an entirely new PR that obsoletes mine, and we can close
>>mine.
>>
>>2. Anh can file a pull request against
>>jsquyres:pr/mpir-being-debugged-fixes.  I can accept his changes, which
>>will then merge his changes into my branch, which will automatically
>>update the existing PR.
>>
>>Either is fine.
>>
>>(#2 may sound mind blowing to those of you to whom this is a new
>>concept, but it's actually quite common -- i.e., you're effectively
>>filing a PR against a PR, and it works exactly as you would expect it to)
>>
>>> 3) In the call yesterday, we were all Git novices, thus I am not sure
>>> whether we agreed on the right workflow within the working group. Our
>>> idea was to create a branch on the working-group repo of the document,
>>> and commit to there, so multiple people can access the text from
>>> there, and we can also create the pull request to the mpi-forum from
>>> there.
>>
>>No, let's not do that.
>>
>>> Would one still need "personal forks" of the documents?
>>
>>Yes.  This is a much better practice.
>>
>>> I could
>>> imagine to pull from personal forks into the created branch instead of
>>> working on the branch directly. Is that better practice?
>>
>>Yes.  This is pretty much The Github Way: individual people create forks
>>and then file pull requests against the upstream repo (e.g., in our
>>case, the mpiwg-tools/mpir repo, and then ultimately the mpi-forum/mpir
>>repo).
>>
>>There is a bit of a new ground for us to figure out, though: since WGs
>>now have their own "private" working areas to create their own text,
>>etc., when exactly do we file a PR against our own WG repo and when do
>>we file a PR against the mpi-forum repo?  (I think Marc-Andre asked the
>>same question)  I don't have an immediate answer for this.
>>
>>> 4) If 3 makes sense, how can I merge Jeffs pull request not into the
>>> main branch of mpiwg-tools:mpir but into something like
>>> mpiwg-tools:issue_6_being_debugged?
>>
>>No.  Once a PR has been created, the source and target repo:branches are
>>fixed.  If you want to change the source/target, you have to close that
>>PR and open a new one.
>>
>>-- 
>>Jeff Squyres
>>jsquyres at cisco.com
>>For corporate legal information go to:
>>http://www.cisco.com/web/about/doing_business/legal/cri/
>>
>_______________________________________________
>mpiwg-tools mailing list
>mpiwg-tools at lists.mpi-forum.org
>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools