October 2015 - mpiwg-tools - mailman3.cels.anl.gov

Re: [mpiwg-tools] Changes from Bordeaux to MPIR
by Todd Gamblin 09 Oct '15

09 Oct '15

On 10/9/15, 6:57 AM, "mpiwg-tools on behalf of Bland, Wesley" <mpiwg-tools-bounces(a)lists.mpi-forum.org on behalf of wesley.bland(a)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(a)cisco.com >>For corporate legal information go to: >>http://www.cisco.com/web/about/doing_business/legal/cri/ >> >_______________________________________________ >mpiwg-tools mailing list >mpiwg-tools(a)lists.mpi-forum.org >http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools

1 0

Re: [mpiwg-tools] Changes from Bordeaux to MPIR
by Bland, Wesley 09 Oct '15

09 Oct '15

On 10/9/15, 6:43 AM, "Jeff Squyres (jsquyres)" <jsquyres(a)cisco.com> wrote: >On Oct 9, 2015, at 1:24 AM, Marc-Andre Hermanns <hermanns(a)jara.rwth-aachen.de> wrote: >> >> Hi Jeff, >> >> (CC: Wes, to keep him in the loop for process/convention finding) >> >> thanks for the updates to the MPIR texts. As this being the first pull >> request I work on, I have some questions: >> >> 1) The pull request states it wants to merge into the >> 'mpiwg-tools:mpir-1.x' branch. But don't we need a separate branch in >> our fork, to enable the "final pull-request" into the mpi-forum:mpir >> document? If we directly pull changes into our main branch of the >> fork, how can we have separate pull requests for separate >> issues/tickets that the forum has/wants to vote on? > >It's common to make a new branch for every pull request that you file. > >More specifically: it's a common Github newbie mistake to *not* make a separate branch for every PR. > >Consider: a PR is a request to pull in a bunch of commits to the target branch. How do you specify *which* commits that you want to be pulled? You make a branch. *All* the commits on that branch -- i.e., all the commits from the point where the branch was made to the tip of that branch -- are part of the PR. Github is even smart enough such that *if you change the branch while the PR is open, the commits listed on the PR will automatically update*. E.g., if you add more commits. Or you rebase. Or you squash commits. Or rewrite the branch to have entirely new commits (vs. when you first created the PR). ...and so on. > >Hence, the branch I made is in *my* fork of the mpir repo. If/when my PR is accepted (i.e., merged in), my commits will show up in the mpir repo on the mpir-1.x branch. > >Make sense? > >(pro tip: start thinking about git as a graph, in the computer science sense of the word -- then git will start making a *lot* more sense) 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. > >> 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(a)cisco.com >For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ >

1 0

Re: [mpiwg-tools] Changes from Bordeaux to MPIR
by Marc-Andre Hermanns 09 Oct '15

09 Oct '15

Hi Jeff, > I think Wesley and I didn't talk about this specific case, to be honest. > > (+Wesley) > > Wesley: got any good ideas here? I.e., how does a working group > manage a bunch of individual Forum tickets internally, and then > push them up -- individually -- up to the main mpi-forum repo? > > I think it would be desirable for the working group to be able to > make a PDF that represents all their collectively-agreed-upon PRs, > but also be able to push those PRs individually up to the Forum > (vs. pushing the entire union of all changes up to the Forum en > masse). I think it would be ok to pull something that passed the 2nd vote into mpiwg-tools/mpir:mpir-1.x so new issues and branches can benefit from the updated document/chapter. So what about this workflow: 1. Member creates issue at mpiwg-tools/tools-issues 2. Member creates a branch off mpiwg-tools/mpir:mpir-1.x called issue_<issueno>_<issuename> 3. Member forks off mpiwg-tools/mpir (or rebases?) 4. Member makes changes to local fork and prepares a pull request from <username>/mpir:my_branch_that_handles_issue to mpiwg-tools/mpir:issue_<issueno>_<issuename> 5. If WG feels OK with the pull request, we accept it and create a pull-request of mpiwg-tools/mpir:issue_<issueno>_<issuename> against mpiwg-tools/mpir:mpir-1.x and schedule reading + votes. If anything fails, reiterate from (3), if it passes, mpiwg-tools merges the pull-request and the the "working-group copy" of the document reflects all accepted changes. 6. WG then creates another pull-request from the same branch against mpi-forum/mpir:mpir-1.x so they can be integrated into the _official_ document as soon as whoever is responsible for it is OK with it. We could also have a branch mpiwg-tools/mpir:ticket_zero that collects _all_ ticket zero changes. This way, all the trivial changes of missing commas etc. are in one pull-request and the others can be done at a time. What do you think? Cheers, Marc-Andre -- Marc-Andre Hermanns Jülich Aachen Research Alliance, High Performance Computing (JARA-HPC) Jülich Supercomputing Centre (JSC) Schinkelstrasse 2 52062 Aachen Germany Phone: +49 2461 61 2509 | +49 241 80 24381 Fax: +49 2461 80 6 99753 www.jara.org/jara-hpc email: hermanns(a)jara.rwth-aachen.de

1 0

Re: [mpiwg-tools] Changes from Bordeaux to MPIR
by Jeff Squyres (jsquyres) 09 Oct '15

09 Oct '15

I think Wesley and I didn't talk about this specific case, to be honest. (+Wesley) Wesley: got any good ideas here? I.e., how does a working group manage a bunch of individual Forum tickets internally, and then push them up -- individually -- up to the main mpi-forum repo? I think it would be desirable for the working group to be able to make a PDF that represents all their collectively-agreed-upon PRs, but also be able to push those PRs individually up to the Forum (vs. pushing the entire union of all changes up to the Forum en masse). > On Oct 9, 2015, at 8:34 AM, Marc-Andre Hermanns <hermanns(a)jara.rwth-aachen.de> wrote: > > Hi Jeff, > > oops. Fingers were faster than my brain. :/ > > I deleted all the things that I did _not_ screw up in my first email a > minute ago. > >>> It's common to make a new branch for every pull request that you file. >>> >>> More specifically: it's a common Github newbie mistake to *not* make a separate branch for every PR. >> >> So I can create a new branch. Say: >> >> mpiwg-tools/mpir:issue_5_being_debugged >> >> and then have your pull request be funneled into that new branch >> instead of mpiwg-tools:mpir:mpir-1.x? > > You basically already answered this below, sorry. So no, not possible. :-/ > >>> Consider: a PR is a request to pull in a bunch of commits to the >>> target branch. How do you specify *which* commits that you want to >>> be pulled? You make a branch. *All* the commits on that branch -- >>> i.e., all the commits from the point where the branch was made to >>> the tip of that branch -- are part of the PR. Github is even smart >>> enough such that *if you change the branch while the PR is open, >>> the commits listed on the PR will automatically update*. E.g., if >>> you add more commits. Or you rebase. Or you squash commits. Or >>> rewrite the branch to have entirely new commits (vs. when you first >>> created the PR). ...and so on. >>> >>> Hence, the branch I made is in *my* fork of the mpir repo. If/when >>> my PR is accepted (i.e., merged in), my commits will show up in the >>> mpir repo on the mpir-1.x branch. >>> >>> Make sense? >> >> This is (I think what I want to prevent). I would like your changes to >> _not_ show up in the mpir-1.x branch, but rather in > > this is how this sentence should have ended: > > ... mpiwg-tools/mpir:issue_5_being_debugged. > > So then we directly have a branch that we can use for the pull request > against mpi-forum/mpir:mpir-1.x > > Cheers, > Marc-Andre > > > > -- > Marc-Andre Hermanns > Jülich Aachen Research Alliance, > High Performance Computing (JARA-HPC) > Jülich Supercomputing Centre (JSC) > > Schinkelstrasse 2 > 52062 Aachen > Germany > > Phone: +49 2461 61 2509 | +49 241 80 24381 > Fax: +49 2461 80 6 99753 > www.jara.org/jara-hpc > email: hermanns(a)jara.rwth-aachen.de > > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [mpiwg-tools] Changes from Bordeaux to MPIR
by Marc-Andre Hermanns 09 Oct '15

09 Oct '15

Hi Jeff, oops. Fingers were faster than my brain. :/ I deleted all the things that I did _not_ screw up in my first email a minute ago. >> It's common to make a new branch for every pull request that you file. >> >> More specifically: it's a common Github newbie mistake to *not* make a separate branch for every PR. > > So I can create a new branch. Say: > > mpiwg-tools/mpir:issue_5_being_debugged > > and then have your pull request be funneled into that new branch > instead of mpiwg-tools:mpir:mpir-1.x? You basically already answered this below, sorry. So no, not possible. :-/ >> Consider: a PR is a request to pull in a bunch of commits to the >> target branch. How do you specify *which* commits that you want to >> be pulled? You make a branch. *All* the commits on that branch -- >> i.e., all the commits from the point where the branch was made to >> the tip of that branch -- are part of the PR. Github is even smart >> enough such that *if you change the branch while the PR is open, >> the commits listed on the PR will automatically update*. E.g., if >> you add more commits. Or you rebase. Or you squash commits. Or >> rewrite the branch to have entirely new commits (vs. when you first >> created the PR). ...and so on. >> >> Hence, the branch I made is in *my* fork of the mpir repo. If/when >> my PR is accepted (i.e., merged in), my commits will show up in the >> mpir repo on the mpir-1.x branch. >> >> Make sense? > > This is (I think what I want to prevent). I would like your changes to > _not_ show up in the mpir-1.x branch, but rather in this is how this sentence should have ended: ... mpiwg-tools/mpir:issue_5_being_debugged. So then we directly have a branch that we can use for the pull request against mpi-forum/mpir:mpir-1.x Cheers, Marc-Andre -- Marc-Andre Hermanns Jülich Aachen Research Alliance, High Performance Computing (JARA-HPC) Jülich Supercomputing Centre (JSC) Schinkelstrasse 2 52062 Aachen Germany Phone: +49 2461 61 2509 | +49 241 80 24381 Fax: +49 2461 80 6 99753 www.jara.org/jara-hpc email: hermanns(a)jara.rwth-aachen.de

1 0

Re: [mpiwg-tools] Changes from Bordeaux to MPIR
by Marc-Andre Hermanns 09 Oct '15

09 Oct '15

Hi Jeff, please forgive my Github illiteracy. ;-) >> 1) The pull request states it wants to merge into the >> 'mpiwg-tools:mpir-1.x' branch. But don't we need a separate branch in >> our fork, to enable the "final pull-request" into the mpi-forum:mpir >> document? If we directly pull changes into our main branch of the >> fork, how can we have separate pull requests for separate >> issues/tickets that the forum has/wants to vote on? > > It's common to make a new branch for every pull request that you file. > > More specifically: it's a common Github newbie mistake to *not* make a separate branch for every PR. So I can create a new branch. Say: mpiwg-tools/mpir:issue_5_being_debugged and then have your pull request be funneled into that new branch instead of mpiwg-tools:mpir:mpir-1.x? > Consider: a PR is a request to pull in a bunch of commits to the > target branch. How do you specify *which* commits that you want to > be pulled? You make a branch. *All* the commits on that branch -- > i.e., all the commits from the point where the branch was made to > the tip of that branch -- are part of the PR. Github is even smart > enough such that *if you change the branch while the PR is open, > the commits listed on the PR will automatically update*. E.g., if > you add more commits. Or you rebase. Or you squash commits. Or > rewrite the branch to have entirely new commits (vs. when you first > created the PR). ...and so on. > > Hence, the branch I made is in *my* fork of the mpir repo. If/when > my PR is accepted (i.e., merged in), my commits will show up in the > mpir repo on the mpir-1.x branch. > > Make sense? This is (I think what I want to prevent). I would like your changes to _not_ show up in the mpir-1.x branch, but rather in > (pro tip: start thinking about git as a graph, in the computer science sense of the word -- then git will start making a *lot* more sense) > >> 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. No problem. It's great that you already prepared the text this far. And this kind of situation will probably come up in the future again, so it's great to figure out how to handle this in the future. > 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) I would probably prefer #2, because your wording is already very nice and Anh would just have to add a single sentence. >> 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. This is probably a very SVN way of thinking about this. ;-) ... so OK 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). OK. Then let's do it this way. :-D > 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. Yes, this is what I haven't figured out yet. For the voting process, I would imagine the working group has a branch, with a pull-request against the mpi-forum version. Once the ticket is voted in, whoever makes the final decision executes the pull-requests that got accepted by the forum. I understand that the pull-request is a branch by itself. Yet, when I accept your pull request, then your changes become part of mpiwg-tools/mpir:mpir-1.x. Then how do I do the following: 1) create a pull request against mpi-forum/mpir specifically for this change (to be voted on). 2) create a fork or even a branch for a new issue that does _not_ contain your pull request. Your changes would be part of HEAD, right? >> 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. So what do you propose. Do you think mpir:mpir-1.x is the correct target branch for this? I probably have to try out pull requests in some sandbox where I cannot break anything to get up to speed here. Cheers, Marc-Andre -- Marc-Andre Hermanns Jülich Aachen Research Alliance, High Performance Computing (JARA-HPC) Jülich Supercomputing Centre (JSC) Schinkelstrasse 2 52062 Aachen Germany Phone: +49 2461 61 2509 | +49 241 80 24381 Fax: +49 2461 80 6 99753 www.jara.org/jara-hpc email: hermanns(a)jara.rwth-aachen.de

1 0

Re: [mpiwg-tools] Changes from Bordeaux to MPIR
by Jeff Squyres (jsquyres) 09 Oct '15

09 Oct '15

On Oct 9, 2015, at 1:24 AM, Marc-Andre Hermanns <hermanns(a)jara.rwth-aachen.de> wrote: > > Hi Jeff, > > (CC: Wes, to keep him in the loop for process/convention finding) > > thanks for the updates to the MPIR texts. As this being the first pull > request I work on, I have some questions: > > 1) The pull request states it wants to merge into the > 'mpiwg-tools:mpir-1.x' branch. But don't we need a separate branch in > our fork, to enable the "final pull-request" into the mpi-forum:mpir > document? If we directly pull changes into our main branch of the > fork, how can we have separate pull requests for separate > issues/tickets that the forum has/wants to vote on? It's common to make a new branch for every pull request that you file. More specifically: it's a common Github newbie mistake to *not* make a separate branch for every PR. Consider: a PR is a request to pull in a bunch of commits to the target branch. How do you specify *which* commits that you want to be pulled? You make a branch. *All* the commits on that branch -- i.e., all the commits from the point where the branch was made to the tip of that branch -- are part of the PR. Github is even smart enough such that *if you change the branch while the PR is open, the commits listed on the PR will automatically update*. E.g., if you add more commits. Or you rebase. Or you squash commits. Or rewrite the branch to have entirely new commits (vs. when you first created the PR). ...and so on. Hence, the branch I made is in *my* fork of the mpir repo. If/when my PR is accepted (i.e., merged in), my commits will show up in the mpir repo on the mpir-1.x branch. Make sense? (pro tip: start thinking about git as a graph, in the computer science sense of the word -- then git will start making a *lot* more sense) > 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(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [mpiwg-tools] Reading of ticket #484
by Jeff Squyres (jsquyres) 09 Oct '15

09 Oct '15

I'm sorry I had to miss the call yesterday -- it sounds like you talked through these issues. Note that I filed a pull request last night with the changes that we discussed in Bordeaux: https://github.com/mpiwg-tools/mpir/pull/1 and its corresponding public issue: https://github.com/mpiwg-tools/tools-issues/issues/3 And I see in the minutes from yesterday that Anh is making the changes you discussed yesterday. Ahn: it would be better if you either filed a pull request against my repo, and then I can suck your changes into the already-existing PR. See https://github.com/mpiwg-tools/mpir/pull/1#issuecomment-146837616. > On Oct 1, 2015, at 8:58 AM, John DelSignore <John.DelSignore(a)roguewave.com> wrote: > > Hi, > > I'll be on a plane on 10/8, so I won't be able to make the call. Here are my comments (I haven't joined the MPI tool github thingy yet): >> • Martin pointed out that "the" may be ambiguous and proposed to use either "all" or "some" to avoid this ambiguity >> • current definition allows only some of the processes to have the symbol >> • in general the new wording should not restrict this >> • might this be problematic for debuggers? > > I think the intent is: > • "the" MPI starter process (e.g., mpiexec, orterun, srun, aprun, etc.), if there is one. MPICH1 doesn't have a separate starter process and TotalView still supports it, but I doubt there are any MPICH1 users anymore. > • "all" MPI processes at the time the MPIR_DEBUG_SPAWNED event is raised. > Here's why... If not all MPI processes define the symbol within the same image file (executable or shared library), it could be problematic for the debugger. TotalView does not currently set MPIR_being_debugged in the MPI processes (so this will have to change), but it does set MPIR_debug_gate in all MPI processes that define it. For the debug gate variable the TotalView client will lookup the symbol in a representative process from each unique executable in the program (the "share group"), and broadcast a write request with a "segment plus offset" relocatable address for each share group. The TotalView servers attempt to relocate that address in each MPI process, but if the process does not load the segment containing the variable the server skips it. > > So, the problem I can imagine here has to do with the variable being defined in a shared library and not all processes having the library loaded at the time the MPIR_DEBUG_SPAWNED event is raised. Also, if the library defining the symbol is loaded later, the debugger might not catch that event and set the variable. > >> >> • We need to specify that we set value to 1/0 in the process to which we attach/from which we detach >> • Do we allow only 0 and 1 or zero and non-zero values? > > TotalView uses 0 and 1. It seems to me that other non-zero values might be a problem for the MPI implementation. > >> • Do we need to be more specific on when the debugger sets the value back to 0? > > I think we said that it is set to 0 before detaching from the MPI process. Is that not specific enough? If we are going to kill the job, there should be no need to set the variable to 0. > >> • We are unspecific about what happens to the value between attach and detach. Do we need to be clearer? > > I think that the MPI implementation is allowed to test the value. I guess I don't see why it can't also modify it's value if it suits its purposes. > > Cheers, John D. > > > Marc-Andre Hermanns wrote: >> Dear all, >> >> there were several comments and modification requests during our >> reading of ticket #484 that will require another reading. >> >> I put up the notes from the reading at: >> >> >> https://github.com/mpiwg-tools/tools-issues/wiki/Notes-2015-09-24 >> >> >> Kathryn and I would like to discuss this at the next call on Oct 8, 2015. >> >> The most pressing question in advance is that we think about where the >> symbol _needs_ to be defined, if at all. The current definition is a >> little ambiguous. As the variable is optional, the common >> understanding during the discussion was that it does not have to be >> available in _every_ process. Does it lead to complications for the >> Debuggers (bookkeeping, etc.) if some MPI processes have the symbol >> and others do not? Should we rather have a "all or none" semantic? >> >> It would be great, if we could discuss this prior to next week, so we >> can finalize the wording on this ticket during the call. >> >> Cheers, >> Marc-Andre >> >> >> >> >> _______________________________________________ >> mpiwg-tools mailing list >> >> mpiwg-tools(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [mpiwg-tools] Changes from Bordeaux to MPIR
by Marc-Andre Hermanns 09 Oct '15

09 Oct '15

Hi Jeff, (CC: Wes, to keep him in the loop for process/convention finding) thanks for the updates to the MPIR texts. As this being the first pull request I work on, I have some questions: 1) The pull request states it wants to merge into the 'mpiwg-tools:mpir-1.x' branch. But don't we need a separate branch in our fork, to enable the "final pull-request" into the mpi-forum:mpir document? If we directly pull changes into our main branch of the fork, how can we have separate pull requests for separate issues/tickets that the forum has/wants to vote on? 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? 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. Would one still need "personal forks" of the documents? I could imagine to pull from personal forks into the created branch instead of working on the branch directly. Is that better practice? 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? Cheers, Marc-Andre On 09.10.15 03:52, Jeff Squyres (jsquyres) wrote: > Dresden? Where did I get that from? > > Bordeaux. :-) > >> On Oct 8, 2015, at 8:37 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: >> >> See https://github.com/mpiwg-tools/mpir/pull/1 >> >> -- >> Jeff Squyres >> jsquyres(a)cisco.com >> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> _______________________________________________ >> mpiwg-tools mailing list >> mpiwg-tools(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools > > -- Marc-Andre Hermanns Jülich Aachen Research Alliance, High Performance Computing (JARA-HPC) Jülich Supercomputing Centre (JSC) Schinkelstrasse 2 52062 Aachen Germany Phone: +49 2461 61 2509 | +49 241 80 24381 Fax: +49 2461 80 6 99753 www.jara.org/jara-hpc email: hermanns(a)jara.rwth-aachen.de

1 0

Re: [mpiwg-tools] Changes from Bordeaux to MPIR
by Jeff Squyres (jsquyres) 08 Oct '15

08 Oct '15

Dresden? Where did I get that from? Bordeaux. :-) > On Oct 8, 2015, at 8:37 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > > See https://github.com/mpiwg-tools/mpir/pull/1 > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > mpiwg-tools mailing list > mpiwg-tools(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0