Yeah, this is a key question. I'd game to try IRC and see how it goes. It's certainly the lowest common denominator. But I agree that voice can certainly be more efficient.
I’ve added a recurring event, every 3 weeks to the community calendar, starting on June 23. It’s set for 9 AM PST, which I think is 4 PM GMT. I sent invites to people I thought would be interested. If you need a reminder and want to be on the invite list just let me know and I’ll add you.
Right now it’s scheduled to take place solely on IRC, in #rust-triage. I’ll send out reminders before the first one.
Open meetings are a great idea, and I hope to see more progress like this going forward. I’m definitely going to attend.
Note to self: the meeting is at Noon Eastern Time. Must remember to be awake at noon.
This might be useful (since 9AM PST is not always 4 PM GMT):
http://arewemeetingyet.com/Los%20Angeles/2016-06-23/09:00/t/Rust%20release%20triage
Reminder that this is happening tomorrow at the time indicated in @djc’s link above. I’ve put together an etherpad with an agenda: https://public.etherpad-mozilla.org/p/rust-release-triage. Because the agenda is so massive we’re probably not going to get through the whole thing, and because the format is new, I expect surprises. But let’s try to rip through it quickly to see how it goes and not get too worried about the details for this first time.
Thanks for everybody who came and helped today. It went smoothly for a first try.
Here’s a summary of changes we made:
-
“called
Result::unwrap()
on anErr
value: Utf8Error { valid_up_to: 2 }” ICE in stable- nominatod for assignment
-
ICE: OutputTypeParameterMismatch in failing to resolve associated type as tuple
- nominated for assignment
-
RFC 401 should account for
Deref
coercions- removed P-high
-
Regression on nightly: doctest on recursion_limit crashes rustdoc
- P-high -> P-medium
-
Drop
and leaking&mut
references- no change
-
Pattern guard can consume value that is being matched
- no change
-
Code no longer builds because of RFC 1214
- nominated for P-medium
-
Desugared x.index(y) is not equivalent to x[y]
- reassigned to pnkfelix
-
Cyclic traits allow arbitrary traits to be synthesized
- asked for clarification
-
Cargo should understand distinctions between public/private dependencies
- asked if alex is working on it
-
Projections, lifetimes, and WF tracking issue (RFC 1214)
- nominated for review
-
Implied bounds on nested references + variance = soundness hole
- nominated for review
-
Don’t
git push
on the HTTP thread- remomved P-high
-
Incomprehensible error message when inference fails for closure
- P-high -> P-medium
-
Rust, Windows, and MSVC
- removed P-high
-
Custom test frameworks
- removed P-high
-
Build dependency awareness
- removed P-high
-
separate rust-format or rustfmt tool that does the pretty-printing
- closed
-
Use benchmarks to set up a website tracking rust performance
- closed
-
Move automation off mac minis, onto macstadium
- closed
-
Methods in impls allowed more restrictive lifetime bounds than in the trait.
- nominated for team triage
-
Resolve errors are likely quite obscure
- removed P-high
-
Linking regression in 1.6
- asked for clarification
-
Lifetime bound error when using the indexing operator with an associated type containing a lifetime
- nominated for team triage
-
ICE in stable 1.9 - ERROR:rbml::reader: failed to find block with tag 32 | [Avoided by removing type decl from closure scope?]
- nominated asked for backport
-
[regression] rustc panic on nightly (0667ae9 2016-05-17): Encountered errors `[FulfillmentError(Obligation(predicate=Binder(TraitPredicate)]
- nominated for team triage
I wasn’t active in the discussion, but was watching from the sidelines. Awesome. So glad we’re doing this.
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
P-high
-
https://github.com/rust-lang/rust/issues/28514
- P-medium
-
https://github.com/rust-lang/rust/issues/31287
- asked lang to retriage
-
https://github.com/rust-lang/rust/issues/18937
- asked niko for update
-
https://github.com/rust-lang/rust/issues/33364
- no change
-
https://github.com/rust-lang/rust/issues/19925
- no change
-
https://github.com/rust-lang/rust/issues/34535
- requested status update
-
https://github.com/rust-lang/rust/issues/29149
- pinged assignee
-
https://github.com/rust-lang/rust/issues/24263
- no change
P-medium
-
https://github.com/rust-lang/rust/issues/6834
- closed. wishlist
-
https://github.com/rust-lang/rust/issues/22932
- closed. 2.0 wishlist
-
https://github.com/rust-lang/rust/issues/19051
- closed in favor of https://github.com/rust-lang/rust/issues/31847
- nominated https://github.com/rust-lang/rust/issues/31847 for stabilization
-
https://github.com/rust-lang/rust/issues/24290
- tagged and nominated and pinged
-
https://github.com/rust-lang/rust/issues/24950
- P-low, unassigned
-
https://github.com/rust-lang/rust/issues/24210
- P-low, tagged
-
https://github.com/rust-lang/rust/issues/21878
- unassigned, tagged, nominated to close
-
https://github.com/rust-lang/rust/issues/24002
- close
-
https://github.com/rust-lang/rust/issues/10520
- close old wishlist
-
https://github.com/rust-lang/rust/issues/1563
- P-low, tagged
-
https://github.com/rust-lang/rust/issues/12466
- close
-
https://github.com/rust-lang/rust/issues/12609
- nominated for retriage
-
https://github.com/rust-lang/rust/issues/15702
- P-low
-
https://github.com/rust-lang/rust/issues/18469
- nominated for triage
-
https://github.com/rust-lang/rust/issues/28229
- P-low. tagged
-
https://github.com/rust-lang/rust/issues/23286
- help wanted, nominated
-
https://github.com/rust-lang/rust/issues/28784
- P-low, E-easy
-
https://github.com/rust-lang/rust/issues/28024
- pinged
-
https://github.com/rust-lang/rust/issues/27554
- nominated for retriage
-
https://github.com/rust-lang/rust/issues/5846
- nominated for retriage and a mentor
-
https://github.com/rust-lang/rust/issues/17344
- close
-
https://github.com/rust-lang/rust/issues/18154
- P-low, nominated for retriage, maybe add a lint
-
https://github.com/rust-lang/rust/issues/20489
- closed in favor of tracking issue, pinged tracking issue
- pinged for status update
-
https://github.com/rust-lang/rust/issues/23110
- closed old
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.
P-high
-
https://github.com/rust-lang/rust/issues/19925
- Set transmute from fn item to type fn lint a hard error
- looks good. PR ready
-
https://github.com/rust-lang/rust/issues/18937
- Methods in impls allowed more restrictive lifetime bounds than in the trait
- nobody working on it. P-medium
-
https://github.com/rust-lang/rust/issues/34754
- Regression: linking errors since latest nightly
- pinged for updates
-
https://github.com/rust-lang/rust/issues/29149
- Lifetime bounds in Copy impls are ignored
- reassigned to nmatsakis
-
https://github.com/rust-lang/rust/issues/24263
- discriminant_value intrinsic – tracking issue for 639
- removed E-help-wanted, P-medium
-
https://github.com/rust-lang/rust/issues/34831
- Apparent 1000% regression in llvm phase of bootstrap
- P-medium, A-infrastructure, A-build, not a regression
P-medium
-
https://github.com/rust-lang/rust/issues/19481
- Valgrind failure during unwinding in trans
- closed
-
https://github.com/rust-lang/rust/issues/28785
- Range expressions: discrepancies between rustc and parser-lalr
- E-mentor, I-wrong, I-needs-decision
-
https://github.com/rust-lang/rust/issues/29743
- Arithmetic makes borrow checker overly restrictive
- I-wrong, E-hard
-
https://github.com/rust-lang/rust/issues/28379
- Field access of block: discrepancy between parser-lalr and rustc
- A-grammar, I-wrong, I-needs-decision,
-
https://github.com/rust-lang/rust/issues/26951
- Abort on some large allocation requests, Panic on other
- E-hard, P-low, A-allocators, I-needs-decision
-
https://github.com/rust-lang/rust/issues/29723
- Variables moved from in match guards are still accessible in other match arms
- E-hard
-
https://github.com/rust-lang/rust/issues/27868
- Inconsistent evaluation order for assignment operations
- E-hard, A-lang, A-borrow-checker
-
https://github.com/rust-lang/rust/issues/29053
- Unsoundness in borrowck around deref and mutable refs
- I-unsound, A-codegen, E-needstest, E-easy
-
https://github.com/rust-lang/rust/issues/24971
- Forbid the -Z compiler flags from being used in beta and stable releases
- A-stability, close in favor of https://github.com/rust-lang/rust/issues/31847
-
https://github.com/rust-lang/rust/issues/28728
- LLVM loop optimization can make safe programs crash
- I-unsound, I-needs-decision, E-medium
-
https://github.com/rust-lang/rust/issues/30225
- Trait selection caching does not handle subtyping properly
- E-mentor
-
https://github.com/rust-lang/rust/issues/16948
- “Explicit lifetime bound required” message should give suggestions
- close
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.
Regressions
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.
Frequency
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
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.
+1
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
P-high
-
https://github.com/rust-lang/rust/issues/29149
- Lifetime bounds in Copy impls are ignored
- E-hard, I-wrong
-
https://github.com/rust-lang/rust/issues/18937
- Methods in impls allowed more restrictive lifetime bounds than in the trait.
- E-hard
-
https://github.com/rust-lang/rust/issues/19925
- Set transmute from fn item to type fn lint a hard error
- no change
-
https://github.com/rust-lang/rust/issues/35662
- LLVM pointer range loop / autovectorization regression
- I-slow
-
https://github.com/rust-lang/rust/issues/35408
- rustc built by MIR overflows its stack for crates with very deep ASTs
- No change
P-medium
-
https://github.com/rust-lang/rust/issues/23157
- glob imports ignore private items
- E-hard, I-wrong, T-compiler, possible PR in flight, pinged author
-
https://github.com/rust-lang/rust/issues/18510
- prevent unwinding past FFI boundaries in code generation
- P-low, I-unsound, T-compiler
-
https://github.com/rust-lang/rust/issues/20841
- Cannot infer closure type with higher-ranked lifetimes inside Box::new
- P-low, E-medium, I-enhancement
-
https://github.com/rust-lang/rust/issues/9883
- Prove the Rust type system sound
- Close
-
https://github.com/rust-lang/rust/issues/19733
- Mutable Pointer Aliasing Rules are Unclear for Unsafe Code
- Close in favor of https://github.com/rust-lang/rfcs/issues/1447
-
https://github.com/rust-lang/rust/issues/22877
- Comparison operators have higher precedence than range operator
..
- E-hard, I-needs-decision, P-low
- Comparison operators have higher precedence than range operator
-
https://github.com/rust-lang/rust/issues/23755
- std::io::Take should have into_inner() method
- E-easy, P-low
-
https://github.com/rust-lang/rust/issues/14875
- Failing destructors leak resources
- P-low, I-needs-decision, E-hard
-
https://github.com/rust-lang/rust/issues/30046
- Closure inference fails to infer that
move
is required when pattern matching - E-hard
- Closure inference fails to infer that
-
https://github.com/rust-lang/rust/issues/21903
- Trait bounds are not yet enforced in type definitions
- E-hard, I-needs-decision, important to fix
-
https://github.com/rust-lang/rust/issues/29008
- stdlib Path has inconsistent normalisation behaviour
- E-easy, A-libs, A-docs, P-low
-
https://github.com/rust-lang/rust/issues/21192
- Precedence of
box
is possibly wrong - T-lang, nmatsakis to update, probably not changing
- Precedence of
-
https://github.com/rust-lang/rust/issues/13231
- opt-in built-in bounds traits RFC tracker
- removed assignee, B-unstable, I-needs-decision, E-hard
-
https://github.com/rust-lang/rust/issues/26758
- The .msi installer freezes if you try to overwrite an existing Rust installation
- E-medium, T-tools, I-wrong, A-windows
-
https://github.com/rust-lang/rust/issues/17657
- Implement where clauses
- A-typesystem, T-compiler
Next triage is in 90 minutes, according to our new biweekly schedule.