[mpiwg-tools] Changes from Bordeaux to MPIR

Todd Gamblin tgamblin at llnl.gov
Fri Oct 9 09:46:57 CDT 2015 

On 10/9/15, 7:42 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:

> +1. 
> 
> 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.
> 
> 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.
> 
> 
> 
> 
> On 10/9/15, 9:35 AM, "mpiwg-tools on behalf of Todd Gamblin"
> <mpiwg-tools-bounces at lists.mpi-forum.org on behalf of 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
>> 
>> 
>> _______________________________________________
>> mpiwg-tools mailing list
>> mpiwg-tools at lists.mpi-forum.org
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools
> _______________________________________________
> mpiwg-tools mailing list
> mpiwg-tools at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-tools/attachments/20151009/1e1ffdad/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BtQnfw2CYAIh123.png
Type: image/png
Size: 218448 bytes
Desc: not available
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-tools/attachments/20151009/1e1ffdad/attachment-0001.png>

More information about the mpiwg-tools mailing list