Skip to content

[EPIC] Proposal for the backport of missing commits from master into next #982

@thbar

Description

@thbar

Currently, 32 commits have been added to master, which are not yet into next (or not with the same commit ids, at least). My understanding is that we need to bring back those changes into next before we can release NeTEx v2.0.

Image

I’m here first listing those commits to create a todo list, then proposing a way to gradually backport those changes safely and in reviewed manner, into next.

Commits from master not yet into next, by chronological order

I generated the list so we can track our work here, using this (+ a bit of manual editing):

git log master ^next --pretty=format:"%h %ad %an|%s" --date=iso-strict --reverse | sed -E 's/^(.*)\|.* \(#([0-9]+)\)$/\1 (#\2)/'

This gives our nice 32-commits todo list so we can follow our progress:

Proposed sync technique

I had a look at the changes we’re going to backport, using different techniques. They are quite largish and most of them will create conflicts when merging. I don’t believe at this point we can safely “merge everything in one go” and be right at the end (but if someone has a better idea, please speak).

Hence I’m proposing to do the same as @TuThoThai and I have done on the French NeTEx profile a few weeks ago: work the commits out, one by one in the chronological order, via individual PRs, which give the opportunity to properly review the changes & conflict resolution, in a lower-risk fashion.

The idea is this, for each commit (or group of commits when extremely lucky):

# THE-COMMIT-ID is a placeholder to be replaced by the actual value 

# create a local source branch from the source commit
git checkout -b backport-source-THE-COMMIT-ID THE-COMMIT-ID

# create a local target branch from `next`, & switch to it
git checkout -b backport-THE-COMMIT-ID next

# merge the source branch into the target branch
git merge backport-source-THE-COMMIT-ID --no-ff

# then: fix the conflicts in the editor, commit, push, issue a PR, review, and merge (no squash)

(the same work can be expressed with slightly different commands, but that’s the general idea)

A few important notes:

  • The PR must be modified to target next, and we then get proper reviewal process as usual, and traceability.
  • The merges must be conducted using a merge commit (so we keep the ids of the original commits, + add a merge commit, and ultimately we can track the remaining commits in the GitHub view, see screenshot at the top of this issue). No squash, no rebase!
  • To go through the list, it’s good to have authors involved (poke stefan / matthias mostly), so we can make sure we understand how we handle the conflict resolution collectively!
  • And it’s been more efficient to do that synchronously over a videocall

For this specific topic: ping @TuThoThai, @skinkie, @ue71603, @Aurige, @trurlurl at least.

Let me know what you think, and then we'll start moving forward as we can.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions