From: William Victor Mote Date: Tue, 8 Apr 2003 19:00:21 +0000 (+0000) Subject: Correct patch submission instructions. X-Git-Tag: Root_Temp_KnuthStylePageBreaking~1639 X-Git-Url: https://source.dussan.org/?a=commitdiff_plain;h=8adf37de6728c941db8b83254fd953e3eb8b230a;p=xmlgraphics-fop.git Correct patch submission instructions. Reorganize some of the other content slightly. git-svn-id: https://svn.apache.org/repos/asf/xmlgraphics/fop/trunk@196237 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/src/documentation/content/xdocs/dev/index.xml b/src/documentation/content/xdocs/dev/index.xml index 6c3623f12..a7267accc 100644 --- a/src/documentation/content/xdocs/dev/index.xml +++ b/src/documentation/content/xdocs/dev/index.xml @@ -6,11 +6,15 @@ Information for FOP Developers -
+
Introduction -

These pages contain information that should be helpful for those developing FOP.

+

These pages contain information that should be helpful for those developing FOP. +This certainly includes programmers, but may also include those contributing to the project in other ways.

For basic and user information on FOP, please visit the FOP homepage.

-

It is important to understand that there are currently three lines of development on the FOP product:

+
+
+ Development Lines +

There are currently three lines of development on the FOP product:

  • The oldest is the one that releases are currently generated from, and is also called the "maintenance branch". Because of limitations in its design, the FOP committers decided to freeze new development on this branch, and are providing only bug fixes. This branch is tagged as "fop-0_20_2-maintain" in the CVS repository.
  • The main development line is the future of FOP. It was spawned from the "maintenance" branch, but had to quickly be "broken" so that the needed redesign could be dropped into place. It is currently not as mature as the "maintenance" branch, but has far greater long-term prospects. It is also known as the "root" or "trunk" or "redesign".
  • @@ -21,6 +25,7 @@
Getting Involved +

Review the Apache Project Roles and Responsibilities document for an understanding of the various roles of contributors within the community.

There are many different ways that you can help with FOP development. The development of FOP and the related plans and tasks are discussed on the dev mailing list. Users can help or get issues resolved by contributing information and examples to the developers. @@ -57,17 +62,16 @@ internally will be kept. fop-cvs-subscribe@xml.apache.org. If you want to contribute to the development of Fop you should subscribe, because it is important that you follow changes being made.

-
- Contributing code, tests and documentation -

If you want to contribute code (p.e. a bugfix), a test or documentation (p.e. an additional example), please do the following:

-

1) Make sure your code doesn't break the existing one and that Fop still compiles.

-

2) Create a file which shows the differences to the existing code.

-

3) Send this file as an Attachment to fop-dev@xml.apache.org. -

-

One of the committers will test your code and commit it to the code repository.

-

If you have a test or useful bug test you should read this page.

-

BTW: The Apache project knows different roles for contributors, namely 'users', 'developers', 'committers' and the 'Project - Management Committee' (An explanation of these roles can be found here).

+
+ Submitting Patches +

If you have useful changes to source code (bugfixes or enhancements), test files, or documentation that you would like to contribute to the project, please do the following:

+
    +
  • If your changes include source code, make sure that it does not break FOP (i.e. make sure that FOP still compiles with your changes).
  • +
  • If your changes include test files, review the Testing page.
  • +
  • Create a patch file for the differences to be applied to the existing code.
  • +
  • Create a new bugzilla issue for the patch. Include the text "[PATCH]" at the beginning of the description. Attach the patch file to the issue.
  • +
+

One of the committers will test your patch and consider its implications for the project. They will then either commit it to the repository or explain on the issue why they did not. Depending on the work load and skill-sets of the various committers, it may take some time before a a submitted patch is addressed.

Coding Conventions