PR final steps (to squash or not to squash)

[René J.V. Bertin]

On Tuesday December 6 2016 14:36:25 Mojca Miklavec wrote:

>> It would be very good to get more committers involved in the revision process.
>
>While I agree with that, it's all voluntary work.

Of course it is, probably shouldn't be anything else either.

>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 ... 
>... essential to get sufficient "points" to stay on the payrole at
>institutes and universities around the world.

There is usually no reward whatsoever in accepting to do a review. Other than the moral compensation that you are contributing to a system on which you depend yourself also and that just works better if every reviewer does his/her job properly and constructively.

You're right about the publishing houses, and editors (or their institutes) working for certain big journals may indeed get a monetary compensation but there are more and more "open" journals where this is not the case at all to my knowledge.

>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.

That suggests a misunderstanding. Reviewers of scientific publications aren't selected at random but based on their past work and known fields of interest - and there's never any form of obligation. Evidently you can expect repercussions on your next own submission if you always refuse reviews you're asked to do, regardless of how suitable you'd be, but I don't think that's a bad thing per se.

This does imply that people currently having commit access can only play the editor role, because they can bypass the reviewing process themselves.

>What we *do* miss though is some easier browsing through trac tickets.
>With thousands of tickets open and zero overview of which tickets:
...

Most non-trivial things to detect automatically, no? The only easy thing to sort this out might be to have a timeout mechanism that starts sending alerts to the reported and assignee after a ticket has been idle for too long?


>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).

Why not simply close the PR in that case, possibly with an explicative note?

So anyway a rebase request would only happen if the patch is committed in another way than through github? Or did you you just omit the case where someone changes something to the port the patch applies too because it's too obvious?

Either way that's more than the few words I had in mind :)


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

In fact, is there no github commit message magic that can close a PR? KDE's review and bug tickets can be closed by referencing them in the commit message:

REVIEW:<RR ticket>
BUG:<BKO ticket>