Development policy for Rust.
We request that contributions are made via pull request and review. Note that all patches from all contributors get reviewed. After a pull request is made other contributors will offer feedback, and if the patch passes review someone with official review privileges will accept it with an "r+" comment. Upon successful review, pull requests are tested and merged automatically by our integration bot, bors. When pull requests fail integration testing authors are expected to update their pull requests to address the failures until the tests pass and the pull request merges successfully.
Those with review privileges or direct push access are required to file a Mozilla "committer agreement". This is a short (1-page) legal agreement that asserts certain claims of originality, absence of conflict with other agreements, and similar terms associated with licensing and authorization. If you already have Level 1 or higher commit rights within the Mozilla project, you have already filled out such a form. Committer agreements are generally only required for reviewers and those with direct push access to the master repository, though we will occasionally also request agreements for large, non-trivial contributions. If you would like to be a reviewer then please discuss in with one of the core contributors through IRC or email.
In the issue tracker, bugs can only be assigned to people who have commit access. Also, we aspire to make as many bugs as possible "owned" by assigning them to a core Rust contributor. Therefore, just because a bug is assigned doesn't mean it's being actively worked on. We (the core contributors) are all busy, and welcome help from the community. If you see a bug you'd like to work on that's assigned but appears to be dormant, communicate with the bug's owner (by IRC, email, or with an @-reply in a comment on the issue page). If you see a bug you'd like to work on that's unassigned, it's fair game: comment to say you'd like to work on it so that we know it's getting attention.
To make a pull request, you will need a Github account; if you're unclear on this process, see Github's documentation on forking and pull requests. Pull requests should be targeted at Rust's
master branch. Before pushing to your Github repo and issuing the pull request, please do two things:
masterbranch. Resolve any conflicts that arise.
make checkcommand. You're not off the hook even if you just stick to documentation; code examples in the docs are tested as well!
Pull requests will be treated as "review requests", and we will give feedback we expect to see corrected on style and substance before pulling. Changes contributed via pull request should focus on a single issue at a time, like any other. We will not look kindly on pull-requests that try to "sneak" unrelated changes in.
Normally, all pull requests must include regression tests (see Note-testsuite) that test your change. Occasionally, a change will be very difficult to test for. In those cases, please include a note in your commit message explaining why.
The copyright header at the top of the file should include a date range that includes any years in which the file was changed in a significant way. For example, if it's 2013, and you change a file that has existed since 2010, it should begin
// Copyright 2010-2013 The Rust Project Developers.
Pass the existing tests. If you have a good reason for breaking a test, XFAIL it. We aim for clean builds at all times.
There is an IRC channel on irc.mozilla.org, channel #rust. You're welcome to drop in and ask questions, discuss bugs and such. It is logged at http://irclog.gr/#browse/irc.mozilla.org/rust
There is also a mailing list at https://mail.mozilla.org/listinfo/rust-dev.
In both contexts, please follow the conduct guidelines above. Language issues are often contentious and we'd like to keep discussion brief, civil and focused on what we're actually doing, not wandering off into too much imaginary stuff.
Add a test to the testsuite for anything you're unsure of or see breaking in passing. See Note testsuite for details.
File bugs in the issue tracker here as well as adding tests, or instead if you can't quite figure out how to test the thing you want to point out.
Tag bugs liberally. The bug tracker here currently has weak search capabilities. Github staff has made a variety of comments suggesting "they're working on it", but in the meantime tags are our only hope. (There's also GHI on Heroku, but it's slow.)
Tags in the tracker have specific definitions and in groups:
[A-foo]tags mean that the bug is in the area of "foo", meaning that someone who wants to work on the foo modules in the compiler should look at it. These should be pretty specific areas, not vague. Some bugs will be tagged with multiple areas because they cut across areas.
[B-foo]tags mean that the bug is blocked in a particular state, such as "wanting clarification" or "RFC". These are effectively workflow-oriented tags, so we can try to attack bugs that are stuck in a particular state of their life and could possibly become unstuck. Just "awaiting someone to do the work" is not a blocked state. A bug should be in zero or one
[B-foo]states, no more than one.
[E-foo]tags indicate a guess of the effort required by a bug. Most bugs are "medium" and don't need such tags; but some are especially easy or hard, and this can be helpful to highlight.
[I-foo]tags area subjective judgment of importance. A bug should be in only one
[I-foo]state. "Wishlist" is the least important: used for non-core features that would be nice to have, but don't need to be scheduled for any particular time.
[P-foo]priority tags are used for release planning. These are the only tags that should not be applied based on individual judgement - they are instead applied as part of the triage process, described below.
Add "FIXME (issue #NN): blah blah" in the source anywhere you see room for improvement, where #NN is the issue number in the tracker here. If you fix an issue on commit, remove the associated FIXMEs (grep for other occurrences) and put the exact phrase "Closes #NN" (with that capitalization) in the commit message and github will pick it up and link to the commit, close the issue.
While Rust point releases are time-based (not feature-based) we still prioritize which issues to work on, particularly as we progress toward the first major release. High-priority issues are tagged with the
P tags, and optionally assigned to a major release milestone (which are feature-based). Issues that impact backwards compatibility are always high priority, but there are additional criteria as well.
When you see an issue that fits the criteria:
Do not assign the issue to a milestone or a priority tag yourself.
Every week there is a bug triage meeting. At that meeting the attendees will review the issues tagged
I-nominated and decide whether the nomination is accepted. If accepted, the issue will be added to a milestone and/or tagged; if not, then a comment will be added explaining why. In either case the
I-nominated tag will then be removed.
Major changes (including all language enhancements) must go through the RFC process.
Last edited by Brian Anderson,