Difference between revisions of "Contributing Patches"

From Apache OpenOffice Wiki
Jump to: navigation, search
(→‎Contributor Agreement: We need a license not an ICLA)
m (→‎Some interaction)
 
(3 intermediate revisions by 2 users not shown)
Line 1: Line 1:
−
== Contributor Agreement ==
+
== 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.
+
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 ==
  
−
Always use extended git-style diffs
+
If you checkout the source with svn, produce your patch with
−
  hg diff -g
+
  svn diff
−
  hg export -g
+
while if you clone with git, the standard
−
since they are the most readable, (and sensible) types of diff to read and apply.
+
  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
−
[http://qa.openoffice.org/issue_handling/submission_gateway.html#code_module here].
+
[https://bz.apache.org/ooo/ here].
 
Whack the patch there & wait for feedback.
 
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
 
−
<code>ooo-build/bin/owner <file-name> </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.
 
  
 
== Some interaction ==
 
== Some interaction ==
Line 29: 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 [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>#dev.OpenOffice.org</tt> channel. IRC is an awfully poor
+
<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.
−
 
+
−
== 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==
  
 
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 Bugzilla 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)
+
−
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.
+
If you find that a patch has been kept unreviewed 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.
+
please contact the [https://openoffice.apache.org/mailing-lists.html development mailing list]
−
So we should drive the issue towards a resolution and closure.
+
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.

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