[CRIU] github pull-requests

[Adrian Reber]

On Tue, Nov 20, 2018 at 12:22:21AM -0800, Andrei Vagin wrote:
> On the Linux Plumbers Conference, I heard a few requests to start
> accepting github pull-requests. Then we discussed this on the first
> official criu hackathon and it looks like there were no objections. I
> know that many of you were not able to be there, so I decided to start
> this thread where you can share thoughts about the subject.
> 
> Pros:
> * It is easier to create a pull-requests than send a patch. Stop,
> stop, stop. Don't laugh. You did this many times, but for a new
> contributor, it is a real problem.
> * We can remove all our machinery, what is used validate patches.
> 
> Cons:
> * The standard workflow is changed for people who read patches in the
> mailing list.
> * No multi-thread discussions
> 
> https://begriffs.com/posts/2018-06-05-mailing-list-vs-github.html
> 
> Questions:
> 1. Should we start accepting github pull requests?
> 2. Should we stop accepting patches from a mailing list?
> 3. Can we do both?
> 4. Which path should be a preferred one?
> 5. Do we need a robot which will send github pull-requests into the
> mailing list?
> https://github.com/google/pull-request-mailer
> 6. Do we need a robot which will create github pull-requests from patch series?
> 7. Should we sync comments between the mailing list and github?
> 8. Who wants to implement 5., 6. and 7.?

I actually prefer the mailing list as I find it easier. I do not have
to fork the repository, push my patches and open a pull request.
'git send-email' is less effort. But, to include travis testing on my
patches before sending them out, I usually push to my CRIU github fork
anyway, so right now I am most of the time doing both things already.

So I have no real preference on how the patch workflow should look in
the future. I can work with whatever we decide. I would, however, only
accept patches either through github or the mailing list, so not both.

Supporting both ways seems to require a lot of additional infrastructure
which I would try to avoid (if I would need to manage it).

As I think we should only use either github or mailing list my answers are:

1. yes
2. yes
3: no
4: github
5: no
6: no
7. no
8. ?

		Adrian