Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
RT 4
(Request Tracker 4.0)
                 jesse@bestpractical.com
                 http://bestpractical.com
Hi, I'm Jesse Vincent

From Boston, MA in the US
Perl Hacker
Current Perl 5 “pumpking”
Android Hacker (K-9 Mail)
Kindle Ha...
Finding me

@obra
jesse@bestpractical.com
facebook.com/jesse.vincent
Hi I'm Jesse

Original Author of RT
Partner at Best Practical
RT project lead
(That just I don't get to
 code much anymore)
Best Practical

We make RT
We sell support
We sell training
We sell consulting
We sell custom development
Our offices

Boston, MA
Moscow, Russia
Hangzhou, China
Pinglin, Taiwan
(We're 11 people)
RT: Request Tracker


General purpose ticketing system
GNU GPLv2
Continuous
development
 since 1996
O(100) downloads
   every day
What is a ticketing system?
It keeps track of what
   needs to get done
It keeps track of what
       got done
...along with lots
   of metadata
...and business logic
...and access control
...It's just a TODO list
On some very serious drugs
not
Important properties of
      ticketing systems
●   Everything has a unique ID
●   Everything has a timestamp
●   History ...
What do you use a ticketing
       system for?
Network operations Accounts Payable
Bug tracking       Accounts
           ...
What we use RT for
Bug Tracking
Bronze/Silver/Gold support
Customer Development
Resumes
Inbound Sales Inquiries
Sales Leads
Accounts Payable
Accounts Receivable
Who uses RT?
Who else uses RT?
http://requesttracker.wikia.com/wiki/RTUsers
RT Scales
It scales down
(for testing or development)
Run RT on your laptop
SQLite
Standalone web server
It scales up
Largest RT I know about
40,000-70,000 tickets
...every day
(Nearly 1 ticket/second)
Multiple front-end app servers
Big database server
  with hot standby
Designed to be hookable
     and pluggable
Plugins
●


●   rt-action-linearescalate                   ●   rt-extension-log-memoryusage
●   rt-action-notifygroup             ...
(and a bunch more
created by RT users)
RT 4.0
Now available?
Not quite
Christmas 2010:

   4.0.0RC1
March 24, 2011:

  4.0.0 RC7
Release next week?
hcchien has been asking
 me to do a talk on RT4
  since at least 2006.
I've been promising “next year”
          for 5 years.
We started RT4 in
September 2007
I named it 3.999-DANGEROUS
In literature, they call
 that foreshadowing
I do public RT trainings
   a few times a year
I talk about RT's history
These are the slides I use
A Brief History of RT
RT 0.9 (1996)
●   Designed for use at a single
    company
●   2 sysadmins
●   30 users
RT 1.0 (1999)
●   Same as RT 0.9
    + a bit more courage
●   Used at hundeds of companies
●   Dozens of CSRs
●   Thouands...
RT 2.0 (2001)
●   Total rewrite
●   Just after Jesse escaped Microsoft
●   DBIx::SearchBuilder
●   Abstraction
●   Whole n...
RT 3.0 (2003)
●   Overhauled web interface
●   Extension mechanisms
●   Internationalization
●   Custom fields
●   Cleaner...
RT 3.2 (2004)
●   New search UI
●   Spreadsheet / RSS output
●   Outgoing mail preview and logging
●   UI improvements
●  ...
RT 3.4 (2005)
●   Reimplemented Custom Fields
●   Custom fields on users, groups
    transactions
●   Generalized Transact...
RT 3.6 (2006)
●   All-CSS layout and styling
●   Customizable homepage
●   Built in charts and reports
●   Ticket "reminde...
RT 3.8 (2008)
●   More user preferences
●   Timezones
●   Theme
●   Ticket history order
●   New configuration system
●   ...
RT 3.8 (continued)
●   “Favorite” tickets
●   Ticket relationship graphs
●   Branded queues
●   iCal feeds
●   PGP support
RT 4.0 (2008?)
Never trust a vendor who
 makes promises about
  unreleased products
That's really what it said!
It was sort of a joke
...little did I know
All Taiwanese know that
    4 is very unlucky
You're supposed
  to just skip 4
Nobody warned me
...until last night!
In my culture, 6 is
the unlucky number.
Along came 2006
We started thinking
about building RT 4.0
RT is big
http://www.flickr.com/photos/swiv/4426214075/
RT is big
http://www.flickr.com/photos/daymin/4715213393/
RT is complex
http://www.flickr.com/photos/18909153@N08/5241036226/
RT is complex
RT is old
http://www.flickr.com/photos/jpott/5326081706/
RT is old
http://www.flickr.com/photos/paulgissane/163290720
What would we change?
Modernize the API
Remove insane features
Use a framework!
Jifty
AJAX
Modern API
Lots of testing affordances
Plack
Automatic Database
Schema Management
UI Helpers
So, we started refactoring
Not a from-scratch rewrite
..but pretty close
No deadline
"It'll be ready when it's ready"
No fixed deliverable
"We want it to be good"
So, we went to work.
What went wrong?
We moved files around
Git made that sort of ok
We decided to modernize
    our coding style
We started renaming
classes and methods
RT's API was old
and InterCapped
The modern perl world
  is prettier_looking
We built refactoring tools
We ported the
full test suite
RT 3.6/3.7 were still in
 active development
We were fixing lots
  of bugs in 3.6
It was a constant battle
    to merge forward
3 years in, RT 3.999 was
     largely "done"
60% of the code of RT 3.8
Almost the same
feature set as RT 3.8.0
Almost the same
test suite as 3.8.0
Much cleaner
Ran on Jifty
Ran on Plack
New "Ticket Lifecycles" system
Much of the UI ported
to Template::Declare
It was a lot better
It killed off lots of bad
   old API decisions
...but mostly better for
    RT's developers
2627 commits
3 years of development
1484 files changed,
174558 insertions(+),
319761 deletions(-)
3.999 was different than 3.8 in
    some important ways
The API was recognizably the
           same
3.999 was better than 3.8 in
   some important ways
The API was 100%
  incompatible
There were lots and lots of
reasons to make the change
There are lots and lots of RT
   extensions out there.
We've done at least 75
There are more on CPAN
Just about every RT instance
has some local customizations
RT has been downloaded
about 100 times every day
For the past 5+ years
How many of you have ever
 customized or extended
     some software?
Guess what happens when
  you change an API?
Ever had an API change
break your customization?
RT has many users
They rely on many, many
     RT extensions
●


●   rt-action-linearescalate                   ●   rt-extension-log-memoryusage
●   rt-action-notifygroup             ...
We broke all of them
(all the extensions)
(all the users)
RT 3.999 had 40% less
  code than RT 3.8
RT 3.999 looked
 just like RT 3.8
RT 3.999 had almost the
 same features as 3.8
...with one really big change
RT 3.x has a system
  called “Scrips”
Scrips let you build
custom business logic
They're sort of like
“if...then...” statements
They can fire after any update
RT's approvals system
     uses Scrips
RT's email-sending rules
      use Scrips
They're really powerful
...but not omnipotent
Scrips are unchanged
     since RT 2.0
We decided to replace
 Scrips in RT 3.999
I wanted a simple
 macro language
clkao built the backend
“I'm not building a stupid macro
 language. If we're doing this, it
should support eval and apply”
We created lorzy
It was a lispy language
...with named, typed
      parameters
We ripped out Scrips and
    dropped in lorzy
Greenspun's Tenth Rule

Any sufficiently complicated C or
Fortran program contains an ad
hoc, informally-specified, bug-
r...
...at least we did it on purpose?
So, have I sold
RT 3.999 to you?
I don't like hurting users.
I don't like hurting customers.
Last summer, we threw away
      3 years of work.
[sad panda]
What'd we learn?
Second system syndrome
       hurts a lot
.oO{         My problem is that
          I actually have users
       I don't want to alienate }
A working test suite is
  not a magic bullet
Incremental updates
          vs
    gut renovation
Got a working system?
Make the smallest change
 that could possibly work
Build for your users
When we do client work, they
say that they want high-quality
 software last week for almost
             free.
"Good, fast and cheap,
    pick any two"
Turns out that you
 must pick two.
Last summer, we started
    RT4 over again
What'd we do different
      this time?
We were working
 for a customer
The customer wanted
      RT 3.8...
...with a lot of extensions.
They wanted to pay us to
integrate those extensions.
We had a deadline
We had a fixed set of
   deliverables
We had a mostly fixed set of
       deliverables
We got to work
The client wanted frequent
       beta releases
The new RT 3.9 needed to
be deployable at any time
Lots of topic branches
We started pulling in work we'd
already done as core features
RTFM became Articles
Stock answers
Really useful
Lots of folks don't install it
So, now you don't get a choice
Lifecycles
Originally built for 3.999 &
    backported to 3.8
Mobile Interface
Date custom fields
IP address custom fields
Full-text search for MySQL,
    Postgres and Oracle
Gmail-style folding
 of ticket history
Some new features,
we built from scratch
New auditing and
debugging tools
A brand new visual theme
A brand new theme editor
A new permissions editor UI
Dropdown and radio-button
      custom fields
Autocompleters for users
 and email addresses
Ported to Plack
Some stuff, you'd never notice
Overhauled how we
do boilerplate code
(Fewer files change.
 They change less)
Cut down our use of autoconf
Made the test suite much faster
Eliminated "noise"
from the test suite
Successfully delivered
    to customer
Since then, we've been
stabilizing, fixing bugs and
       improving docs
RC 1 came out just after
      christmas
RC 7 came out last week
We're very, very close.
Try out RT4

http://bestpractical.com/rt/download.html
http://bestpractical.com/rt/git.html
Release Candidate means we
think it's ready for production
If it breaks, email
rt-bugs@bestpractical.com
Thank you!

Questions?
RT4 - The whole sordid story
RT4 - The whole sordid story
RT4 - The whole sordid story
RT4 - The whole sordid story
RT4 - The whole sordid story
RT4 - The whole sordid story
RT4 - The whole sordid story
RT4 - The whole sordid story
RT4 - The whole sordid story
RT4 - The whole sordid story
RT4 - The whole sordid story
RT4 - The whole sordid story
RT4 - The whole sordid story
You’ve finished this document.
Download and read it offline.
Upcoming SlideShare
Dancing App Stores - Android Open 2011
Next
Upcoming SlideShare
Dancing App Stores - Android Open 2011
Next
Download to read offline and view in fullscreen.

4

Share

RT4 - The whole sordid story

Download to read offline

Building RT 4 took a lot more work than we'd expected. In the end, we learned some useful lessons and ended up with a great product.

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

RT4 - The whole sordid story

  1. 1. RT 4 (Request Tracker 4.0) jesse@bestpractical.com http://bestpractical.com
  2. 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. 3. Finding me @obra jesse@bestpractical.com facebook.com/jesse.vincent
  4. 4. Hi I'm Jesse Original Author of RT Partner at Best Practical RT project lead
  5. 5. (That just I don't get to code much anymore)
  6. 6. Best Practical We make RT We sell support We sell training We sell consulting We sell custom development
  7. 7. Our offices Boston, MA Moscow, Russia Hangzhou, China Pinglin, Taiwan
  8. 8. (We're 11 people)
  9. 9. RT: Request Tracker General purpose ticketing system
  10. 10. GNU GPLv2
  11. 11. Continuous development since 1996
  12. 12. O(100) downloads every day
  13. 13. What is a ticketing system?
  14. 14. It keeps track of what needs to get done
  15. 15. It keeps track of what got done
  16. 16. ...along with lots of metadata
  17. 17. ...and business logic
  18. 18. ...and access control
  19. 19. ...It's just a TODO list
  20. 20. On some very serious drugs
  21. 21. not
  22. 22. Important properties of ticketing systems ● Everything has a unique ID ● Everything has a timestamp ● History can't be edited or erased
  23. 23. 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
  24. 24. What we use RT for
  25. 25. Bug Tracking
  26. 26. Bronze/Silver/Gold support
  27. 27. Customer Development
  28. 28. Resumes
  29. 29. Inbound Sales Inquiries
  30. 30. Sales Leads
  31. 31. Accounts Payable
  32. 32. Accounts Receivable
  33. 33. Who uses RT?
  34. 34. Who else uses RT? http://requesttracker.wikia.com/wiki/RTUsers
  35. 35. RT Scales
  36. 36. It scales down
  37. 37. (for testing or development)
  38. 38. Run RT on your laptop
  39. 39. SQLite
  40. 40. Standalone web server
  41. 41. It scales up
  42. 42. Largest RT I know about
  43. 43. 40,000-70,000 tickets
  44. 44. ...every day
  45. 45. (Nearly 1 ticket/second)
  46. 46. Multiple front-end app servers
  47. 47. Big database server with hot standby
  48. 48. Designed to be hookable and pluggable
  49. 49. Plugins
  50. 50. ● ● 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
  51. 51. (and a bunch more created by RT users)
  52. 52. RT 4.0
  53. 53. Now available?
  54. 54. Not quite
  55. 55. Christmas 2010: 4.0.0RC1
  56. 56. March 24, 2011: 4.0.0 RC7
  57. 57. Release next week?
  58. 58. hcchien has been asking me to do a talk on RT4 since at least 2006.
  59. 59. I've been promising “next year” for 5 years.
  60. 60. We started RT4 in September 2007
  61. 61. I named it 3.999-DANGEROUS
  62. 62. In literature, they call that foreshadowing
  63. 63. I do public RT trainings a few times a year
  64. 64. I talk about RT's history
  65. 65. These are the slides I use
  66. 66. A Brief History of RT
  67. 67. RT 0.9 (1996) ● Designed for use at a single company ● 2 sysadmins ● 30 users
  68. 68. 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
  69. 69. RT 2.0 (2001) ● Total rewrite ● Just after Jesse escaped Microsoft ● DBIx::SearchBuilder ● Abstraction ● Whole new UI ● No more frames ● “Keywords”
  70. 70. RT 3.0 (2003) ● Overhauled web interface ● Extension mechanisms ● Internationalization ● Custom fields ● Cleaner internals ● Tests
  71. 71. RT 3.2 (2004) ● New search UI ● Spreadsheet / RSS output ● Outgoing mail preview and logging ● UI improvements ● No major structural changes ● More tests
  72. 72. RT 3.4 (2005) ● Reimplemented Custom Fields ● Custom fields on users, groups transactions ● Generalized Transaction system ● Faster, Faster, Faster ● Prettier ● Even more tests
  73. 73. RT 3.6 (2006) ● All-CSS layout and styling ● Customizable homepage ● Built in charts and reports ● Ticket "reminders" ● Comprehensive test coverage ● Cleaner code
  74. 74. RT 3.8 (2008) ● More user preferences ● Timezones ● Theme ● Ticket history order ● New configuration system ● Even more tests
  75. 75. RT 3.8 (continued) ● “Favorite” tickets ● Ticket relationship graphs ● Branded queues ● iCal feeds ● PGP support
  76. 76. RT 4.0 (2008?)
  77. 77. Never trust a vendor who makes promises about unreleased products
  78. 78. That's really what it said!
  79. 79. It was sort of a joke
  80. 80. ...little did I know
  81. 81. All Taiwanese know that 4 is very unlucky
  82. 82. You're supposed to just skip 4
  83. 83. Nobody warned me
  84. 84. ...until last night!
  85. 85. In my culture, 6 is the unlucky number.
  86. 86. Along came 2006
  87. 87. We started thinking about building RT 4.0
  88. 88. RT is big
  89. 89. http://www.flickr.com/photos/swiv/4426214075/
  90. 90. RT is big
  91. 91. http://www.flickr.com/photos/daymin/4715213393/
  92. 92. RT is complex
  93. 93. http://www.flickr.com/photos/18909153@N08/5241036226/
  94. 94. RT is complex
  95. 95. RT is old
  96. 96. http://www.flickr.com/photos/jpott/5326081706/
  97. 97. RT is old
  98. 98. http://www.flickr.com/photos/paulgissane/163290720
  99. 99. What would we change?
  100. 100. Modernize the API
  101. 101. Remove insane features
  102. 102. Use a framework!
  103. 103. Jifty
  104. 104. AJAX
  105. 105. Modern API
  106. 106. Lots of testing affordances
  107. 107. Plack
  108. 108. Automatic Database Schema Management
  109. 109. UI Helpers
  110. 110. So, we started refactoring
  111. 111. Not a from-scratch rewrite
  112. 112. ..but pretty close
  113. 113. No deadline
  114. 114. "It'll be ready when it's ready"
  115. 115. No fixed deliverable
  116. 116. "We want it to be good"
  117. 117. So, we went to work.
  118. 118. What went wrong?
  119. 119. We moved files around
  120. 120. Git made that sort of ok
  121. 121. We decided to modernize our coding style
  122. 122. We started renaming classes and methods
  123. 123. RT's API was old and InterCapped
  124. 124. The modern perl world is prettier_looking
  125. 125. We built refactoring tools
  126. 126. We ported the full test suite
  127. 127. RT 3.6/3.7 were still in active development
  128. 128. We were fixing lots of bugs in 3.6
  129. 129. It was a constant battle to merge forward
  130. 130. 3 years in, RT 3.999 was largely "done"
  131. 131. 60% of the code of RT 3.8
  132. 132. Almost the same feature set as RT 3.8.0
  133. 133. Almost the same test suite as 3.8.0
  134. 134. Much cleaner
  135. 135. Ran on Jifty
  136. 136. Ran on Plack
  137. 137. New "Ticket Lifecycles" system
  138. 138. Much of the UI ported to Template::Declare
  139. 139. It was a lot better
  140. 140. It killed off lots of bad old API decisions
  141. 141. ...but mostly better for RT's developers
  142. 142. 2627 commits
  143. 143. 3 years of development
  144. 144. 1484 files changed, 174558 insertions(+), 319761 deletions(-)
  145. 145. 3.999 was different than 3.8 in some important ways
  146. 146. The API was recognizably the same
  147. 147. 3.999 was better than 3.8 in some important ways
  148. 148. The API was 100% incompatible
  149. 149. There were lots and lots of reasons to make the change
  150. 150. There are lots and lots of RT extensions out there.
  151. 151. We've done at least 75
  152. 152. There are more on CPAN
  153. 153. Just about every RT instance has some local customizations
  154. 154. RT has been downloaded about 100 times every day
  155. 155. For the past 5+ years
  156. 156. How many of you have ever customized or extended some software?
  157. 157. Guess what happens when you change an API?
  158. 158. Ever had an API change break your customization?
  159. 159. RT has many users
  160. 160. They rely on many, many RT extensions
  161. 161. ● ● 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
  162. 162. We broke all of them
  163. 163. (all the extensions)
  164. 164. (all the users)
  165. 165. RT 3.999 had 40% less code than RT 3.8
  166. 166. RT 3.999 looked just like RT 3.8
  167. 167. RT 3.999 had almost the same features as 3.8
  168. 168. ...with one really big change
  169. 169. RT 3.x has a system called “Scrips”
  170. 170. Scrips let you build custom business logic
  171. 171. They're sort of like “if...then...” statements
  172. 172. They can fire after any update
  173. 173. RT's approvals system uses Scrips
  174. 174. RT's email-sending rules use Scrips
  175. 175. They're really powerful
  176. 176. ...but not omnipotent
  177. 177. Scrips are unchanged since RT 2.0
  178. 178. We decided to replace Scrips in RT 3.999
  179. 179. I wanted a simple macro language
  180. 180. clkao built the backend
  181. 181. “I'm not building a stupid macro language. If we're doing this, it should support eval and apply”
  182. 182. We created lorzy
  183. 183. It was a lispy language
  184. 184. ...with named, typed parameters
  185. 185. We ripped out Scrips and dropped in lorzy
  186. 186. 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.
  187. 187. ...at least we did it on purpose?
  188. 188. So, have I sold RT 3.999 to you?
  189. 189. I don't like hurting users.
  190. 190. I don't like hurting customers.
  191. 191. Last summer, we threw away 3 years of work.
  192. 192. [sad panda]
  193. 193. What'd we learn?
  194. 194. Second system syndrome hurts a lot
  195. 195. .oO{ My problem is that I actually have users I don't want to alienate }
  196. 196. A working test suite is not a magic bullet
  197. 197. Incremental updates vs gut renovation
  198. 198. Got a working system?
  199. 199. Make the smallest change that could possibly work
  200. 200. Build for your users
  201. 201. When we do client work, they say that they want high-quality software last week for almost free.
  202. 202. "Good, fast and cheap, pick any two"
  203. 203. Turns out that you must pick two.
  204. 204. Last summer, we started RT4 over again
  205. 205. What'd we do different this time?
  206. 206. We were working for a customer
  207. 207. The customer wanted RT 3.8...
  208. 208. ...with a lot of extensions.
  209. 209. They wanted to pay us to integrate those extensions.
  210. 210. We had a deadline
  211. 211. We had a fixed set of deliverables
  212. 212. We had a mostly fixed set of deliverables
  213. 213. We got to work
  214. 214. The client wanted frequent beta releases
  215. 215. The new RT 3.9 needed to be deployable at any time
  216. 216. Lots of topic branches
  217. 217. We started pulling in work we'd already done as core features
  218. 218. RTFM became Articles
  219. 219. Stock answers
  220. 220. Really useful
  221. 221. Lots of folks don't install it
  222. 222. So, now you don't get a choice
  223. 223. Lifecycles
  224. 224. Originally built for 3.999 & backported to 3.8
  225. 225. Mobile Interface
  226. 226. Date custom fields
  227. 227. IP address custom fields
  228. 228. Full-text search for MySQL, Postgres and Oracle
  229. 229. Gmail-style folding of ticket history
  230. 230. Some new features, we built from scratch
  231. 231. New auditing and debugging tools
  232. 232. A brand new visual theme
  233. 233. A brand new theme editor
  234. 234. A new permissions editor UI
  235. 235. Dropdown and radio-button custom fields
  236. 236. Autocompleters for users and email addresses
  237. 237. Ported to Plack
  238. 238. Some stuff, you'd never notice
  239. 239. Overhauled how we do boilerplate code
  240. 240. (Fewer files change. They change less)
  241. 241. Cut down our use of autoconf
  242. 242. Made the test suite much faster
  243. 243. Eliminated "noise" from the test suite
  244. 244. Successfully delivered to customer
  245. 245. Since then, we've been stabilizing, fixing bugs and improving docs
  246. 246. RC 1 came out just after christmas
  247. 247. RC 7 came out last week
  248. 248. We're very, very close.
  249. 249. Try out RT4 http://bestpractical.com/rt/download.html http://bestpractical.com/rt/git.html
  250. 250. Release Candidate means we think it's ready for production
  251. 251. If it breaks, email rt-bugs@bestpractical.com
  252. 252. Thank you! Questions?
  • MikaelaKarlsson3

    May. 25, 2017
  • sresearcher7

    Sep. 13, 2014
  • jehosaphat

    Jun. 14, 2013
  • AHinMaine

    Nov. 5, 2011

Building RT 4 took a lot more work than we'd expected. In the end, we learned some useful lessons and ended up with a great product.

Views

Total views

5,737

On Slideshare

0

From embeds

0

Number of embeds

8

Actions

Downloads

43

Shares

0

Comments

0

Likes

4

×