Difference between revisions of "Contributing Patches"
B michaelsen (talk | contribs) |
|||
(8 intermediate revisions by 5 users not shown) | |||
Line 1: | Line 1: | ||
− | == | + | == License for code contributions == |
− | + | All code contributions you make to OpenOffice must be under the Apache License, version 2.0. See https://www.apache.org/licenses/ for details. | |
== Diff style == | == Diff style == | ||
− | + | If you checkout the source with svn, produce your patch with | |
− | diff | + | svn diff |
− | If you | + | 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 == | == Filing patches == | ||
The best hacker centric bug filing interface is | The best hacker centric bug filing interface is | ||
− | [ | + | [https://bz.apache.org/ooo/ here]. |
Whack the patch there & wait for feedback. | Whack the patch there & wait for feedback. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
== Some interaction == | == Some interaction == | ||
Line 28: | 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 | ||
− | [ | + | the [https://openoffice.apache.org/mailing-lists.html development mailing list] or lurk on IRC at <tt>irc://irc.libera.chat/Openoffice </tt> on the |
− | <tt># | + | <tt>#openoffice</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. |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
==Speedy Handling of Patch Submissions== | ==Speedy Handling of Patch Submissions== | ||
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 | + | as patches - attachments to issues of type PATCH - to Bugzilla for |
− | review and integration into the main repository | + | review and integration into the main repository. |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | + | If you find that a patch has been kept unreviewed for too long, | |
− | + | please contact the [https://openoffice.apache.org/mailing-lists.html development mailing list] | |
− | + | and ask that someone reviews it. | |
[[Category:Policy]] | [[Category:Policy]] | ||
[[Category:Build_System]] | [[Category:Build_System]] |
Latest revision as of 11:32, 11 August 2021
License for code contributions
All code contributions you make to OpenOffice must be under the Apache License, version 2.0. See https://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://irc.libera.chat/Openoffice on the #openoffice 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 Bugzilla 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.