Difference between revisions of "Contributing Patches"

From Apache OpenOffice Wiki
Jump to: navigation, search
(Contributor Agreement)
(Contributor Agreement: We need a license not an ICLA)
Line 1: Line 1:
== Contributor Agreement ==
== Contributor Agreement ==
To submit any code to Apache OpenOffice.org, you need to sign the CLA(Contributor License Agreements). Check http://www.apache.org/licenses/#clas for detail.
All code contributions you make to OpenOffice must be under the Apache License, version 2.0. See http://www.apache.org/licenses/ for details.
== Diff style ==
== Diff style ==

Revision as of 20:57, 29 August 2014

Contributor Agreement

All code contributions you make to OpenOffice must be under the Apache License, version 2.0. See http://www.apache.org/licenses/ for details.

Diff style

Always use extended git-style diffs

hg diff -g
hg export -g

since they are the most readable, (and sensible) types of diff to read and apply.

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