Advanced Rails - Building Industrial-Strength Web Apps in Record Time

(Tuis.) #1

292 | Chapter 9: Incorporating and Extending Rails



  1. Check the output ofsvn stas a sanity check for missing files, merge con-
    flicts, or other junk.
    5.svn diff > my_patch.diff to create a unified diff of the changes.

  2. Manually inspect the generated diff to verify that there are no extraneous
    changes and that all necessary changes are included.


File a ticket
Rails uses the Trac issue-tracking system, which is set up at http://dev.
rubyonrails.org/. You need an account to use the system, due to excessive spam
in the past. Once you have an account, click “New Ticket” to create a ticket.
If you have a patch for the issue you are reporting, use[PATCH]at the beginning
of the ticket summary, and remember to check the “I have files to attach to this
ticket” button.
There are a few points of basic ticket-creation etiquette. Leave the “Keywords”
field blank unless you know better. The “Assign to” and “Cc” fields should in
most cases be left blank as well; if other developers want to be added to the Cc
list, they will add themselves.
At this point, there may be a good deal of back-and-forth, or there may be no
activity. Be prepared to defend your decisions and your code, and you may be
sent back for rewrites or additions. Make sure to keep the patch current; if the
Rails trunk changes significantly in the meantime, you should rebase your patch
so that it still applies cleanly (with no fuzz). If a patch is well-tested, it can be
rebased and verified simply by repeating the preceding steps (updating, running
tests, and creating a new diff).


Get reviewed
Every month, the Rails Trac system sees thousands of actions (tickets opened,
closed, or commented on). In order to manage this flow, there is a barrier to
entry for contributors so that the core team doesn’t have to deal with patches
that are outdated, untested, or that break obvious functionality.
Generally, to get attention for a patch, you have to find three reviewers to assert
that the patch applies cleanly, passes the automated tests, and “works” for them.
They do this by making an appropriate comment (as simple as “+1 for me”) in
the ticket’s comments. Once you have three reviewers, it is up to you to add the
verified keyword to the ticket to indicate that review is complete.


Be available
At this point, your ticket will show up in the “verified” report (http://dev.
rubyonrails.org/report/12). Patches in this queue are usually acted upon quickly,
whether the action is acceptance, rejection, or sending it back for more discussion.

Free download pdf