PR final steps (to squash or not to squash)

[Mojca Miklavec]

On 6 December 2016 at 10:34, René J.V. Bertin wrote:
> On Monday December 5 2016 22:52:51 Lawrence Velázquez wrote:
>
>> Fetching from a fork does not download the full history. Only the
>> objects that are not in your repository are fetched.
>
> That implies adding the fork as another remote with the associated house-keeping afterwards?

No.

You can do:

USER=some-username
REMOTEBR=remote-branch-name
LOCALBR=local-branch-name

git fetch https://github.com/$USER/macports-ports.git $REMOTEBR
git checkout -b $LOCALBR FETCH_HEAD
# git rebase master

> Not that it's directly relevant to the topic at hand, but how many committers are there?

https://trac.macports.org/wiki/MacPortsDevelopers

> It would be very good to get more committers involved in the revision process.

While I agree with that, it's all voluntary work.

> I'm not sure how; the peer review process as used in scientific publication comes to mind (oh, the fond memories...), where an "editor" (ideally picked by the author) requests timely reviews from a number of referees. Question is of course who those editors would be, and who'd appoint them.

The huge difference is that people involved in scientific journals
(either as authors, reviewers or editors) often have a monetary
interest in one way or another (ok, in realy the publisher has the
biggest interest and all others are free workers for the publisher,
but let's not get this off-topic). Doing scientific publishing is
essential to get sufficient "points" to stay on the payrole at
institutes and universities around the world.

For me MacPorts is exactly the opposite: a distraction that makes me
do *LESS* of what counts for my career (and sometimes even bites off
my time at work).

Getting random assignments that I don't understand / don't know how to
test / don't have time to work on / or am not interested to do, would
probably backfire and would hardly help.

What we *do* miss though is some easier browsing through trac tickets.
With thousands of tickets open and zero overview of which tickets:
- only need the final OK and commit from a reviewer
- are waiting for maintainer's approval (and are already due for committing)
- don't get committed because the non-maintainer is too polite/kind
and doesn't want the maintainer to get angry due to a non-authorized
commit
- need someone to solve a potentially trivial problem
- just need someone to take 5 minutes to finish the work
- need an agreement of *how* to implement things
- just need tedious, but otherwise trivial work
- ...

>>> Side-ways related: maybe the Git/PR wiki topic could say a word or two
>>> about when a rebase request might be made before a PR can be merged.
>>
>>Huh?
>
> The how to work with git wiki topic about pull requests ("Updating your fork") states something like "we might ask you to rebase your changes on top of our current master branch". A bit of explanation when and why such a request might occur won't hurt.

I can explain here, but someone needs to edit the page.

When someone submits a pull request (let's assume that it's already
perfect) and a committer fetches it, rebases it and commits it to the
master, then the PR is not automatically linked to the commit (if
rebasing happens in the meantime). Alternatives are:

(a) press the rebase button on the website
(b) force push to the branch of PR
(c) ask the author to rebase
(d) accept the fact that the two are not linked

Problems:

(a) Committer's email is "random" rather than username at macports.org
(b) The one submitting the PR has to allow this (not everyone is happy with it)
(c) Timing. It's basically impossible to assure that even after the
author rebases, some committer will pick it up and commit it fast
enough (= before another commit flies in).
(d) The obvious. PR will be marked as Closed (rejected?) rather than Merged.

>From the perspective of GIT updating (rebasing) the PR is not really
required, it's just the workflow at GitHub that's flawed.

I cannot find the relevant "quasi-upstream" ticket right now, but an
example would be
    https://github.com/todogroup/gh-issues/issues/40

Mojca