[mpiwg-tools] Changes from Bordeaux to MPIR

[Jeff Squyres (jsquyres)]

+1 on Todd's idea.

> On Oct 9, 2015, at 10:35 AM, Todd Gamblin <tgamblin at llnl.gov> wrote:
> 
> 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
> 
> 


-- 
Jeff Squyres
jsquyres at cisco.com
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/