incubator-odf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Burch <>
Subject Re: Review of changes
Date Fri, 02 Mar 2012 14:49:56 GMT
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 


View raw message