[Python-Dev] Mercurial migration: progress report (PEP 385)

[Nick Coghlan]

Martin v. Löwis wrote:
> What will need debate and discussion in the PEP is the workflow, ie.
> the order in which changes should be applied to the branches.

Particularly since there isn't even "one true workflow" *now*. I see
three main variants go by on Python-checkins:

- svnmerge based
  - commit to 2.x
  - backport to 2.6 with svnmerge
  - forward port to 3.x with svnmerge
  - backport to 3.0 (now 3.1) with svnmerge

- manual port based
  - as above, but without using svnmerge

- Py3k focused
  - commit to 3.x
  - manual backport to 2.x
  - possible svnmerge block of the backported 2.x commit
  - possible svnmerge based or manual backport to 2.6/3.1

While it would obviously be *nice* if every committer maintained 4
checkouts and either blocked or committed each change on the appropriate
branches, I think actually *requiring* a specific workflow has the
potential to cost us commits. Even if one workflow is designated the
'preferred' approach, the others still need to be supported to handle
various possibilities for the "first" commit for a given change:

- forward port only
  - commit to 2.6
  - forward port to 2.x
  - forward port to 3.1
  - forward port to 3.x

- backport only
  - commit to 3.x
  - backport to 3.1
  - backport to 2.x
  - backport to 2.6

- mixed, starting with 2.x (aka current svnmerge workflow)
  - commit to 2.x
  - backport to 2.6
  - forward port to 3.x
  - backport to 3.1

- mixed, starting with 3.1
  - commit to 3.1
  - forward port to 3.x
  - backport to 2.6
  - forward port or backport to 2.x

Note that there are actual multiple variations even of the above
workflows, based on the *source* of the various forward ports and
backports. Also, each "forward port" or "backport" can be replaced by
blocking the merge rather than applying it.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------