… proposed 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    
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    
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    
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).

4 Responses to … proposed changes to commit workflow

  1. Jeff Muizelaar

    Where can we find the wrapper script?

  2. Hal Wine

    It’s not yet available – this document is describing where we’re going, not yet the “here’s how to use it”. Basically, they will be modified versions of the scripts already developed and used by various m-c committers.
    I’ll be making some edits based on your feedback – hopefully that will clarify.

  3. The current commit policy was explicitly designed to cover all Mozilla projects, not just Firefox and Thunderbird. Where do you feel it falls down in that regard?

    I certainly agree that there is a need to revisit the policy to see how the principles behind it should fit with the changes of tooling.

  4. Hal Wine

    Theoretically, I agree: the current commit policy could be applied to all Mozilla work. In my experience, policy compliance is directly related to how well the supporting procedures make compliance the path of least resistance.

    We have a great story to tell on procedure (and compliance) with repositories hosted by Mozilla. For repositories of record hosted elsewhere, the story is less clear. While we could likely technically shoehorn 3rd party hosting sites into the existing policy, it would both be clumsy, and possibly disrupt the “social coding” effect Mozilla benefits from on those sites.

    Here are a few specific examples of policy & procedural gaps:

    * “Commit level” is a Mozilla concept, enforced by internal extensions to our VCS. What does that mean about using 3rd party sites where the concept doesn’t exist?

    * Projects (successful ones) move from over time from prototypes to core code. How do they cross those boundaries?

    N.B. – I’m not saying anything is broken – I’m saying as we expand our concept of Mozilla projects, we should revisit our assumptions.