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