On 04/22/2013 08:44 PM, Graydon Hoare wrote:
Hi,
1. Milestones split into two groups
Previous rust releases have used milestones ineffectively, as they
blurred the distinction between aspirations ("we think this bug
_should_ get done") and prediction ("we think this bug _will_ get
done"). As a result, they served neither purpose and were frequently
overlooked or ignored.
We will attempt to breathe new life into the "milestone" facility by
splitting their roles into separate sets: for 0.7 and onwards,
release-numbered milestones (0.7, 0.8, 0.9, etc.) will be _predictive
only_. Bugs should be placed on those milestones only if they are
assigned to you, and represent your best guess about _what you will
do_ during a release cycle. You can take something off that milestone
if it's assigned to you and you don't think you'll get it done,
whenever you see fit. These milestones will have associated target
dates, which we will aim to maintain on the quarterly cadence we've
maintained so far.
A separate set of milestones has been added called "maturity"
milestones. These have no dates, and are "aspirational": they define
subjective concepts "backwards compatible" or "feature complete" in
terms of specific bugs, for external measurement of the project's
state. The project's maturity can be judged against these more
usefully than it can be judged against milestones like "0.7" (which
tells the reader very little).
Is closing any or all maturity milestones a prerequisite for releasing 1.0?
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
