[mpiwg-tools] Changes from Bordeaux to MPIR
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:
> 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
> 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>
>> 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
>>> 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:
>> 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:
>> So that people besides the WG lead can't just clobber integration or
>>>>> 2) As commented on the pull request at:
>>>>> 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
>>>> 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
>>>> 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
>>>> 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
>>>> 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:
>>> mpiwg-tools mailing list
>>> mpiwg-tools at lists.mpi-forum.org
>> mpiwg-tools mailing list
>> mpiwg-tools at lists.mpi-forum.org
> mpiwg-tools mailing list
> mpiwg-tools at lists.mpi-forum.org
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 218448 bytes
Desc: not available
More information about the mpiwg-tools