… 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 themain pagefor 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:

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.

(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.