[rust-dev] Refactoring the milestones on the issue tracker

Brian Anderson banderson at mozilla.com
Thu Oct 10 21:17:00 PDT 2013

Hey, Rustlings!

During the bug triage meeting today we decided to make a few changes to 
how our milestones on GitHub are organized in order to be better 
oriented towards our goals for the near future.

Recently the core team has been putting a lot of thought into what it's 
going to take to get a major, stable release of Rust finished, and it's 
become clear that the way we've been organizing the milestones is not 
representative of the actual work we believe must be done.

We previously triaged the entire set of issues into 5 categories: 
well-defined, backwards compatible, well-covered, feature complete, and 
production ready. It's not clear though how useful this exercise was; 
certainly figuring out the set of issues with backwards-compatibility 
implications was important, but it appears both that the scope of all 
these milestones together is much greater than anything we can 
accomplish in a reasonable timeframe, and also that there were many 
issues triaged into the backwards-compatible milestone that don't 
necessarily need to be resolved. In the end, this scheme did not well 
capture the actual work that we need to do.

For reference this approach was previously described here: 

Today we're simplifying our triage scheme in the following ways:

* The previous 'maturity milestones' have been converted to 'P' 
(priority) tags on the issue tracker: P-backcompat-lang, 
P-backcompat-libs, P-high, and P-low; and all of the previously triaged 
issues have been tagged. Converting from milestones to tags emphasizes 
that these are simply categories, not singular goals that occur in any 
specific order, and the naming emphasizes that what we mostly care about 
for completing a major release is backwards compatibility of the 
language and libraries.
* We now have an upcoming [milestone] called "first major release". This 
is tentatively Rust 1.0 and is intended to represent the complete set of 
work that we need to do to get a major release out of the door. Unlike 
our typical point releases, this will be a feature-based release.
* We'll keep the [nomination] process intact, but instead of triaging 
bugs into maturity milestones, they will be given P-tags and possibly 
assigned to the first major release milestone.
The [criteria] for nomination is still the same as for the previous 
maturity milestones.

[milestone]: https://github.com/mozilla/rust/issues/milestones

In the past few weeks we've already triaged all the "well-defined" and 
"backwards compatible" issues to determine the subset to move into the 
"first major release" milestone. The remaining issues from the maturity 
milestones are temporarily tagged P-high-untriaged and will be 
re-triaged to determine which belong on the release milestone.

It's not clear where the P-low tag fits into the triage process yet, but 
conceivably we'll expand triage to include all bugs in the future, not 
just 'nominated' bugs, giving all bugs a P-tag.

OK, I hope that's clear, relatively simple, and not too objectionable to 

As to the actual criteria for what is in-scope and what is out-of-scope 
for the first major release of Rust, I'd like to hold off that 
discussion a little longer. Some time soon we'll have another thread to 
discuss release plans in more detail.


More information about the Rust-dev mailing list