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:
https://mail.mozilla.org/pipermail/rust-dev/2013-April/003668.html
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
[nomination]:
https://github.com/mozilla/rust/wiki/Note-development-policy#milestone-and-priority-nomination-and-triage
[criteria]:
https://github.com/mozilla/rust/wiki/Note-priority-issue-criteria
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
anybody.
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.
Regards,
Brian
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
