[Skiboot] [PATCH] github: update pull request template

[Klaus Heinrich Kiwi]

On 6/4/2020 2:11 AM, Andrew Donnellan wrote:
> On 4/6/20 1:53 pm, Oliver O'Halloran wrote:
>> The current wording is a bit curt. Flesh it out a bit and put in some
>> useful detail.
>>
>> Signed-off-by: Oliver O'Halloran <oohall at gmail.com>
> 
> New message looks good.
> 
> Reviewed-by: Andrew Donnellan <ajd at linux.ibm.com>
Reviewed-by: Klaus Heinrich Kiwi <klaus at linux.vnet.ibm.com>
> 
>> ---
>> I guess the real question we should be asking is: Why don't we take
>> github pull requests? The best answer I can offer is that it seems to
>> be impossible to get the DCO (the signed-off-by, etc) correct when using
>> PRs since github doesn't let you screw with the patches proper when
>> merging a PR. As far as I can tell anyway, I could be wrong.
> 
> The DCO issue is addressable by a CI bot that tells you off for screwing that up, and then abandoning the idea that the maintainer who commits it has to add their own SOB. Though there are other cases where maintainers want to fix up commit messages or minor fixes during merge which aren't as practical with GitHub.

I believe Github by default allow changes to forked PR branches by the upstream repo maintainers: https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/allowing-changes-to-a-pull-request-branch-created-from-a-fork
So if the submitter hasn't explicitly disabled it, I believe maintainers are able to "fix" the PR in whatever ways necessary before applying the commit.

If it's a simple patch (no multi-part), I will usually opt to "rebase and merge" (which is a --ff merge) instead of adding a merge commit. If it's multi-part and a merge is in order, the maintainer will always have the opportunity to manually add it in it's own merge commit message, but I wonder if it's really necessary, considering the actual content being committed should already have the SOBs enforced from the DCO bot check (when enabled).

> 
> The bigger issue to me is that I think it's best if the project has one path for submitting patches. It may be better to be all-or-nothing and switch to GitHub completely if it suits our needs, I'm less keen on having 70% of patches go through the mailing list and 30% go through GitHub.

+1 here. I'll admit I actually like the Github-workflow better than mailing-list + patchwork. Nowadays we have a plethora of bots that could act on PRs (travis included, which should be available for ppc64le targets) that could be helpful, not mentioning the overall integration with reviews, issues etc. The downside is that conversation will probably move to github PRs and issues, something anyone interested would have to subscribe to and monitor if they want to be part of the conversation (in that sense not much different from mailing-lists).

  -Klaus

-- 
Klaus Heinrich Kiwi <klaus at linux.vnet.ibm.com>