+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, 6:57 AM, "mpiwg-tools on behalf of Bland, Wesley"
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:
So that people besides the WG lead can't just clobber integration or
master.
Thoughts?
-Todd
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
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
For corporate legal information go to:
_______________________________________________
mpiwg-tools mailing list
_______________________________________________
mpiwg-tools mailing list