RFR: 1663: Mark integrated Pull Requests as properly merged in their repositories [v37]

[Magnus Ihse Bursie]

On Mon, 21 Nov 2022 13:56:50 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Skara currently closes integrated Pull Requests, since the actual integration is done internally and then pushed to the repository separately. This makes every integrated request always look like it was closed to an outside observer, forcing the use of a special integrated flag to distinguish between integrated and closed, or rejected and closed. On top of that, it just looks awful in the interface all around (and is also not included in the accepted Pull Request count by GitHub for the committer, which is frustrating for newer contributors to a surprising extent). In the [willful absence of a reply from the GitHub team to allow marking a pull request as merged through a flag](https://github.com/orgs/community/discussions/12437), and [GitLab being unlikely to make a similar change either](https://gitlab.com/gitlab-org/gitlab/-/issues/16701), we can look at implementing this as an integration feature in Skara itself instead.
>> 
>> Every pull has a corresponding pre-integration branch created at the time it was made, and this special branch is marked for deletion when the pull is integrated, and initially it was thought to merge the Pull Request into these corresponding pr/ branches just before their deletion but that proved to present too many challenges to be viable. Instead a related approach of enhancing the Pull Request bots with their own special integration branches can be taken, as well as providing a flexible utility method for extracting the actual branch the Pull Request was integrated into, to address the concern of losing information on what the actual Pull Request target branch was.
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   GitLab should mirror the GitHub status getter

Is the core issue here if this is even a good idea? My understanding is that Erik is highly skeptical towards the entire approach, and that a specific code review is not really relevant before it can be decided if the problem this PR attempts to solve is worth the possible risk it introduces.

I think that @TheShermanTanker could perhaps make a better argument, like, concise and effective, in explaining why this would be a good thing.

And maybe @erikj79 could be more specific about what worries you, and if there are any way the proposed change could be made safe enough. Or, as the Skara Team lead, you need to declare that this PR will not be accepted, regardless of any changes.

-------------

PR: https://git.openjdk.org/skara/pull/1409