Crew

The Mercurial 'crew' is a group of people who are allowed to push to the crew repository, thereby forming the gateway of moving changesets from other people's trees into the main Mercurial trees (which is managed by Matt Mackall). This page provides an outline of the crew's tasks.

1. Accepting patches

Crew can take patches, primarily through the mercurial-devel mailing list. If they are straightforward, they can be pushed into crew or crew-stable quickly (see CrewRepository for the distinction). In other cases, some discussion on the mailing list or several iterations of the patch will be required to get the patch in good shape. In general, guide contributors along the way of getting their patches accepted, including helping them find the right people for review. When a patch is deemed sufficient (see also ContributingChanges), don't forget to thank contributors for their patches, and be sure to change the status for any relevant issues if you do push a patch (as per ManagingBugs).

2. Pulling from main

When mpm pushes to main, a notice will pop up on the mercurial-devel list within an hour. If that happens, you can usually pull from him and push his changesets to crew (hopefully after reviewing any new changesets). After release or at feature freeze, mpm merges from default into stable branch. At that time, crew should also get those changesets, so they get deployed to a wider audience.

3. Pushing your own

For the simple stuff, you can just push it (but pull from main first before committing your changes on top to avoid needless merges). If it's a larger issue that might require some design discussion, just post it to mercurial-devel and await discussion there. Of course, try to always make sure the crew tip runs the test suite without consistent errors. If you find that someone else broke something, try to fix it or notify them so they can fix it themselves.

4. The '@' bookmark

In order to help us uncover bugs in bookmarks behavior, we are using an '@' bookmark on the crew repository. Crew members should try to keep it as their active bookmark as they queue changes, so that it will stay at the head of crew. If the active bookmark behavior is working right, this should be all you need to do.

The one exception to this is if you are queueing changes for stable outside of a code freeze -- when you queue the stable changes and then switch back to the default branch, you should 'hg update @' to make the bookmark active again.

5. Crew is non-publishing

People pushing to crew want to have the EvolveExtension enabled.

Crew is now a non publishing repo. This means that content from crew may be rewritten by Matt at any time. (see ChangesetEvolution) for details.

Content on crew but not in main are kept in the draft Phases. Keep in mind that crew is for ready and properly tested changes. Rewriting of it's content should be rare.

Rewrite **MUST** happen with ChangesetEvolution turned (using EvolveExtension)

6. Mailinglists, the wiki, and the issue tracker

Read both mailing lists; help out with support in the general list, and help guide contributors or review patches and design on the development list.

There is a fair amount of communication going on in Mercurial which does not reach the mailinglists because it takes place on the wiki or on the issue tracker. So create an account for the wiki and subscribe to all pages that look vaguely interesting (subscribe to this page!). Do the same for the bug tracker. That will help to keep you in the loop on what's going on in the Mercurial community.

7. Hgtester

Ry4an offers a hgtester service for trusted crew members. See http://ry4an.org/unblog/UnBlog/2010-04-15 and send your ssh public key to ry4an@ry4an.org to get access. To test a repo push it to ssh://hgtester@ry4an.org:2222 (which will be seeded with the crew repo) and wait 4 minutes. The test output will be received as result of the push and then the server will forget everything.

CategoryProject CategoryDeveloper