rt 4.2.14 (#13852)

[freeside.git] / rt / docs / hacking.pod

diff --git a/rt/docs/hacking.pod b/rt/docs/hacking.pod
index 8aa84fd..e254665 100644 (file)
--- a/rt/docs/hacking.pod
+++ b/rt/docs/hacking.pod
@@ -38,7 +38,9 @@ For example, a bugfix branched from C<4.0-trunk> might be named
 C<4.0/fail-taint-mode-early>.  A feature branched from C<master> when
 there exists a C<4.0-trunk> but no C<4.2-trunk> might be named
 C<4.2/rename-LogToScreen>.  For consistency, branches should use dashes,
 C<4.0/fail-taint-mode-early>.  A feature branched from C<master> when
 there exists a C<4.0-trunk> but no C<4.2-trunk> might be named
 C<4.2/rename-LogToScreen>.  For consistency, branches should use dashes,

-not underscores, to separate words.
+not underscores, to separate words.  Branches which are destined for
+4.2, but which are branched from 4.0 (to provide for easy extraction as
+a 4.0 extension) should be named 4.2-on-4.0/branch-name.

 
 Branches should be reviewed by another developer before being merged.
 Reviewers should make sure that the branch accomplishes what it claims
 
 Branches should be reviewed by another developer before being merged.
 Reviewers should make sure that the branch accomplishes what it claims


@@ -151,8 +153,14 @@ C<#loc_left_pair> is used for declaring that the I<key> of a
 particular C<< key => value >> pair is translatable. This is of
 very limited usefulness.
 
 particular C<< key => value >> pair is translatable. This is of
 very limited usefulness.
 

-C<#loc_right_pair> does NOT exist. C<#loc> works in such cases since
-its parser does not extend beyond the string at the end of a line.
+C<#loc_right_pair> does NOT exist. C<#loc> works in such cases since its
+parser does not extend beyond the string at the end of a line.  However,
+if the string is I<not> at the end of the line, C<#loc{word}> declares
+that the value associated with the key I<word> (earlier on the same
+line) is to be loc'd.  This is useful for inline hashes:
+
+    # Note the string "baz" is to be loc'd
+    foo => { bar => "baz", troz => "zort" },  # loc{bar}

 
 =head1 Development tips
 
 
 =head1 Development tips
 


@@ -170,7 +178,7 @@ can create and drop databases:
 You'll need to configure RT and make sure you have all the dependencies
 before running tests.  To do this in place without installing:
 
 You'll need to configure RT and make sure you have all the dependencies
 before running tests.  To do this in place without installing:
 

-    ./configure.ac --with-my-user-group --enable-layout=inplace --with-devel-mode
+    ./configure.ac --with-my-user-group --enable-layout=inplace --enable-developer

     make testdeps
     make fixdeps
 
     make testdeps
     make fixdeps
 


@@ -186,16 +194,21 @@ which will be significantly faster:
 
     make test-parallel
 
 
     make test-parallel
 

-The C<*-trunk> and C<master> branches are expected to be passing always
-be passing all tests.  While it is acceptable to break tests in an
-intermediate commit, a branch which does not pass tests will not be
-merged.  Ideally, commits which fix a bug should also include a testcase
-which fails before the fix and succeeds after.
+The C<*-trunk> and C<master> branches are expected to always be passing
+all tests.  While it is acceptable to break tests in an intermediate
+commit, a branch which does not pass tests will not be merged.  Ideally,
+commits which fix a bug should also include a testcase which fails
+before the fix and succeeds after.

 
 
 
 =head1 git quickstart
 
 
 
 
 =head1 git quickstart
 

+The process below describes how to get a copy of an RT repo,
+modify it, and submit your changes as a patch. You can also create
+an account on GitHub, fork RT, and submit a PR. GitHub has documentation
+on this process: L<https://help.github.com/articles/fork-a-repo/>.
+

 =over
 
 =item 1.
 =over
 
 =item 1.


@@ -291,7 +304,8 @@ This will print out the names of the files as it creates them.
 =item 9.
 
 Attach these files to an email using your standard email client, and
 =item 9.
 
 Attach these files to an email using your standard email client, and

-send it to C<rt-devel@bestpractical.com>.
+send it to C<rt-bugs@bestpractical.com>. This will create a ticket in
+our public RT instance at L<https://issues.bestpractical.com>.

 
 =back
 
 
 =back