README: contrinuting: add request to avoid force-push to an existing PR

Submitted by Mike Rapoport on June 6, 2020, 5:03 p.m.

Details

Message ID 20200606170348.237542-1-rppt@linux.ibm.com
State New
Series "README: contrinuting: add request to avoid force-push to an existing PR"
Headers show

Commit Message

Mike Rapoport June 6, 2020, 5:03 p.m.
The updates of an existing pull request are hard to review because it is
not clear what was changed from the previous version.
It would be easier for reviewers and maintainers to have the PR closed
and then opened again with the updated changes and a brief description
of changes between the versions.

Add a text to README.md that will emphasize this.

Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
---
 README.md | 2 ++
 1 file changed, 2 insertions(+)

Patch hide | download patch | download mbox

diff --git a/README.md b/README.md
index 6a578b953..6f82c8241 100644
--- a/README.md
+++ b/README.md
@@ -68,6 +68,8 @@  Here are some useful hints to get involved.
 * Documentation is always hard, we have [some information](https://criu.org/Category:Empty_articles) that is to be extracted from people's heads into wiki pages as well as [some texts](https://criu.org/Category:Editor_help_needed) that all need to be converted into useful articles;
 * Feedback is expected on the github issues page and on the [mailing list](https://lists.openvz.org/mailman/listinfo/criu);
 * We accept github pull requests and this is the preferred way to contribute to CRIU. If you prefer to send patches by email, you are welcome to send them to [the devel list](http://criu.org/How_to_submit_patches);
+  * Please avoid force pushing updates to an existent pull request. Close the pull request and open a new one with the updated changes.
+  * Mention what were the changes between different versions of a pull request. It makes reviewers and maintainers life much easier.
 * Spread the word about CRIU in [social networks](http://criu.org/Contacts);
 * If you're giving a talk about CRIU -- let us know, we'll mention it on the [wiki main page](https://criu.org/News/events);
 

Comments

Pavel Emelyanov June 6, 2020, 7:03 p.m.
сб, 6 июн. 2020 г. в 20:03, Mike Rapoport <rppt@linux.ibm.com>:

> The updates of an existing pull request are hard to review because it is
> not clear what was changed from the previous version.
> It would be easier for reviewers and maintainers to have the PR closed
> and then opened again with the updated changes and a brief description
> of changes between the versions.
>
> Add a text to README.md that will emphasize this.
>
> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
> ---
>  README.md | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/README.md b/README.md
> index 6a578b953..6f82c8241 100644
> --- a/README.md
> +++ b/README.md
> @@ -68,6 +68,8 @@ Here are some useful hints to get involved.
>  * Documentation is always hard, we have [some information](
> https://criu.org/Category:Empty_articles) that is to be extracted from
> people's heads into wiki pages as well as [some texts](
> https://criu.org/Category:Editor_help_needed) that all need to be
> converted into useful articles;
>  * Feedback is expected on the github issues page and on the [mailing
> list](https://lists.openvz.org/mailman/listinfo/criu);
>  * We accept github pull requests and this is the preferred way to
> contribute to CRIU. If you prefer to send patches by email, you are welcome
> to send them to [the devel list](http://criu.org/How_to_submit_patches);
> +  * Please avoid force pushing updates to an existent pull request. Close
> the pull request and open a new one with the updated changes.
>

This makes it hard to track history. When the 2nd version is pushed
maintainer should knows that a) it's vN+1 and b) what whas in vN.
I agree that github PRs suck in many ways though.


> +  * Mention what were the changes between different versions of a pull
> request. It makes reviewers and maintainers life much easier.
>  * Spread the word about CRIU in [social networks](
> http://criu.org/Contacts);
>  * If you're giving a talk about CRIU -- let us know, we'll mention it on
> the [wiki main page](https://criu.org/News/events);
>
> --
> 2.25.4
>
>
Alexander Mihalicyn June 6, 2020, 7:40 p.m.
Hello, guys!

What about different way? Contributor adds changes between patchset
versions as additional commits then, after all reviews are done and
patchset is ready to merge,
author squashes/rebases and pushes clean patchset version.

Regards, Alex

On Sat, Jun 6, 2020 at 10:07 PM Pavel Emelyanov <ovzxemul@gmail.com> wrote:
>
>
>
> сб, 6 июн. 2020 г. в 20:03, Mike Rapoport <rppt@linux.ibm.com>:
>>
>> The updates of an existing pull request are hard to review because it is
>> not clear what was changed from the previous version.
>> It would be easier for reviewers and maintainers to have the PR closed
>> and then opened again with the updated changes and a brief description
>> of changes between the versions.
>>
>> Add a text to README.md that will emphasize this.
>>
>> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
>> ---
>>  README.md | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/README.md b/README.md
>> index 6a578b953..6f82c8241 100644
>> --- a/README.md
>> +++ b/README.md
>> @@ -68,6 +68,8 @@ Here are some useful hints to get involved.
>>  * Documentation is always hard, we have [some information](https://criu.org/Category:Empty_articles) that is to be extracted from people's heads into wiki pages as well as [some texts](https://criu.org/Category:Editor_help_needed) that all need to be converted into useful articles;
>>  * Feedback is expected on the github issues page and on the [mailing list](https://lists.openvz.org/mailman/listinfo/criu);
>>  * We accept github pull requests and this is the preferred way to contribute to CRIU. If you prefer to send patches by email, you are welcome to send them to [the devel list](http://criu.org/How_to_submit_patches);
>> +  * Please avoid force pushing updates to an existent pull request. Close the pull request and open a new one with the updated changes.
>
>
> This makes it hard to track history. When the 2nd version is pushed maintainer should knows that a) it's vN+1 and b) what whas in vN.
> I agree that github PRs suck in many ways though.
>
>>
>> +  * Mention what were the changes between different versions of a pull request. It makes reviewers and maintainers life much easier.
>>  * Spread the word about CRIU in [social networks](http://criu.org/Contacts);
>>  * If you're giving a talk about CRIU -- let us know, we'll mention it on the [wiki main page](https://criu.org/News/events);
>>
>> --
>> 2.25.4
>>
> _______________________________________________
> CRIU mailing list
> CRIU@openvz.org
> https://lists.openvz.org/mailman/listinfo/criu