Difference between revisions of "Contributing Patches"

From Apache OpenOffice Wiki
Jump to: navigation, search
(add patch tracking)
m
(14 intermediate revisions by 9 users not shown)
Line 1: Line 1:
−
== Joint Copyright Assignment ==
+
== License for code contributions ==
  
−
To submit any code to OOo you need to sign the [[Joint Copyright Assignment]].  This process can take some time, so check [[Pending JCAs]] to see if yours is pending legal review.
+
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 ==
  
−
Always use unified diffs <tt>cvs -z3 diff -u</tt>, since they are the most readable, (and sensible) types of
+
If you checkout the source with svn, produce your patch with
−
diff to read and apply.
+
svn diff
−
If you're not using them - most likely you want to setup your [[Tips#CVS_setup|cvsrc]] properly.
+
while if you clone with git, the standard
 +
git diff
 +
will do.
 +
If you can, please respect the line ending convention in use in the source files you are patching.
 +
 
 +
== Filing patches  ==
 +
 
 +
The best hacker centric bug filing interface is
 +
[https://issues.apache.org/ooo/ here].
 +
Whack the patch there &amp; wait for feedback.
  
 
== Some interaction ==
 
== Some interaction ==
Line 14: Line 23:
 
your fix, and/or discuss it with a developer or two before hand.
 
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
 
Some of the best ways to do this are to post to
−
[mailto:dev@openoffice.org] or lurk on IRC at <tt>irc.freenode.net</tt> on the
+
the [http://openoffice.apache.org/mailing-lists.html development mailing list] or lurk on IRC at <tt>irc.freenode.net</tt> on the
−
<tt>#OpenOffice.org</tt>, or <tt>#go-oo</tt> channels. IRC is an awfully poor
+
<tt>#dev.OpenOffice.org</tt> channel. IRC is an awfully poor
 
communication medium, but better than no communication.
 
communication medium, but better than no communication.
  
−
See [[DomainDeveloper]] to unwind who is whom.
+
See [[DomainDeveloper]] (outdated but still useful) to unwind who is whom.
−
 
+
−
== Filing patches for the main repository ==
+
−
 
+
−
The best hacker centric bug filing interface is
+
−
[http://qa.openoffice.org/issue_handling/submission_gateway.html#code_module here].
+
−
Whack the patch there &amp; 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
+
−
<code>ooo-build/bin/owner &lt;file-name&gt;</code> 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.
+
−
 
+
−
== 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==
 
==Speedy Handling of Patch Submissions==
Line 47: Line 33:
 
Developers are encouraged to submit their first code contributions
 
Developers are encouraged to submit their first code contributions
 
as patches - attachments to issues of type PATCH - to IssueZilla for
 
as patches - attachments to issues of type PATCH - to IssueZilla for
−
review and integration into the main repository. We have been criticized that submitted
+
review and integration into the main repository.
−
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)===
+
−
 
+
−
[http://eis.services.openoffice.org/patchreport/irt_index.html 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)===
+
  
−
[http://eis.services.openoffice.org/patchreport/iit_index.html Issue Inactivity Time] (IIT)
+
If you find that a patch has been kept unreviewed for too long,
−
describes the time since the last addition of a comment or status
+
please contact the [http://openoffice.apache.org/mailing-lists.html development mailing list]
−
change for open issues of type PATCH.
+
and ask that someone reviews it.
  
−
Let's avoid that patches linger around with unclear status for too long.
+
[[Category:Policy]]
−
The expectation of a contributor is that he will see his code reviewed and - if applicable - integrated in one of the next microreleases.
+
[[Category:Build_System]]
−
So we should drive the issue towards a resolution and closure.
+

Revision as of 21:14, 29 August 2014

License for code contributions

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

If you checkout the source with svn, produce your patch with 

svn diff

while if you clone with git, the standard 

git diff

will do. If you can, please respect the line ending convention in use in the source files you are patching.

Filing patches

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

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 the development mailing list 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 (outdated but still useful) to unwind who is whom.

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.

If you find that a patch has been kept unreviewed for too long, please contact the development mailing list and ask that someone reviews it.

Retrieved from "https://wiki.openoffice.org/w/index.php?title=Contributing_Patches&oldid=235537"
Personal tools