Hi there,

Currently Alpine supports (at least) three ways to submit patches:

	1. GitLab merge request (MR) on gitlab.alpinelinux.org
	2. GitHub pull requests (PR) on github.com/alpinelinux
	3. git-format-patches send to the mailing list (ML)

IMHO this creates an unnecessary maintenance overhead, e.g. you have to
consult three platforms to figure out if a patch has already been
submitted somewhere. Additionally, the platforms use different CI
services (or none at all in case of the ML).

Since gitlab.alpinelinux.org is fully usable nowadays I would suggest
to stop supporting GitHub PRs. Users attempting to submit PRs should be
notified that patches should either be send to the ML or submitted as
GitLab MRs. This could, for instance, be achieved through a GitHub PR
template [1].

I assume that we would like to continue using GitHub as a read-only git
mirror. Unfortunately, it does not seem to be possible to disable GitHub
PRs [2]. Other organizations seem to deal with this using a cronjob or a
GitHub bot which automatically closes all PRs periodically [3]. This
seems to be a feasible solution which we could deploy.

A problem that remains is dealing with existing PRs. Solutions include
stopping to accept new PRs and reviewing the existing ones until there
are none left or migrating them to GitLab.

Any thoughts on this proposal?

Cheers,
Sören

[1]: https://help.github.com/en/github/building-a-strong-community/creating-a-pull-request-template-for-your-repository
[2]: https://github.com/dear-github/dear-github/issues/84
[3]: https://mail.gnome.org/archives/desktop-devel-list/2016-November/msg00043.html

On Fri, 25 Oct 2019 12:32:35 +0200
soeren@soeren-tempel.net wrote:

> Since gitlab.alpinelinux.org is fully usable nowadays I would suggest
> to stop supporting GitHub PRs. Users attempting to submit PRs should
> be notified that patches should either be send to the ML or submitted
> as GitLab MRs. This could, for instance, be achieved through a GitHub
> PR template [1].
> 

We can also do what Linus' Linux tree on GitHub does and use a
KernelPRBot that comments on Pull Requests, telling how to do it
properly.

> A problem that remains is dealing with existing PRs. Solutions include
> stopping to accept new PRs and reviewing the existing ones until there
> are none left or migrating them to GitLab.
> 

Sounds good to me, current Pull Requests are reviewed and merged until
there are none. New Pull requests receive a visit from AlpinePRBot?

On Fri, 25 Oct 2019 12:32:35 +0200
soeren@soeren-tempel.net wrote:

> Hi there,
> 
> Currently Alpine supports (at least) three ways to submit patches:
> 
> 	1. GitLab merge request (MR) on gitlab.alpinelinux.org
> 	2. GitHub pull requests (PR) on github.com/alpinelinux
> 	3. git-format-patches send to the mailing list (ML)
> 
> IMHO this creates an unnecessary maintenance overhead, e.g. you have to
> consult three platforms to figure out if a patch has already been
> submitted somewhere. Additionally, the platforms use different CI
> services (or none at all in case of the ML).

Agree. This is the long term plan.

As a sidenote, it is also possible to connect the gilab login with a
github login, so you can use the github password to login to gitlab.

> Since gitlab.alpinelinux.org is fully usable nowadays I would suggest
> to stop supporting GitHub PRs. Users attempting to submit PRs should be
> notified that patches should either be send to the ML or submitted as
> GitLab MRs. This could, for instance, be achieved through a GitHub PR
> template [1].

I am all for shutting down github PRs as long as the infra team, the
people maintaining our gitlab instance is ok with it. My understanding
is that they are a bit overloaded right now, so we may need patience.

> I assume that we would like to continue using GitHub as a read-only
> git mirror. Unfortunately, it does not seem to be possible to disable
> GitHub PRs [2]. Other organizations seem to deal with this using a
> cronjob or a GitHub bot which automatically closes all PRs
> periodically [3]. This seems to be a feasible solution which we could
> deploy.
> 
> A problem that remains is dealing with existing PRs. Solutions include
> stopping to accept new PRs and reviewing the existing ones until there
> are none left or migrating them to GitLab.
> 
> Any thoughts on this proposal?

I think we want keep github as read-only mirror, yes.

I think we may need a webhook for gitlab, to do the mirror to git.a.o.
Currently we push to git.a.o and sync to gitlab, but we want push to
gitlab and sync to git.a.o, so git.a.o becomes read-only mirror with
cgit interface.

We may also want the webhook do auto closing etc, similar to what we do
now (stale bot).

If there are any volunteers with docker and gitlab maintenance
experience, who would be interested in help us, please let us know.

> 
> Cheers,
> Sören
> 
> [1]:
> https://help.github.com/en/github/building-a-strong-community/creating-a-pull-request-template-for-your-repository
> [2]: https://github.com/dear-github/dear-github/issues/84 [3]:
> https://mail.gnome.org/archives/desktop-devel-list/2016-November/msg00043.html

Leo <thinkabit.ukim@gmail.com> wrote:
> We can also do what Linus' Linux tree on GitHub does and use a
> KernelPRBot that comments on Pull Requests, telling how to do it
> properly.

I actually prefer this idea, thanks for sharing. The KernelPRBot is open
source [0], however, I personally dislike some technical decisions, e.g.
it requires a cronjob and doesn't utilize GitHub webhooks.

For this reason (and because I was looking for a simple project to
experiment with a new programming language anyhow), I ended up writing
an alternative to KernelPRBot [1]. Contrary to KernelPRBot, it uses
GitHub webhooks and can thus easily be deployed for the entire GitHub
Alpine organization.

Just as KernelPRBot it adds a custom comment to any new PR and
additionally closes it automatically afterwards (though that's
configurable).

It works as is currently, I also created an aport for it [2]. If we
decide to stick with this approach the only thing left to do is creating
a markdown comment template.

> Sounds good to me, current Pull Requests are reviewed and merged until
> there are none. New Pull requests receive a visit from AlpinePRBot?

Sounds good.

Cheers,
Sören

[0]: https://github.com/ajdlinux/PRBot
[1]: https://github.com/nmeum/noprs
[2]: https://gitlab.alpinelinux.org/alpine/aports/merge_requests/870