[CRIU] github pull-requests

[Radostin Stoyanov]

On 12/02/2019 18:20, Andrei Vagin wrote:
> On Mon, Feb 11, 2019 at 10:16 AM Radostin Stoyanov <rstoyanov1 at gmail.com> wrote:
>> On 11/02/2019 17:52, Andrei Vagin wrote:
>>> On Sun, Feb 10, 2019 at 06:05:56PM +0200, Mike Rapoport wrote:
>>>> On Fri, Feb 01, 2019 at 09:45:36AM -0800, Andrei Vagin wrote:
>>>>> Hi All,
>>>>>
>>>>>
>>>>> Let's start this experiment. Starting from today, you can create
>>>>> pull-requests on github. And it is a preferred way to submit changes.
>>>> And how github pull requests are supposed to handle Acked-by and
>>>> Reviewed-by? :-O
>>> Good question! Could you spend a few minutes and look how it is handled
>>> in other projects? ;)
>> I think that "Approve changes" is the closes to Acked-by or Reviewed-by
> "Approve changes" are not saved in the git history, are they?
No, they are not. Looking at this guide:
https://github.com/nodejs/node/blob/master/COLLABORATOR_GUIDE.md

the answer is: Never use GitHub's green "Merge Pull Request" button.

* The "Create a merge commit" method will add an unnecessary merge commit.

* The "Squash and merge" method will add metadata (the PR #) to the
commit title. If more than one author has contributed to the PR,
squashing will only keep the most recent author.

* The "Rebase and merge" method has no way of adding metadata to the commit.

>> https://help.github.com/articles/about-pull-request-reviews/
>>>>> On Tue, Nov 20, 2018 at 12:22:21AM -0800, Andrei Vagin wrote:
>>>>>> Hello,
>>>>>>
>>>>>> 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.?
>>>>>>
>>>>>> My answers:
>>>>>> 1. yes
>>>>>> 2. no
>>>>>> 3. yes
>>>>>> 4. the mailing list
>>>>>> 5. yes
>>>>>> 6. would be good
>>>>>> 7. would be good
>>>>>> 8. I don't :)
>>>>>>
>>>>>> Thanks,
>>>>>> Andrei Vagin
>>>>> _______________________________________________
>>>>> CRIU mailing list
>>>>> CRIU at openvz.org
>>>>> https://lists.openvz.org/mailman/listinfo/criu
>>>>>
>>>> --
>>>> Sincerely yours,
>>>> Mike.
>>>>
>>> _______________________________________________
>>> CRIU mailing list
>>> CRIU at openvz.org
>>> https://lists.openvz.org/mailman/listinfo/criu