[GRASS-dev] [PROJ] [gdal-dev] github backporting application

Hi devs,

See below for cool new stuff.
I guess we also want such a Backport bot…

Markus

---------- Forwarded message ---------
From: Nyall Dawson <nyall.dawson@gmail.com>
Date: So., 17. März 2019, 20:14
Subject: Re: [PROJ] [gdal-dev] github backporting application
To: Even Rouault <even.rouault@spatialys.com>
Cc: gdal dev <gdal-dev@lists.osgeo.org>, PROJ <proj@lists.osgeo.org>

On Mon, 18 Mar 2019 at 09:06, Even Rouault <even.rouault@spatialys.com> wrote:

Hi,

I’ve just seen that QGIS has started using a github backporting application,
https://github.com/apps/backporting, and I’ve just setup it for GDAL and PROJ

So the workflow is :

  1. Create a pull request against master
  2. If backport is needed, label it with “backport {branchname}” (I’ve created
    a “backport release/2.4” for GDAL and “backport 6.0” for PROJ)
  3. Merge the pull request
  4. The backport application automatically creates a new pull request against
    the target backport branch, and cherry-picks all the commits of the original
    pull request
  5. Wait for CI to complete (or not) and merge (or not) this new PR

Of course this doesn’t solve automagically conflicts etc, but can be
convenient for trivial backports when branches are close enough

Just from a QGIS developer’s perspective:

The system is working OK, but there’s two current limitations in the
bot which make it difficult to work within nicely:

  1. Backported PRs have a generic name, e.g. “Backport #9528
    (https://github.com/qgis/QGIS/pull/9531). This makes it hard to see
    what outstanding backports are open without diving into the details of
    each. There’s a fix here for the bot, but not merged yet:
    https://github.com/tibdex/backport/pull/19 . On a similar vein, the
    backported PRs don’t include original author information, which in my
    view makes reviewing a bit harder (since we have policies in place
    that require a review from a different developer to the original
    submitter for backports to the stable branch. Not a blocker, but just
    opens the policy for easier abuse).

  2. It’s hard to track multiple backports, because currently the bot
    only supports a single branch. See
    https://github.com/tibdex/backport/pull/18 . We have to currently
    “step” the backports back through multiple branches individually by
    tagging the first auto created backport with the next branch to
    backport to. Hopefully Matthias’ PR is merged soon and fixes this
    situation, but in the meantime it’s fragile and potentially a backport
    could accidently be skipped for a branch.

Nyall


PROJ mailing list
PROJ@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/proj

On mercredi 20 mars 2019 13:26:40 CET Markus Neteler wrote:

Hi devs,

See below for cool new stuff.
I guess we also want such a Backport bot...

You also need tweaking the travis.yml/appveyor.yml to avoid useless builds to
be triggered, to save some carbon emissions and time.
The bot creates a branch in the repository, which causes it to be built by
default by CI services, but you are only interested by the pull requests
builds themselves.

See
https://github.com/OSGeo/gdal/commit/0b0160fb59757092b2b2bce4d8c253c6341e3b9e

(needs to be present in the branch(es) where you backport to)

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com