Perform a Severe Bug Retrospective for the last few years.

For every severe bug we fixed in 026 and 027 and 028, let's analyze roughly why it happened, and which programming practices could have prevented it. This will help us identify ways to do 0.2.9 better.

changed milestone to %Tor: 0.2.9.x-final

added TorCoreTeam-postponed-201604 TorCoreTeam201605 actualpoints::6 component::core tor/tor milestone::Tor: 0.2.9.x-final owner::nickm points::3 priority::high resolution::implemented severity::normal sponsor::U-can status::closed tor-dos-designs type::project labels

Trac:
Owner: N/A to nickm
Status: new to accepted

I've come up with my list of bugs in a spreadsheet, for bugs fixed in 0.2.5.1-alpha or later. I based this on reading the changelogs. There are 56 bugs I thought were worth including in the analysis here. I'm trying to decide whether to upload the spreadsheet, or tag the tickets on trac.

I have marked a bunch of tickets with the tag "2016-bug-retrospective."

Trac:
Keywords: N/A deleted, tor-dos-designs added

I've started an etherpad for commenting on every single darn ticket. I aim to do 10-15 tickets at a time, so I don't get burned out.

aaaaand, I've got an analysis for every darn ticket. Now to write a summary-of-findings document.

April is over; calling these april tickets postponed into may.

Trac:
Keywords: TorCoreTeam201604 deleted, TorCoreTeam-postponed-201604, TorCoreTeam201605 added

Trac:
Points: medium to 3

Summary-of-findings document written and circulated to other tor devs for sanity-checking. Will plan to publish once reviewed. (Not making this public yet in case I accidentally left some of the swearing in.)

Trac:
Actualpoints: N/A to 5
Status: accepted to needs_review

FINALLY done:

• https://blog.torproject.org/blog/mid-2016-tor-bug-retrospective-lessons-future-coding

Trac:
Actualpoints: 5 to 6
Resolution: N/A to implemented
Status: needs_review to closed

closed

changed time estimate to 24h

added 48h of time spent

moved to tpo/core/tor#18639 (closed)