[mpiwg-tools] Changes from Bordeaux to MPIR

[Marc-Andre Hermanns]

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 at jara.rwth-aachen.de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4899 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-tools/attachments/20151009/5fefd438/attachment-0001.bin>