Successfully reported this slideshow.
Your SlideShare is downloading. ×

SD - A peer to peer issue tracking system

Upcoming SlideShare
Standard measurements
Standard measurements
Loading in …3

Check these out next

1 of 223 Ad

More Related Content

More from Jesse Vincent (20)

Recently uploaded (20)


SD - A peer to peer issue tracking system

  1. P2P Bug Tracking with SD curl|perl; export PATH=~/sd/bin:$PATH; sd Jesse Vincent
  2. Hi!
  3. I’m Jesse (obra)
  4. I own a small software company
  5. (Best Practical)
  6. I’ve been making issue trackers since 1995
  7. Our software has some bugs
  8. All software has some bugs
  9. (All software is made of bugs)
  10. I spend a lot of time on airplanes...
  11. ...and at conferences with bad wifi
  12. I need to keep track of our bugs and our work
  13. I’m the boss
  14. I have no excuse for not doing my work
  15. I need to keep track of our bugs and our work even when I don’t have Internet access
  16. I’ve tried everything
  17. Text files
  18. Text files in version control
  19. IMAP Servers
  20. RSS Feeds
  21. Running RT on my laptop
  22. Keeping browsers open
  23. Nothing was quite right
  24. So we built SD
  25. SD is a Bug Tracker
  26. SD is a Distributed Bug Tracker
  27. SD Features Tracks bugs P2P Sync CLI Trac Sync Web UI RT Sync Scriptable Hiveminder Sync Works offline GitHub Sync Attachments Google Code Sync Comments Conflict Resolution Customizable workflow Git integration Custom properties Darcs integration
  28. Principles of distributed computing
  29. The network is reliable
  30. Latency is zero
  31. Bandwidth is infinite
  32. The network is secure
  33. Transport cost is zero
  34. The network is homogeneous
  35. Topology doesn't change
  36. There is one administrator
  37. Principles of distributed computing
  38. ie s la c Principles of distributed l F a computing
  39. Those are all LIES
  40. The network is not reliable
  41. SD isn’t network- dependent
  42. Latency hurts
  43. SD runs at the edge
  44. Bandwidth is always a problem
  45. SD knows which changesets you’ve already seen
  46. The network is insecure
  47. SD doesn’t depend on a network security layer
  48. Topology is unpredictable and fluid
  49. SD is topology-agnostic
  50. There is no administrator
  51. (But there are many people who think they’re administrators)
  52. SD lets you implement policy in the centralized systems it syncs to
  53. Transport costs money
  54. SD doesn’t use much bandwidth & can use non-network substrates
  55. The network is heterogeneous
  56. SD is designed to sync to foreign systems
  57. I didn’t make those up
  58. Bill Joy, Tom Lyon and James Gosling did
  59. They missed one
  60. Data is clean
  61. SD doesn’t expect to be able to enforce data integrity rules
  62. SD runs locally
  63. SD plays well with others
  64. It syncs the way you do
  65. Clone a project’s bug database (over HTTP)
  66. Work offline
  67. Pull changesets from anyone you work with
  68. Publish your database replica with rsync
  69. Topology doesn’t matter...
  70. Don’t worry
  71. It won’t break
  72. SD learns how to resolve each conflict...
  73. ...based on how everyone else resolves it
  74. Using SD (CLI)
  75. Getting Started
  76. SD Shell $ sd
  77. ./
  78. Getting help $ sd help
  79. Creating a new project $ sd init
  80. Project settings $ sd settings
  81. Config file $ sd config
  82. Create a bug $ sd ticket create
  83. Listing bugs $ sd ticket list
  84. Show a bug $ sd ticket show
  85. Update a bug $ sd ticket update
  86. Log $ sd log
  87. Git Integration $ git sd
  88. Using SD (Web)
  89. Web? Isn’t SD an offline tool?
  90. Local microserver
  91. $ sd browser
  92. Home
  93. Create a ticket
  94. Search
  95. Show a bug
  96. Update a bug
  98. History
  99. Working with others
  100. Working with others (Using SD)
  101. Any topology
  102. It doesn’t matter who you sync with
  103. You get all the updates eventually
  104. Cloning $ sd clone
  105. clone makes a replica of someone else’s database
  106. Pulling $ sd pull
  107. pull imports unseen changes from another database replica
  108. Publishing $ sd publish
  109. publish writes out a copy of your database replica for sharing
  110. (As SD changesets and static HTML)
  111. Hackathon mode (using Bonjour)
  112. Publish your replica $ sd server
  113. Pull updates $ sd pull --local
  114. Working with others (Using other systems)
  115. But you already have a bug tracker?
  116. No Problem!
  117. I use at least two others.
  118. I wrote at least two others.
  119. We designed SD talk to foreign bug trackers
  120. RT
  121. (RT::Client::REST)
  122. Hiveminder
  123. (Net::Jifty)
  124. Trac
  125. (Net::Trac)
  126. Google Code
  127. (Net::Google::Code)
  128. GitHub
  129. (Net::GitHub)
  130. Redmine (Read-only for now)
  131. (Net::Redmine)
  132. Want to help with Bugzilla, Jira, FogBugz or something else?
  133. Work with foreign replicas in a Star Topology
  134. X An SD node can act as a gateway
  135. Clone $ sd clone
  136. Clone from Google Code $ sd clone --from gcode:k9mail
  137. Clone from RT $ sd clone --from "rt:|DBI|"
  138. Clone from Trac $ sd clone --from trac:
  139. Clone from GitHub $ git sd clone --from github:miyagawa/remedie
  140. SD reverse engineers a database history
  141. Pull $ sd pull
  142. SD reverse engineers a partial database history
  143. Push $ sd push
  144. SD figures out local updates and sends them upstream
  145. (Then it does a bunch of book-keeping)
  146. So what’s that all look like in the real world?
  147. Google Code Alice’s SD Bob’s SD Create some bugs clone --from gcode:k9mail Alice’s SD makes a full copy of the k9mail from google code Someone updates ticket 12 ticket update 13 ticket create pull --from k9mail SD integrates upstream changes from Google Code since Alice ran the ‘clone’ command. push --to k9mail SD figures out what’s changed locally since the original ‘clone’ command. SD then sends any changes that Google Code hasn’t seen upstream as ticket updates. Alice’s new ticket and her updates to ticket 13 are now part of the upstream bug database in Google Code publish --to SD exports a full copy of Alice’s bug database and rsyncs it up to Anyone browsing can clone her SD replica. (Or see it in static HTML) clone --from Bob makes a full copy of Alice’s SD replica of the k9mail database. He’s now free to make changes to his local database replica. ticket update 45 ticket create ticket create ticket update 45 publish --to Bob publishes his full K9 bug database. Anyone browsing can clone Bob’s K9 replica. Anyone who already has a copy of Alice or Bob’s database can incorporate Bob’s new ticket and his changes to ticket 45. pull --from Alice’s SD pulls all previously unseen updates from Bob’s published database replica and incorporates them. If Bob's edits to ticket 45 didn't conflict, Alice's SD incorporate them. If they did conflict, Alice will be prompted to resolve the conflict. push --to k9mail Alice publishes all updates her bug database has seen since she last sent updates to Google Code. Google Code now has all of Alice and Bob’s changes.
  148. Installing SD
  149. It’s time to get SD up and running
  150. SD is in Perl
  151. SD uses 45-90 CPAN modules
  152. Are you afraid?
  153. Are you afraid?
  154. Don’t be
  155. I have a novel idea for a Perl application
  156. One-tweet install.
  157. I’m installing #SD ( after seeing @obra’s talk at #OSCON!
  158. 80 bytes! I still have 60 to work with!
  159. I’m installing #SD ( after seeing @obra’s talk at #OSCON! curl|perl; export PATH=~/sd/bin:$PATH; sd
  160. You’ll need: curl, perl 5.8, C compiler
  161. You won’t need: CPAN
  162. You won’t need: to answer prompts
  163. You won’t need: to fix dependencies
  164. SD is in Perl
  165. SD uses CPAN modules.
  166. This is a blessing.
  167. This is a curse.
  168. CPAN = Dependency Hell
  169. When we first built SD, we used anything we thought was useful.
  170. (The first version of SD used a SVN backend)
  171. The first ~useful version of SD:
  172. 123 Dependencies
  173. ...a couple hours later
  174. 54 Dependencies
  175. Only one needs a compiler.
  176. Shipwright gives us one-command install
  177. curl|perl export PATH=$PATH:~/sd/bin
  178. What’s that do?
  179. curl
  180. perl
  181. $ head /Library/WebServer/Documents/sd open (my $tar,'|tar xz 2>/dev/null'); while (<DATA>) { print $tar $_; } close $tar; exec("cd sd-build; bin/shipwright-builder --install-base=$ENV{HOME}/sd"); __DATA__ ?I?Isd-build.tar?<is?F???_1?䀌yH?"#‫{$ۿ‬U???H?eH ...
  182. Shipwright installs a few Perl modules...
  183. order
  184. Scalar-List-Utils WWW-Mechanize-GZip Sub-Exporter String-BufferStack File-Slurp Path-Dispatcher Class-Accessor Test-MockModule Module-Pluggable Class-Data-Inheritable Net-GitHub Time-Progress Tree-DAG_Node MIME-Types Carp-Assert Test-Simple Class-Singleton Proc-InvokeEditor Sub-Uplevel Params-Validate Test-HTTP-Server-Simple Test-Exception version Module-Refresh Array-Compare ExtUtils-CBuilder Carp-Assert-More Test-Warn ExtUtils-ParseXS Test-LongString Template-Declare Test-Harness Test-WWW-Mechanize URI File-Temp Test-Script-Run HTTP-Server-Simple Module-Build prophet.git Params-Util DateTime-TimeZone Devel-StackTrace Class-Inspector List-MoreUtils Exception-Class File-ShareDir DateTime-Locale Error DBI DateTime RT-Client-REST DBD-SQLite File-MMagic Email-Address HTML-Tagset Net-Google-Code YAML HTML-Parser Term-ReadLine-Perl Path-Class HTML-Tree Digest-SHA1 Clone Crypt-SSLeay Digest-HMAC Hash-Merge JSON Net-IP UNIVERSAL-isa YAML-Syck Net-DNS UNIVERSAL-can JSON-XS Net-Bonjour Test-MockObject JSON-DWIW TermReadKey Net-Jifty JSON-Any Data-UUID Lingua-EN-Inflect Mouse XML-Atom-SimpleFeed Text-CSV Any-Moose Digest-SHA Net-Trac Compress-Raw-Zlib Exporter-Lite boolean Compress-Raw-Bzip2 IPC-Run3 Time-Piece IO-Compress MIME-Base64-URLSafe Test-MockTime libwww-perl Data-UUID-Base64URLSafe DateTime-Format-Natural HTTP-Response-Encoding Sub-Install sd.git WWW-Mechanize Data-OptList
  185. (104 dists with our sync plugins)
  186. What’s wrong with SD?
  187. $ sd clone --from
  188. Don’t want to install SD?
  189. Point your browser at
  190. What’s next?
  191. Indexing
  192. GPG-signed changesets
  193. Actually releasing 1.0
  194. Thanks! Questions? curl | perl