On Fri, 2 Mar 2012, Rob Weir wrote:
Agree on a mandatory set of "desk checks" that committers must do
before checking in code. For example, one set of rules might me:
1) Do an svn update to ensure that you have the current trunk code
2) Do a complete build of all changed components, as well as any
components that depend on the changed components.
3) Complete build means: mvn clean install -Ppedantic
4) Build must complete with no errors
I'd say these are all very sensible, and should always be followed
Additionally, one rule we have for Tika (but not POI) is that all changes
must reference a JIRA issue, so there's always somewhere to track and
comment on things, as well as a record for changelogs etc.
For small changes, we generally open an issue, describe what'll happen
commit the change, and close it. Very occasionally, someone spots a
problem, comments, and we make further changes as needed.
For larger changes, we open an issue, and mention the proposed solution.
If appropriate, we upload a patch for review (especially important if
you're not sure you've the best way to solve it). If no-one objects, you
commit a day or two later. Otherwise, you work with others to come up with
the best solution, then commit that.
This seems to work quite well, and might be a good model to follow. (For
POI, we generally post to the dev list about planned big changes, and hold
discussions on them where needed on list. Bug fixes normally have a bug
anyway, so are tagged with that. POI has a different mix of committers and
committer overlap, so this slightly lighter weight approach works well
there)
Nick
