Development processes

[Leif Hedstrom <zw...@apache.org>]

Hi all,

with the community gaining a few new committers recently (woohoo!), and 
perhaps as a reminder to the old ones, here's a summary of our current 
development processes. Most, if not all,  of this should be available on the 
CWiki (see summary of links at the bottom).


    Commit

All trunk commits are Commit Then Review (CTR). All stable branch commits 
are Review Then Commit (RTC), and we review / vote on the branch changes via 
the STATUS file on the branch. The only currently active stable branch is 
3.0.x. It's important that everyone both adds, and reviews / votes on these 
proposals to move the stable branch(es) forward.

It is never frowned upon to ask for a review! Even though trunk is CTR, if 
the commit is particularly difficult, risky, or very large, you are 
encouraged to ask for reviews. If the change current behavior, or adds new 
behavior or features, it's even more important to make sure the discussion 
is done on dev@ first (either directly, or via the Jira ticket).

All non-trivial commits should have a Jira bug associated with it. Make sure 
to include TS-XYZ in the commit messages, and also make sure to add a line 
or two to the CHANGES file upon completing a bug. Jira bugs should have the 
correct fix version associated with it, before commit. This assures that the 
release notes we get from Jira are accurate.


    Coding styles

Our coding style is mostly K&R, with slight modifications. It is documented 
on the CWiki! We are definitely not married to this, so feel free to suggest 
changes. What I personally think is important that we all stick to the same 
coding and indentation style. There's nothing worse to me (other than <TAB> 
in source code)  than having to go between different coding style across 
files, or (shiver) within the same source file.

While working on a bug / fix, if you see significantly oddly formatted code, 
it's ok to clean that up! We still have a lot of cases where the code 
doesn't follow the current coding style. If you encounter this, I'd 
recommend doing the change as two commits: one to fix the code style or 
indentation, and the second for your particular fix. Yes, I'm as guilty as 
anyone else here, merging the two, but it helps for reviews etc. to separate 
"cleanup" from real changes.


    Releases

All stable releases are made from the respective release branch (e.g. 
3.0.x). All development releases are cut straight from trunk. All releases 
(stable or development) should get a tag in Subversion as well (e.g. 3.0.3 
or 3.1.2). Releases are always voted on, for a minimum of 72 hours, before 
getting pushed to the dist servers. Please make sure to test and vote as 
often as possible!

When a bug has received enough (minimum 3 +1's, and no -1's) votes on a 
release branch, make sure to add the appropriate fix version to the bug in 
Jira (you can have multiple fix versions, e.g. 3.1.2 and 3.0.2). Then merge 
and commit the patch onto the release branch, and remove the entry from the 
STATUS file. Having correct fix versions in Jira again helps creating 
accurate release notes (see above).

Stable releases are "even" (3.0.0, 3.0.1 etc.), while development releases 
are "odd" (3.1.0, 3.1.1 etc.). The next major stable release will be v3.2.0.

Cheers,

-- Leif


      Some links

https://cwiki.apache.org/confluence/display/TS/CommitPolicies
https://cwiki.apache.org/confluence/display/TS/ReleaseProcess
https://cwiki.apache.org/confluence/display/TS/Coding+Style