OpenOffice.org

OpenOffice.org package guidelines

Minimize differences from upstream, ideally we should have no fedora-specific patches at all
All patches must either...
1. contain the upstream issuezilla id in the patch name and added to our upstream fedora applied-patches tracker id if not merged into upstream yet
2. or if the patch or related patchset has been accepted into upstream then name the patch as the workspace name
3. or if the changes is not upstreamable then contain the fedora bug id in the patch name instead
4. be aggressively pursued upstream to either get then accepted and merged, or clearly refused
When OpenOffice.org releases it's first master workspace along the release branch, i.e. OOX680mY, then it becomes acceptable to import into rawhide at this stage, but not during the development SRC680_mY stage.
Retain the upstream rpm version as the base fedora version, e.g. OOE680m6 was the cvs tag for the upstream 2.1.0-6 rpms, so the fedora rpms must be 2.1.0-6.X where X is the fedora rpm version
The Fedora OpenOffice.org structure should be split similarly to the upstream structure, e.g. -core, -base, -writer, the various langpacks, etc
The fedora OpenOffice.org tarball must only be imported by the package maintainer and it should be checked out with ooocvs
Messing with ARCH_FLAGS is a sure way to create a non-functional OpenOffice.org

Must build the langpack only if the locale is supported by glibc (locale -a)
Must build the langpack only if there is a font available in fedora to render that language
The langpack should Require: a font capable of rendering that language, i.e. Requires: font(:lang=XX)
The langpack should Require: a spell-check dictionary for the language if available, e.g. hunspell-en, hunspell-de. See OpenOffice.org/LinguisticComponents
The langpack should Require: a hyphenation dictionary for the language if available, e.g. hyphen-en, hyphen-de. See OpenOffice.org/LinguisticComponents
The langpack should Require: a thesaurus for the language if available, e.g. mythes-en, mythes-de. See OpenOffice.org/LinguisticComponents
The langpack should Require: a autocorrect package for the language if available, e.g. autocorr-en, autocorr-de.
The new langpack must be added by inserting an appropriate entry into langpackdetails in the .spec.
A langpack must only be included if there has been an explicit request by someone for it
Updated translations can be added, but must be submitted upstream and a request made to include them. (e.g. rhbz#483487 request to include upstream i98704 translations) so that we know when we can drop the integrated-upstream translations and don't get sucked into a time-sink translation update churn

Bugs should reference the upstream bug id through the external link option which lists OpenOffice.org's issuezilla as an option
Bugs should be responded to in a timely fashion to reassure that it has been read
Bugs should not be allowed to rot, if it can't be fixed, either move it upstream for consideration (see this fedora wish-list tracker, or close and explain why it's not going to be fixed
Stacktraces from the crash reporter should be mapped back through debuginfo to the original source lines with ooomapstack . Attach the mapped stack to the bug as text/plain
Bugs must be moved to the correct component, e.g.
1. Print Dialog issues, see if it affects evince as well, -> gtk2
2. File Dialog issues, see if it affects firefox or eclipse as well -> gtk2
3. Text Rendering issues, clarify if it is an icu issue, -> icu
4. Database issues, clarify if it is a hsqldb issue, -> hsqldb
5. el bizarro bug, clarify if it affects another large c++ program, e.g. firefox -> verify that compilation toolchain is ok
Verify that all installed files are non-corrupt, e.g. check for suspicious output in

/etc/cron.daily/prelink
rpm -Va

The KDE vclplug is not included, but I have made a src.rpm it is available if someone will volunteer to maintain it (I'll keep it built, but the maintainer must triage kde vcl-plug bugreports to determine what are generic problems, and which are solely kde vclplug only.)