Hi,
Mozilla research had a workweek recently where we discussed a number of
process changes to the Rust project to try to bring a little more order
to the chaos and wind down the rapid-growth, everything-on-fire phase of
the project. This email explains those process changes in a little more
detail.
If you're employed on this project full time, please read this email
carefully.
0. Bors, incoming and master
Bors has been generally judged a success (modulo annoyingly regular
timeouts on the buildbot) so we will be deleting the incoming branch and
switching bors to move master directly. I'll send another notice when
this is ready to happen.
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).
Bugs will be assigned to maturity milestones by a nomination process.
That's point #2. Maturity milestones will be reached "when we get
there"; we will not hold releases for them. What we call "1.0" is a
different conversation, but I imagine it needs to be somewhere after the
"backwards compatible" milestone, just to suit the concept of
major-version numbers in semantic versioning.
2. Nomination and acceptance
Maturity milestones represent a subjective judgment about product
maturity, as seen through the eyes of the repository owners (that is,
mozilla engineers). Of course you're welcome to consider maturity in
different terms, but this is for our own planning and measurement of the
project. As such we'll be accepting _nomination_ of a bug for inclusion
in one of these milestones liberally -- anyone should feel free to
nominate a bug if they think it's really important -- but meeting weekly
to either _accept_ or _decline_ inclusion in these milestones. This way
we hope to establish and communicate a consensus concerning the project
status and path towards completion. There is a new tag I-nominated for
tagging a bug with nomination. These will be cleared weekly, at the meeting.
Bugs that we decline to add to a maturity milestone will remain in the
general bug pool, and will be addressed "best effort" by the repository
owners, or (of course) through contributed pull requests. It's still
worth keeping non-milestone bugs around.
I should reiterate: the maturity milestones are there to _sharpen a
concept_ like "feature complete" or "backwards compatible" into a
particular bug-set. They are not there for scheduling a bug you "want to
get done because it seems cool". The idea is that a bug should be
assigned to a maturity milestone where it would be a _untenable_ to
claim or argue the terms of the milestone were met without that bug.
As such, the maturity milestones have extensive text associated with
them. Please read them to make sure you understand the idea behind each:
https://github.com/mozilla/rust/issues/milestones
3. Randomized triage and fixing in the general bug pool
I've added a new script to our repertoire of project automation that
selects a set least-recently-edited bugs every week and randomly assigns
them in batches for triage to a set of project participants (who have
signed up for this fate -- email me if you want to join in). This way we
hope to visit, self-nominate, review and close bugs at a better rate and
a more uniform breadth than we've been doing so far; and to improve this
rate as we advance towards feature completion and can focus more and
more energy on bug fixing.
If you received a set of bugs from this script this week, please take a
look at the bugs you were given and make time to look through them and
post at least one change to them so they don't come up again next week.
This could be as little as simply confirming that the bug still exists
and makes sense, though searching for duplicates, narrowing cases,
investigating causes and/or actually fixing bugs is also great if you
can spare the effort.
4. WIP on "1.0 bugs"
I'm presently mass-reassigning bugs that were formerly marked "1.0" to
the maturity milestones (and doing a small amount of filtering and
triage along the way). We will spend some time reviewing these in the
next few nomination meetings, as a sort of backlog of implicit
nominations, since "accepting" carries a bit more weight now than it did
when a lot of them were put on "1.0" (back when that seemed "infinitely
far away"). Hopefully it doesn't take _too_ many meetings to sort out;
but in case you were wondering, that's why the maturity milestones
currently already have (some) bugs assigned to them.
I should be finished with the initial mass-reassignment of those 1.0
bugs before the meeting this week. At that point I'll remove the 1.0
milestone. We should probably also have a look through the 0.7 milestone
to make sure it corresponds to the definition given above for numeric
milestones (only bugs assigned-to-users and expected-to-complete by next
release mark).
If you have any questions on any of this, please mention them here. I'm
happy to discuss further anything that's unclear, either here or on IRC
/ through direct email to me. We'd like the process to become more
transparent and better-organized, so everyone should feel like they
understand what's going on.
Thanks for your attention,
-Graydon
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
