I am the blog of Hal Fire, and I bring you…

… interesting tidbits of release engineering.

Changes to commit workflow

[This is an experiment in publishing a doc piece by piece as blog entries. Please refer to the main page for additional context.]

With all the changes to support git, how will that affect a committer’s workflow? (For developer impact, see this post.)

The primary goal is to work within the existing Mozilla commit policy [1]. Working within that constraint, the idea is “as little as possible”, and this post will try to describe how big “as little” is.

Remember: all existing ways of working with hg will continue to work! These are just going to be some additional options for folks who prefer to use github & bitbucket.

Introduction

To start things off, here are the simplified workflows that describe how things currently work with the Mercurial repositories on hg.m.o and following commit policy. The major differences between the committer’s workflow and the developer’s workflow are:

  • the source of the changes (could be patches from developers without commit access, in addition to development work done directly by the committer).
  • the ultimate destination repository is the repository of record hosted on hg.mozilla.org.

The following table should match today’s workflow for landing someone else’s (or their own) approved patch:

Committer Action Steps Involved Pseudo Commands
First time checkout [2]    
get personal copy  
get copy on PC hg clone hg.m.o PC
tweak for 1 step commit to hg add hg.m.o as pushable path
Work Cycle    
update local repo to tip hg pull –update
incorporate r+ work [3] hg patch OR pull from github or bitbucket (may not match r+ attachment) [4]
resolve conflicts  
local work hg commit
Commit Process    
  hg push hg.m.o

Changes for Bitbucket

As bitbucket uses mercurial as it’s primary DVCS, you might expect there to be not too many changes. That’s correct - there is just some additional steps on bitbucket so other users can see your work.

The changes from hg.m.o are italicized.

Committer Action Steps Involved Pseudo Commands
First time checkout [2]    
get personal copy bitbucket fork
get copy on PC hg clone bitbucket PC
tweak for 1 step commit to hg add hg.m.o as pushable path
Work Cycle    
update local repo to tip hg pull –update
incorporate r+ work [3] hg patch OR pull from github or bitbucket (may not match r+ attachment) [4]
resolve conflicts  
local work hg commit
Commit Process    
  hg push hg.m.o

Changes for Github

For github, there are a few additional steps that will be supported by scripts. As above, the differences from hg.m.o are italicized.

Committer Action Steps Involved Pseudo Commands
First time checkout [2]    
get personal copy github fork
get copy on PC git clone github PC
tweak for 1 step commit to hg run script to setup hg repo & git post commit hooks & magic_refs [5]
Work Cycle    
update local repo to tip git pull
incorporate r+ work [3] apply patch manually OR pull from github or bitbucket (but may not match r+ attachment) [4]
resolve conflicts  
local work git commit
Commit Process    
  git push magic_ref [5]

Notes

[1]There is a strong case to be made for revising the commit policy to account for both new tooling (e.g. github/bitbucket) and new Mozilla projects (e.g. everything beyond Firefox/Thunderbird). A policy discussion involves a lot more groups, and is explicitly out of scope of this effort.
[2](1, 2, 3) assumes committer keeps “clean repo” for all push to moz actions (best practice)
[3](1, 2, 3) due to patch rot, the committer may need to make adjustments to the patch. It’s up to the authorized committer to decide if such changes require re-approval.
[4](1, 2, 3) directly incorporating a pull request (from either github, bitbucket, or any other hosting service) is straightforward with the hg-git extension installed in Mercurial, if the other repo was based on the same original. This requires coordination among the team members.
[5](1, 2) This is how several developers now work, what’s new is the wrapper script to make it easy to setup. See the reference section of the main project page for links to their original code (which will be the basis for this project).

Change Log

2012-03-21 Added step of bring local repository up to date prior to incorporating changes.