Difference between revisions of "Contributing Patches"

From Apache OpenOffice Wiki
Jump to: navigation, search
Line 74: Line 74:
  
 
[[Category:Development]]
 
[[Category:Development]]
 +
[[Category:Build_System]]

Revision as of 03:03, 29 December 2008

Sun Contributor Agreement

To submit any code to OOo you need to sign the Sun Contributor Agreement (SCA) that replaces the former Joint Copyright Assignment (JCA). This process can take some time, so check Pending JCAs to see if yours is pending legal review.

Diff style

Always use unified diffs cvs -z3 diff -u , since they are the most readable, (and sensible) types of diff to read and apply. If you're not using them - most likely you want to setup your cvsrc properly.

Filing patches

The best hacker centric bug filing interface is here. Whack the patch there & wait for feedback.

Sometimes assigning the bug to the code owner helps accelerate the process. We can sometimes extract the owner of a module by checking for the ADMIN_FILE_OWNER tag; there is a little tool in ooo-build/bin/owner <file-name> that helps you find out who to E-mail / interact with about a given module; it's worth assigning very specifically located bugs to that person.

Some interaction

It tends to be a good idea to work out how best to implement your fix, and/or discuss it with a developer or two before hand. Some of the best ways to do this are to post to [1] or lurk on IRC at irc.freenode.net on the #dev.OpenOffice.org channel. IRC is an awfully poor communication medium, but better than no communication.

See DomainDeveloper to unwind who is whom.

ooo-build patch creation

Once you have created your patch you need to add it to the apply file so it can be applied by apply.pl during build time.

Then simply re-run 'make' in the toplevel - this should incrementally apply your patch to an (untouched) build tree.


Speedy Handling of Patch Submissions

Developers are encouraged to submit their first code contributions as patches - attachments to issues of type PATCH - to IssueZilla for review and integration into the main repository. We have been criticized that submitted PATCHes are not handled in a reasonable timeframe. To support the timely work on patches we introduced the two metrics as listed below.

The consequences of insufficient responsiveness are contributor dissatisfaction, bad reputation for the project and project leads and most significantly that the developer will probably not contribute again.

The number of 5 - 15 submissions per week and a backlog of about 170 open patches seems to be within our capabilities.

Initial Response Time (IRT)

Initial Response Time (IRT) describes the time between submission and first comment or status change from someone else than the submitter for open issues of type PATCH.

Please acknowledge the submission within one of the following days and assign the issue to the developer maintaining the code in question.

Issue Inactivity Time (IIT)

Issue Inactivity Time (IIT) describes the time since the last addition of a comment or status change for open issues of type PATCH.

Let's avoid that patches linger around with unclear status for too long. The expectation of a contributor is that he will see his code reviewed and - if applicable - integrated in one of the next microreleases. So we should drive the issue towards a resolution and closure.

Personal tools