1. RT 4
(Request Tracker 4.0)
jesse@bestpractical.com
http://bestpractical.com

2. Hi, I'm Jesse Vincent
From Boston, MA in the US
Perl Hacker
Current Perl 5 “pumpking”
Android Hacker (K-9 Mail)
Kindle Hacker (Savory)
Former Perl 6 project manager

3. Finding me
@obra
jesse@bestpractical.com
facebook.com/jesse.vincent

4. Hi I'm Jesse
Original Author of RT
Partner at Best Practical
RT project lead

5. (That just I don't get to
code much anymore)

6. Best Practical
We make RT
We sell support
We sell training
We sell consulting
We sell custom development

7. Our offices
Boston, MA
Moscow, Russia
Hangzhou, China
Pinglin, Taiwan

8. (We're 11 people)

9. RT: Request Tracker
General purpose ticketing system

10. GNU GPLv2

11. Continuous
development
since 1996

12. O(100) downloads
every day

13. What is a ticketing system?

14. It keeps track of what
needs to get done

16. It keeps track of what
got done

18. ...along with lots
of metadata

20. ...and business logic

21. ...and access control

22. ...It's just a TODO list

23. On some very serious drugs

25. not

27. Important properties of
ticketing systems
● Everything has a unique ID
● Everything has a timestamp
● History can't be edited or erased

28. What do you use a ticketing
system for?
Network operations Accounts Payable
Bug tracking Accounts
Receivable
Call center
Vacation rentals
Helpdesk
Youth counselling
Customer service
Workflow
Work orders

29. What we use RT for

30. Bug Tracking

31. Bronze/Silver/Gold support

32. Customer Development

33. Resumes

34. Inbound Sales Inquiries

35. Sales Leads

36. Accounts Payable

37. Accounts Receivable

38. Who uses RT?

40. Who else uses RT?
http://requesttracker.wikia.com/wiki/RTUsers

41. RT Scales

42. It scales down

43. (for testing or development)

44. Run RT on your laptop

45. SQLite

46. Standalone web server

47. It scales up

48. Largest RT I know about

49. 40,000-70,000 tickets

50. ...every day

51. (Nearly 1 ticket/second)

52. Multiple front-end app servers

53. Big database server
with hot standby

54. Designed to be hookable
and pluggable

55. Plugins

56. ●
● rt-action-linearescalate ● rt-extension-log-memoryusage
● rt-action-notifygroup ● rt-extension-menubarsearches
● rt-ajaxyreplypage rt-extension-mergeusers
●
rt-authen-bitcard
●
● rt-extension-mergeusershistory
● rt-authen-openid2
● rt-extension-nagios
● rt-bugtracker
rt-bugtracker-public ● rt-extension-notificationmatrix
●
● rt-condition-complex ● rt-extension-priorityasstring
● rt-crypt-smime ● rt-extension-quickcalls
● rt-extension-activityreports ● rt-extension-quickdelete
● rt-extension-activityreports-billing ● rt-extension-quickupdate
● rt-extension-addadminccsonqueuechange rt-extension-reportspam
●
rt-extension-attributewalker
●
● rt-extension-rt_cpan_org
rt-extension-captcha
rt-extension-spawnlinkedticketinqueue
●
●
● rt-extension-cloneticket-withdata
rt-extension-utils
● rt-extension-commandbyemail ●
rt-extension-commandbymail ● rtfm
●
● rt-extension-commentoncreate ● rtfm-extension-articletemplate
● rt-extension-customfield-hideemptyvalues ● rtir
● rt-extension-datediscordian ● rtx-calendar
● rt-extension-extractcustomfieldvalues ● rtx-emailcompletion
● rt-extension-formtools rtx-ticketlist-transactions
●
rt-extension-jsgantt
●
● rtx-workflowbuilder
● rt-extension-ldapimport

57. (and a bunch more
created by RT users)

58. RT 4.0

59. Now available?

60. Not quite

61. Christmas 2010:
4.0.0RC1

62. March 24, 2011:
4.0.0 RC7

63. Release next week?

64. hcchien has been asking
me to do a talk on RT4
since at least 2006.

65. I've been promising “next year”
for 5 years.

66. We started RT4 in
September 2007

67. I named it 3.999-DANGEROUS

68. In literature, they call
that foreshadowing

69. I do public RT trainings
a few times a year

70. I talk about RT's history

71. These are the slides I use

72. A Brief History of RT

73. RT 0.9 (1996)
● Designed for use at a single
company
● 2 sysadmins
● 30 users

74. RT 1.0 (1999)
● Same as RT 0.9
+ a bit more courage
● Used at hundeds of companies
● Dozens of CSRs
● Thouands of requests per day
● Intense guilt

75. RT 2.0 (2001)
● Total rewrite
● Just after Jesse escaped Microsoft
● DBIx::SearchBuilder
● Abstraction
● Whole new UI
● No more frames
● “Keywords”

76. RT 3.0 (2003)
● Overhauled web interface
● Extension mechanisms
● Internationalization
● Custom fields
● Cleaner internals
● Tests

77. RT 3.2 (2004)
● New search UI
● Spreadsheet / RSS output
● Outgoing mail preview and logging
● UI improvements
● No major structural changes
● More tests

78. RT 3.4 (2005)
● Reimplemented Custom Fields
● Custom fields on users, groups
transactions
● Generalized Transaction system
● Faster, Faster, Faster
● Prettier
● Even more tests

79. RT 3.6 (2006)
● All-CSS layout and styling
● Customizable homepage
● Built in charts and reports
● Ticket "reminders"
● Comprehensive test coverage
● Cleaner code

80. RT 3.8 (2008)
● More user preferences
● Timezones
● Theme
● Ticket history order
● New configuration system
● Even more tests

81. RT 3.8 (continued)
● “Favorite” tickets
● Ticket relationship graphs
● Branded queues
● iCal feeds
● PGP support

82. RT 4.0 (2008?)

83. Never trust a vendor who
makes promises about
unreleased products

84. That's really what it said!

85. It was sort of a joke

86. ...little did I know

87. All Taiwanese know that
4 is very unlucky

88. You're supposed
to just skip 4

89. Nobody warned me

90. ...until last night!

91. In my culture, 6 is
the unlucky number.

93. Along came 2006

94. We started thinking
about building RT 4.0

95. RT is big

96. http://www.flickr.com/photos/swiv/4426214075/

97. RT is big

98. http://www.flickr.com/photos/daymin/4715213393/

99. RT is complex

100. http://www.flickr.com/photos/18909153@N08/5241036226/

101. RT is complex

103. RT is old

104. http://www.flickr.com/photos/jpott/5326081706/

105. RT is old

106. http://www.flickr.com/photos/paulgissane/163290720

107. What would we change?

108. Modernize the API

109. Remove insane features

110. Use a framework!

111. Jifty

112. AJAX

113. Modern API

114. Lots of testing affordances

115. Plack

116. Automatic Database
Schema Management

117. UI Helpers

118. So, we started refactoring

119. Not a from-scratch rewrite

120. ..but pretty close

121. No deadline

122. "It'll be ready when it's ready"

123. No fixed deliverable

124. "We want it to be good"

125. So, we went to work.

126. What went wrong?

127. We moved files around

128. Git made that sort of ok

129. We decided to modernize
our coding style

130. We started renaming
classes and methods

131. RT's API was old
and InterCapped

132. The modern perl world
is prettier_looking

133. We built refactoring tools

134. We ported the
full test suite

135. RT 3.6/3.7 were still in
active development

136. We were fixing lots
of bugs in 3.6

137. It was a constant battle
to merge forward

138. 3 years in, RT 3.999 was
largely "done"

139. 60% of the code of RT 3.8

140. Almost the same
feature set as RT 3.8.0

141. Almost the same
test suite as 3.8.0

142. Much cleaner

143. Ran on Jifty

144. Ran on Plack

145. New "Ticket Lifecycles" system

146. Much of the UI ported
to Template::Declare

147. It was a lot better

148. It killed off lots of bad
old API decisions

149. ...but mostly better for
RT's developers

150. 2627 commits

151. 3 years of development

152. 1484 files changed,
174558 insertions(+),
319761 deletions(-)

153. 3.999 was different than 3.8 in
some important ways

154. The API was recognizably the
same

155. 3.999 was better than 3.8 in
some important ways

156. The API was 100%
incompatible

157. There were lots and lots of
reasons to make the change

158. There are lots and lots of RT
extensions out there.

159. We've done at least 75

160. There are more on CPAN

161. Just about every RT instance
has some local customizations

162. RT has been downloaded
about 100 times every day

163. For the past 5+ years

164. How many of you have ever
customized or extended
some software?

165. Guess what happens when
you change an API?

166. Ever had an API change
break your customization?

167. RT has many users

168. They rely on many, many
RT extensions

169. ●
● rt-action-linearescalate ● rt-extension-log-memoryusage
● rt-action-notifygroup ● rt-extension-menubarsearches
● rt-ajaxyreplypage rt-extension-mergeusers
●
rt-authen-bitcard
●
● rt-extension-mergeusershistory
● rt-authen-openid2
● rt-extension-nagios
● rt-bugtracker
rt-bugtracker-public ● rt-extension-notificationmatrix
●
● rt-condition-complex ● rt-extension-priorityasstring
● rt-crypt-smime ● rt-extension-quickcalls
● rt-extension-activityreports ● rt-extension-quickdelete
● rt-extension-activityreports-billing ● rt-extension-quickupdate
● rt-extension-addadminccsonqueuechange rt-extension-reportspam
●
rt-extension-attributewalker
●
● rt-extension-rt_cpan_org
rt-extension-captcha
rt-extension-spawnlinkedticketinqueue
●
●
● rt-extension-cloneticket-withdata
rt-extension-utils
● rt-extension-commandbyemail ●
rt-extension-commandbymail ● rtfm
●
● rt-extension-commentoncreate ● rtfm-extension-articletemplate
● rt-extension-customfield-hideemptyvalues ● rtir
● rt-extension-datediscordian ● rtx-calendar
● rt-extension-extractcustomfieldvalues ● rtx-emailcompletion
● rt-extension-formtools rtx-ticketlist-transactions
●
rt-extension-jsgantt
●
● rtx-workflowbuilder
● rt-extension-ldapimport

170. We broke all of them

171. (all the extensions)

172. (all the users)

173. RT 3.999 had 40% less
code than RT 3.8

174. RT 3.999 looked
just like RT 3.8

175. RT 3.999 had almost the
same features as 3.8

176. ...with one really big change

177. RT 3.x has a system
called “Scrips”

178. Scrips let you build
custom business logic

179. They're sort of like
“if...then...” statements

180. They can fire after any update

181. RT's approvals system
uses Scrips

182. RT's email-sending rules
use Scrips

183. They're really powerful

184. ...but not omnipotent

185. Scrips are unchanged
since RT 2.0

186. We decided to replace
Scrips in RT 3.999

187. I wanted a simple
macro language

188. clkao built the backend

189. “I'm not building a stupid macro
language. If we're doing this, it
should support eval and apply”

190. We created lorzy

191. It was a lispy language

192. ...with named, typed
parameters

193. We ripped out Scrips and
dropped in lorzy

194. Greenspun's Tenth Rule
Any sufficiently complicated C or
Fortran program contains an ad
hoc, informally-specified, bug-
ridden, slow implementation of
half of Common Lisp.

195. ...at least we did it on purpose?

196. So, have I sold
RT 3.999 to you?

197. I don't like hurting users.

198. I don't like hurting customers.

199. Last summer, we threw away
3 years of work.

200. [sad panda]

201. What'd we learn?

202. Second system syndrome
hurts a lot

204. .oO{ My problem is that
I actually have users
I don't want to alienate }

205. A working test suite is
not a magic bullet

206. Incremental updates
vs
gut renovation

207. Got a working system?

208. Make the smallest change
that could possibly work

209. Build for your users

210. When we do client work, they
say that they want high-quality
software last week for almost
free.

211. "Good, fast and cheap,
pick any two"

212. Turns out that you
must pick two.

213. Last summer, we started
RT4 over again

214. What'd we do different
this time?

215. We were working
for a customer

216. The customer wanted
RT 3.8...

217. ...with a lot of extensions.

218. They wanted to pay us to
integrate those extensions.

219. We had a deadline

220. We had a fixed set of
deliverables

221. We had a mostly fixed set of
deliverables

222. We got to work

223. The client wanted frequent
beta releases

224. The new RT 3.9 needed to
be deployable at any time

225. Lots of topic branches

226. We started pulling in work we'd
already done as core features

227. RTFM became Articles

228. Stock answers

229. Really useful

230. Lots of folks don't install it

231. So, now you don't get a choice

232. Lifecycles

233. Originally built for 3.999 &
backported to 3.8

234. Mobile Interface

236. Date custom fields

237. IP address custom fields

238. Full-text search for MySQL,
Postgres and Oracle

239. Gmail-style folding
of ticket history

241. Some new features,
we built from scratch

242. New auditing and
debugging tools

243. A brand new visual theme

244. A brand new theme editor

246. A new permissions editor UI

248. Dropdown and radio-button
custom fields

249. Autocompleters for users
and email addresses

250. Ported to Plack

251. Some stuff, you'd never notice

252. Overhauled how we
do boilerplate code

253. (Fewer files change.
They change less)

254. Cut down our use of autoconf

255. Made the test suite much faster

256. Eliminated "noise"
from the test suite

257. Successfully delivered
to customer

258. Since then, we've been
stabilizing, fixing bugs and
improving docs

259. RC 1 came out just after
christmas

260. RC 7 came out last week

261. We're very, very close.

262. Try out RT4
http://bestpractical.com/rt/download.html
http://bestpractical.com/rt/git.html

263. Release Candidate means we
think it's ready for production

264. If it breaks, email
rt-bugs@bestpractical.com

265. Thank you!
Questions?