Release cycle triage proposal


Reminder that this is happening again tomorrow. at 9 AM PST. See the calendar for the time in other timezones.


Thanks for coming today! It went really well. We’re down to only 7 P-high bugs and started plowing though P-medium. Uncovered lots of old issues to either close or nominate the teams to reconsider. A summary of actions taken follows.

Release triage minutes 2016-07-14




This is amazing. Nice work!


Reminder that this is happening again in 1 hour. Sorry for the late notice.


Here’s a summary of the actions taken in today’s meeting.




We’ve done this a few times now, so maybe a good time to review. I have thoughts on a few specific topics.

P-high - what’s it mean?

We are down to 3 P-high bugs!

This is awesome. We are ruthless at triage. It’s probably time to think again about what P-high means based on what we’ve learned, as well as how to make sure the right bugs are P-high.

My best guess is that P-high means ‘critical to fix right now’. As a corollary, that also means ‘somebody is assigned’. If we’re not willing to assign somebody thin it must not be critical.

P-high - how do we get more of them?

Is it really only 3 bugs that we think are important to fix right now? We’ve structured this to be great at demoting P-high bugs, but not uncovering new ones - most P-medium seem to stay P-medium. Should we incorporate triage of new bugs into this process? If so, it’s not clear when we’ll have the time, since there’s a steady stream of new bugs.


Similar to the last, we’re not doing anything in particular to uncover regressions and promote them to P-high. Just hoping that individuals are watching the incoming issues and tagging them right.


We still haven’t gotten through the backlog of P-medium bugs, and per the previous topics there’s still more useful triage we probably should be doing. Anybody interested in bumping the frequency from every 3 weeks to every 2 weeks?

cc @compiler_subteam, @lang_subteam, @sanxiyn @steveklabnik @alexcrichton @jntrnr reviewing the triage process

Release cycle milestones and P-high

I try to periodically triage new bugs, making sure that they all have tags. At some point, I had every bug tagged, but then some of them didn’t fit into any tags, and five became thirty, and then I got demoralized. I still try to do it every so often.

I never tried to assign levels to things, but if that’s something we want to do, I can try to do it.


A good approach would be to identify bugs you think are important, then nominate them to specific teams to weigh in on.


Hear, ye! Triage is happening again tomorrow. Same time, same place. See the OP for details.


As we discussed on IRC, I have sometimes considered four categories:

  • Fix it now.
  • Retriage regularly (say, every release).
  • Retriage periodically (as a background task).
  • Do not retriage unless requested to do so. Will get fixed when it gets fixed.

Currently, we don’t have the “retriage regularly category”, I don’t think. I would sort of like to use a milestone-per-release as the “fix it now” category; P-high for retriage regularly; P-medium for retriage periodically; and P-low for “do not retriage unless requested”.

The idea would be that after every release we focus on p-high bugs, than focus on p-medium bugs until the next release.

At some point we also discussed the idea of reviewing issues opened since the last triage meeting and so forth. But I think that would require more regular meetings.


Release cycle milestones and P-high

I agree with this direction, but want to point out that P-high are retriaged every three weeks, and we are cycling through P-medium as well, so they are retriaged regularly.

I will post a thread to irlo suggesting we create release milestones, and define them as ‘must fix right now’; and defining P-high as high-priority per team opinion; both retriaged every 2 weeks in this meeting.

Once complication with this use of release milestones is that the roadmap RFC may end up also using release milestones for estimated goal completion. This means it would have two purposes - critical bugs, and tracking non-critical but expected features. I’m not sure this distinction will matter much as long as we’re continually retriaging them.

I have bumped triage frequency to every 2 weeks.


Release triage minutes 2016-08-25



How the Rust issue tracker works

Next triage is in 90 minutes, according to our new biweekly schedule.


Because several people I want to attend are not available because RustConf, I’ve rescheduled for Tuesday 9/13, same time.


Next triage in 80 minutes.


Release triage minutes 2016-09-13

Stable regressions

Beta regressions

Nightly regressions



This is coming up again tomorrow, the last group triage before the 1.12 release.


Release triage minutes 2016-09-22

Stable regressions

Beta regressions

Nightly regressions


Old bugs


Release triage minutes 2016-10-06

Stable regressions

Beta regressions

Nightly regressions



Release triage minutes 2016-10-20

Stable regressions

Beta regressions

Nightly regressions