[GRASS-dev] Backport sync: merge mess

[Vaclav Petras]

On Wed, Apr 8, 2020 at 5:13 PM Markus Neteler <neteler at osgeo.org> wrote:

> Hi Vaclav,
>
> Thanks for your extensive explanations! Much appreciated.
>
> I think that I have probably found the missing part: I should have
> deleted the *entire* directory. By just deleting my fork and re-adding
> it as a "remote" I probably still had all the clutter in my local
> copy.
>
> Today I have
> - trashed the entire directory
> - clones the repo
> - deleted my fork and created it again
> - added the fork as a "remote"
>

This does not sound like recommended workflow: clone fork as origin, add
OSGeo as upstream. Are you aware of that?

Related to that, I'm not sure why most projects using this workflow use the
name origin for one's own fork. Calling it fork, myfork or <username> seems
more explicit. Perhaps something to consider.


> Magically (well, not really), it seems to be clean.
>
> Might that be the explanation, that I didn't properly start from scratch?
>

Since I saw old Merge... commits in your fork, they were preserved locally
or in the fork and propagated through pull/fetch or push.


>
> What might have happened:
> ...
> - as you guessed, I probably cherry-picked, didn't commit due to my
> network issues on the road, then other backports happened and I tried
> to push on top of that
>

...which is hard to avoid which in turn creates the Merge... commits which
we now consider unnecessary. So I updated the wiki (how to backport a
single commit and made a mess sections including some explanations):

https://trac.osgeo.org/grass/wiki/HowToGit#Backportingtoreleasebranches

I did not test the rebase workflow myself, but it turned out, I suggested
the workflow to Anna who was successfully using it for some time now
(although I think she did not get into the same situation as you did, so
not really tested for that, you can test with two clones if you want).


> Question: would the (somewhere) existing backport bot help here?
>

The new workflow with rebase should give us now the expected behavior, so I
don't think it is needed for that.

As far as automating backports, with GitHub Actions automating should be
quite possible.

https://github.com/marketplace/actions/backport-commit
https://github.com/marketplace/actions/backporting
(and there is more)

For anything like that we need to spell out our backporting policies. For
example, I'm just against immediate backports because I think the change
needs to settle. We had several cases of immediate backport and then quick
series of fixes or reverts which does not seem right as it lowers the
stability of a the stable branch. I don't see a setting of a delay in
settings of the above actions which would make me happy. Using two labels
one for humans and another for the bot would work in the same way without
the possibly confusing delay and including some human consideration.
Anyway, my point is that it is possible, but it requires more research. On
top of that, the GitHub Actions (both the infrastructure and the available
actions) are a moving target.

Vaclav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20200408/fa9341f6/attachment.html>