[Koha-devel] Follow-up patches and why not to use them

[Joonas Kylmälä]

Hi,

I just bumped in another case of follow-up patch style causing us
trouble. In bug
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28490 I had to
spend considerable amount of time just reverting all the problematic
patches and making sure I didn't miss any related patches, instead of
just reverting one patch and knowing I would be good to go with that.
Reverting this many patches also means a lot more review work yet again
because you have no commit messages to reference to easily or if you
want to use those you have to jump from patch to patch to find out what
the change does. And this extra review work needs to be done by two
people when reverting such follow-up patch series!

If we instead asked the original author to fix the patches then this
work would need to be done only ~once. The argument against this I have
heard is that it makes the review work harder because you don't know
what has changed since the previous version. I think however that is not
very useful because the second reviewer doesn't benefit from this at all
and makes their work harder and also the first reviewer even sometimes
might review the revision after many days by which time they have
forgotten already the context so basically they end up in the same
situation as the second reviewer and have to jump between patches.

Just my two cents, I hope we can stop doing follow-ups and instead have
commits which contain one single change to decrease our time spent on
review and make sure we don't miss any problems due to having to jump
between so many contexts.

Joonas
_______________________________________________
Koha-devel mailing list
Koha-***@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : https://www.koha-community.org/
git : https://git.koha-commun

[Julian Maurice]

Hi Joonas,

Do you know you can revert multiple commits at once (ie. only one
"revert commit" that revert a series of commits) ? Would that make it
easier for cases like that ?
And when trying to find all commits of a particular bug, git log --grep
is your friend.

Also, you can show a list of commits as a single diff. I have a git
alias defined to "diff origin/HEAD..." which shows all differences on my
local branch from the remote default branch (master).

When you have a lot of patches, I agree that it is sometimes useful to
see it as a single patch (that's why I have this git alias). But often
it makes sense to have separate patches.

By enforcing a "1 commit" rule we would lose the (often) logical
separation of patches that makes review easier.

That being said, there are other times where it would have made sense to
just squash all commits together before pushing them to master. So I
guess my opinion can be summarized at "it depends" :-)

Post by Joonas Kylmälä
Hi,
I just bumped in another case of follow-up patch style causing us
trouble. In bug
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28490 I had to
spend considerable amount of time just reverting all the problematic
patches and making sure I didn't miss any related patches, instead of
just reverting one patch and knowing I would be good to go with that.
Reverting this many patches also means a lot more review work yet again
because you have no commit messages to reference to easily or if you
want to use those you have to jump from patch to patch to find out what
the change does. And this extra review work needs to be done by two
people when reverting such follow-up patch series!
If we instead asked the original author to fix the patches then this
work would need to be done only ~once. The argument against this I have
heard is that it makes the review work harder because you don't know
what has changed since the previous version. I think however that is not
very useful because the second reviewer doesn't benefit from this at all
and makes their work harder and also the first reviewer even sometimes
might review the revision after many days by which time they have
forgotten already the context so basically they end up in the same
situation as the second reviewer and have to jump between patches.
Just my two cents, I hope we can stop doing follow-ups and instead have
commits which contain one single change to decrease our time spent on
review and make sure we don't miss any problems due to having to jump
between so many contexts.
Joonas
_______________________________________________
Koha-devel mailing list
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : https://www.koha-community.org/
git : https://git.koha-community.org/
bugs : https://bugs.koha-community.org/

[Joonas Kylmälä]

Hi,

Post by Julian Maurice
Do you know you can revert multiple commits at once (ie. only one
"revert commit" that revert a series of commits) ? Would that make it
easier for cases like that ?
And when trying to find all commits of a particular bug, git log --grep
is your friend.

Yup, however you still need to verify all the changes make sense on top
of the new code base so that doesn't help.

Post by Julian Maurice
By enforcing a "1 commit" rule we would lose the (often) logical
separation of patches that makes review easier.

I didn't suggest 1 commit hard rule per bug. I'm after commits
containing one logical change also.

Joonas
_______________________________________________
Koha-devel mailing list
Koha-***@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : https://www.koha-community.org/
git : https://git.koha-community.org/
bu