Little-t tor release process

Abstract: How can we make better software faster and get it into our users hands faster.

Minutes

Little-t-tor release plans

Want more frequent Tor point releases, and want more frequent stable release series

Earlier, we decided Nick would do releases too. But in practice he didn't.

Two things dissuading Nick from doing Tor releases:

• Get people to test it enough
• Revise the changes entries

(In 0.2.5.2-alpha, Roger basically rewrote all the changes entries to be user-facing and user-useful.)

Timing and triage of tickets

Need a process for what goes into each stable release

We have a huge pile of low priority bugs

Right now we use milestones for triage

Mike used to use "points" / "actual points", but it appears he's stopped

So the solution is, more people fixing bugs? Or what?

Need a category in between undecided and "the upcoming stable"

For the future

Cannot pick all three of:

• People working on it
• Amount of time
• feature set

If we do two stable releases a year (every six months on fixed schedule), we need to call some longterm and some not. And be clear about what we mean by longterm: buffer overflow fixes, not anonymity fixes.

It's a security app: many patches are security fixes

Did we just decide that Debian should always only include longterm releases (since they're the only ones we're willing to let go into a stable debian)?

We once had a deal with Ubuntu where they promised to move to the new Tor stable when we told them the old Tor stable is bad. But when Roger tried to invoke this promise, it failed.

How to call Tors stable more quickly? Conclusion: Nightlies for TBBs are a great missing way to test upcoming stables for normal users.