Integrate callgraph complexity measures into our regular process

Unless we track the size of the largest cycles in our code, big cycles may return

changed milestone to %Tor: unspecified

added calltool component::core tor/tor milestone::Tor: unspecified parent::16764 points::.2 priority::medium severity::normal sponsor::S-can status::new technical-debt tor-build type::defect labels

Trac:
Status: new to accepted

Trac:
Sponsor: N/A to SponsorS-can

Defer some of my own tickets to 0.2.???

Trac:
Keywords: N/A deleted, nickm-deferred-20160905 added
Milestone: Tor: 0.2.9.x-final to Tor: 0.2.???

Milestone renamed

Trac:
Milestone: Tor: 0.2.??? to Tor: 0.3.???

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

Trac:
Keywords: N/A deleted, tor-03-unspecified-201612 added
Milestone: Tor: 0.3.??? to Tor: unspecified

Remove an old triaging keyword.

Trac:
Keywords: tor-03-unspecified-201612 deleted, N/A added

Trac:
Keywords: nickm-deferred-20160905 deleted, N/A added

Trac:
Keywords: N/A deleted, tor-build technical-debt calltool added

We have this after a fashion now, inasmuch as we are using .may_include files to make more and more of our intermodule dependencies noncircular.

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

Change tickets that are assigned to nobody to "new".

Trac:
Status: assigned to new

changed time estimate to 1h 36m

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