|
Size: 2167
Comment: Initial version of CrewHowTo.
|
Size: 4226
Comment: add horizontal line to separate the categories
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| #pragma section-numbers 2 | |
| Line 2: | Line 3: |
| The Mercurial 'crew' is a group of people who are allowed to push to the [[CrewRepository|crew repository]], thereby forming the gateway of moving changesets from other people's trees into the main Mercurial trees (which is managed by [[mpm|Matt Mackall]]). This page provides an outline of the crew's tasks. | |
| Line 3: | Line 5: |
| The Mercurial 'crew' is a group of people who are allowed to push to the [[CrewRepository|crew and crew-stable repositories]], thereby forming the gateway of moving changesets from other people's trees into the main Mercurial trees (which is managed by [[mpm|Matt Mackall]]). This page provides an outline of the crew's tasks. | <<TableOfContents>> |
| Line 6: | Line 8: |
| Crew can take patches, primarily through the [[MailingLists|mercurial-devel]] mailing list, but also sometimes through IRC or the [[BugTracker|BTS]]. 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). | |
| Line 7: | Line 10: |
| Crew can take patches, primarily through the [[MailingLists|mercurial-devel]] mailing list, but also sometimes through IRC or the [[BugTracking|bts]]. 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 SuccessfullPatches), 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. | == 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. |
| Line 10: | Line 14: |
| 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. | |
| Line 11: | Line 16: |
| For the simple stuff, you can just push it. 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{,-stable} tips run 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. | == The '@' bookmark == |
| Line 13: | Line 18: |
| == Pulling from main/stable == | 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. |
| Line 15: | Line 20: |
| When mpm pushes to main or stable, 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 pushes everything from main into stable. At that time, crew-stable should also get those changesets, so they get deployed to a wider audience. | 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. |
| Line 17: | Line 22: |
| == MailingLists == | == Crew is non-publishing == |
| Line 19: | Line 24: |
| /!\ 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) == Mailinglists, the wiki, and the issue tracker == |
|
| Line 21: | Line 36: |
| CategoryHowTo | 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. == 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 |
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.
Contents
1. Accepting patches
Crew can take patches, primarily through the mercurial-devel mailing list, but also sometimes through IRC or the BTS. 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
![/!\](/moin-static/modernized/img/alert.png "/!\"){kind=small}
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.