From: Nick Burch
We are actively seeking case studies for this page (after all it
just started). To submit a case study, either
-
+
submit a patch for this page or email it to the
mailing list
(with [PATCH] prefixed subject, please).
diff --git a/src/documentation/content/xdocs/getinvolved/book.xml b/src/documentation/content/xdocs/getinvolved/book.xml
deleted file mode 100644
index d139954975..0000000000
--- a/src/documentation/content/xdocs/getinvolved/book.xml
+++ /dev/null
@@ -1,38 +0,0 @@
-
-
-
-
-
- Branches are tagged in the following way:
-
- Merge points should be tagged as follows:
-
- Releases should be tagged as:
-
- Don't forget which branch you are currently on. This is critically
- important. Committing stuff to the wrong branch causes all sorts of
- headaches. Best to name your checkout after the branch you are on.
-
- All branching is currently managed by Glen Stampoultzis. If you wish
- to create your own branch please let him know. Merging is also
- handled by Glen. Just pop him a mail if you feel it's necessary to
- create a branch or perform a merge.
-
- The reason to go through a single point for branching is that it can be
- an easy thing to get wrong. Having a single person managing branches
- means there is less chance of getting getting our wires crossed with this
- difficult area of CVS.
-
- The following branches are currently active:
-
- Any information in here that might be perceived as legal information is
- informational only. We're not lawyers, so consult a legal professional
- if needed.
-
- The POI project is OpenSource
- and developed/distributed under the
- Apache Software License. Unlike other licenses this license allows
- free open source development; however, it does not require you to release
- your source or use any particular license for your source. If you wish
- to contribute to POI (which you're very welcome and encouraged to do so)
- then you must agree to release the rights of your source to us under this
- license.
-
- In early 2008, Microsoft made a fairly complete set of documentation
- on the binary file formats freely and publicly available. These were
- released under the Open
- Specification Promise, which does allow us to use them for
- building open source software under the
- Apache Software License.
-
- You can download the documentation on Excel, Word, PowerPoint and
- Escher (drawing) from
- http://www.microsoft.com/interop/docs/OfficeBinaryFormats.mspx.
- Documentation on a few of the supporting technologies used in these
- file formats can be downloaded from
- http://www.microsoft.com/interop/docs/supportingtechnologies.mspx.
-
- Previously, Microsoft published a book on the Excel 97 file format.
- It can still be of plenty of use, and is handy dead tree form. Pick up
- a copy of "Excel 97 Developer's Kit" from your favourite second hand
- book store.
-
- The newer Office Open XML (ooxml) file formats are documented as part
- of the ECMA / ISO standardisation effort for the formats. This
- documentation is quite large, but you can normally find the bit you
- need without too much effort! This can be downloaded from
- http://www.ecma-international.org/publications/standards/Ecma-376.htm,
- and is also under the OSP.
-
- It is also worth checking the documentation and code of the other
- open source implementations of the file formats.
-
- In short, stay away, stay far far away. Implementing these file formats
- in POI is done strictly by using public information. Public information
- includes sources from other open source projects, books that state the
- purpose intended is for allowing implementation of the file format and
- do not require any non-disclosure agreement and just hard work.
- We are intent on keeping it
- legal, by contributing patches you agree to do the same.
-
- If you've ever received information regarding the OLE 2 Compound Document
- Format under any type of exclusionary agreement from Microsoft, or
- (possibly illegally) received such information from a person bound by
- such an agreement, you cannot participate in this project. (Sorry)
-
- Those submitting patches that show insight into the file format may be
- asked to state explicitly that they have only ever read the publicly
- available file format information, and not any received under an NDA
- or similar.
- The Nutch project also have a very useful guide on becoming a
- new developer in their project. While it is written for their project,
- a large part of it will apply to POI too. You can read it at
- http://wiki.apache.org/nutch/Becoming_A_Nutch_Developer
- Create patches by getting the latest sources from Subversion.
- Alter or add files as appropriate. Then, from the poi directiory,
- type svn diff > mypatch.patch. This will capture all of your changes
- in a patch file of the appropriate format. However, svn diff won't
- capture any new files you may have added. So, if you've added any
- files, create an archive (tar.bz2 preferred as its the smallest) in a
- path-preserving archive format, relative to your poi directory.
- You'll attach both files in the next step.
-
- Patches are submitted via the Bug Database.
- Create a new bug, set the subject to [PATCH] followed by a brief description. Explain you patch and any special instructions and submit/save it.
- Next, go back to the bug, and create attachements for the patch files you
- created. Be sure to describe not only the files purpose, but its format.
- (Is that ZIP or a tgz or a bz2 or what?).
-
- Make sure your patches include the @author tag on any files you've altered
- or created. Make sure you've documented your changes and altered the
- examples/etc to reflect them. Any new additions should have unit tests.
- Lastly, ensure that you've provided approriate javadoc. (see
- Coding
- Standards). Patches that are of low quality may be rejected or
- the contributer may be asked to bring them up to spec.
- If you use a unix shell, you may find the following following
- sequence of commands useful for building the files to attach.
In short, stay away, stay far far away. Implementing these file formats
- in POI is done strictly by using public information. Public information
+ in POI is done strictly by using public information. Most of this Public
+ Information currently comes from the documentation that Microsoft
+ makes freely available (see above). The rest of the public information
includes sources from other open source projects, books that state the
purpose intended is for allowing implementation of the file format and
do not require any non-disclosure agreement and just hard work.
- We are intent on keeping it
- legal, by contributing patches you agree to do the same.
+ We are intent on keeping it legal, by contributing patches you agree to
+ do the same.
If you've ever received information regarding the OLE 2 Compound Document
Format under any type of exclusionary agreement from Microsoft, or
- (possibly illegally) received such information from a person bound by
- such an agreement, you cannot participate in this project. (Sorry)
+ received such information from a person bound by such an agreement, you
+ cannot participate in this project. Sorry. Well, unless you can persuade
+ Microsoft to release you from the terms of the NDA on the grounds that
+ most of the information is now publically available. However, if you have
+ been party to a Microsoft NDA, you will need to get clearance from Microsoft
+ before contributing.
Those submitting patches that show insight into the file format may be
asked to state explicitly that they have only ever read the publicly
available file format information, and not any received under an NDA
- or similar.
+ or similar, and have only made us of the public documentation.
The Nutch project also have a very useful guide on becoming a
new developer in their project. While it is written for their project,
a large part of it will apply to POI too. You can read it at
- http://wiki.apache.org/nutch/Becoming_A_Nutch_Developer
-
-
-
-
-
-
-
-
-
-
-
- Branch
-
-
- Description
-
-
-
-
- HEAD
-
-
- This is the trunk and is always active. Currently it is being used to continue development
- of the 2.0 release.
-
-
-
-
- REL_1_5_BRANCH
-
-
- All bug fixes not specifically relevant to the 2.0 work should be placed in this branch.
- From here they will merged back to the trunk and the merge point marked.
-
-
-
-
@@ -148,6 +155,19 @@ path-preserving archive format, relative to your poi directory. You'll attach both files in the next step.
++ Ideally, patches should be submitted early and often. This is for + two key reasons. Firstly, it's much easier to review smaller patches + than large ones. This means that smaller patches are much more likely + to be applied to SVN in a timely fashion. Secondly, by sending in your + patches earlier rather than later, it's much easier to get feedback + on your coding and direction. If you've missed an easier way to do something, + or are duplicating some (probably hidden) existing code, or taking things + in an unusual direction, it's best to get the feedback sooner rather than + later! As such, when submitting patches to POI, as with other Apache + Software Foundation projects, do please try to submit early and often, rather + than "throwing a large patch over the wall" at the end. +
Patches are submitted via the Bug Database. Create a new bug, set the subject to [PATCH] followed by a brief description. Explain you patch and any special instructions and submit/save it. @@ -179,8 +199,7 @@ svn diff > /tmp/poi-patch/diff.txt # Capture any new files, as svn diff won't include them # Preserve the path -svn status | grep "^\?" | \ - awk '{printf "cp --parents %s /tmp/poi-patch/new-files/\n", $2 }' | sh -s +svn status | grep "^\?" | awk '{printf "cp --parents %s /tmp/poi-patch/new-files/\n", $2 }' | sh -s # tar up the new files cd /tmp/poi-patch/new-files/ @@ -194,10 +213,43 @@ echo " /tmp/poi-patch/new-files.tar.bz2"
The POI project will generally offer committership to contributors who send + in consistently good patches over a period of several months.
+The requirement for "good patches" generally means patches which can be applied + to SVN with little or no changes. These patches should include unit test, and + appropriate documentation. Whilst your first patch to POI may require quite a + bit of work before it can be committed by an existing committer, with any luck + your later patches will be applied with no / minor tweaks. Please do take note + of any changes required by your earlier patches, to learn for later ones! If + in doubt, ask on the dev mailing list.
+The requirement for patches over several months is to ensure that committers + remain with the project. It's very easy for a good developer to fire off half + a dozen good patches in the couple of weeks that they're working on a POI + powered project. However, if that developer then moves away, and stops + contributing to POI after that spurt, then they're not a good candidate for + committership. As such, we generally require people to stay around for a while, + submitting patches and helping on the mailing list before considering them + for committership.
+Where possible, patches should be submitted early and often. For more details + on this, please see the "Submitting Patches" section above.
+ +Where possible, the existing developers will try to help and mentor new + contributors. However, everyone involved in POI is a volunteer, and it may + happen that your first few patches come in at a time when all the committers + are very busy. Do please have patience, and remember to use the + dev mailing list so that other + contributors can assist you!
+For more information on getting started at Apache, mentoring, and local + Apache Committers near you who can offer advice, please see the + Apache Community Development + Project website.
+