Apache OpenOffice Wiki - User contributions [en]

Extensions releasing

2008-08-08T11:44:45Z

Jj:

= Release builds of Extensions (Draft) =

== High-level requirements ==
Extensions are a way to leverage the modularization of OpenOffice.org. The code of Extensions and the core OpenOffice.org needs to be separated to decouple the code and to allow less prerequisites for Extension building. Ideally, at least for Java extensions, all that is necessary to create and/or build an Extension is the OpenOffice.org SDK, a JDK and perhaps one or two small tools. This lowers the hurdles for new contributors to start developing for OpenOffice.org.

The release of OpenOffice.org Extensions is done independently from the OpenOffice.org Release Schedule.

Localization communities need to be able to identify whether strings belong to the OpenOffice.org core product or to an Extension to make the independent release schedule possible.

== Consequences ==

* To take advantage of the modularization introduced with Extensions, the core OpenOffice.org build should be possible without having to build extensions and of course vice versa.

* To keep the release schedule of the extensions independent from the OpenOffice.org release schedule there should be own 'targets' in IssueZilla and EIS.

* For the development and release of C++ Extensions, environments for Windows, MacOS X (Intel), Solaris x86 and Solaris Sparc, Linux x86-32 and Linux x86-64 should be available (other environments may be added).

* The development and release of OpenOffice.org extensions should be lightweight and should encourage developers to contribute since the chance of breaking the vanilla OpenOffice.org build with an extension is not likely. In most case there is also no big development team involved. So it should be possible for contributors to choose the development process of their own choice. The contributor of an extension is able to have full control about the release process (development, qa, release).

* To enable localization communities to identify whether strings belong to the OpenOffice.org core product or to an Extension, the code and translatable strings of Extensions should be placed in separate modules. String changes in these modules indicate translations for Extensions need to be done, strings changes in other modules indicate translation work for the core OpenOffice.org product.

* Automated QA must be possible for Extensions (at least this is a requirement of Sun provided extensions).

* The build system for Extensions should be the same as for the core OpenOffice.org.

== Recommendations ==

* It is recommended to develop extensions in Java or other platform independent supported language so that the resulting extensions are able to run on every supported platform.

* Extensions should be buildable by an automated build service to encourage contributions of Extensions into OpenOffice.org repository (also non SCA'd contribution hosted on [http://external.openoffice.org/source/browse/external/exemptedextensions/ Exempted Extensions repository]).

* For every new release of OpenOffice.org all existing extensions should get tested (recompile is not necessary, since API's are stable). A new extension will be build on the latest available OOo release even if a lower baseline can be used.

== ToDos ==
* SCM - all extensions should be hosted in the extensions project (or http://external.openoffice.org/source/browse/external/exemptedextensions/)
* Bugtracking
** Target Milestones for an independent release schedule
** Component extensions plus subcomponent
* Developing - branch/release model - choice of the developer?
* Code required for localization, e.g. the module transex3 and modules it depends on, needs to be moved to the SDK.

== Releasing ==

* [[Extensions/website/submission]]
* A list current extensions and their extensions is available at [[Extensions_Overview]]

[[Category:Extensions]]
[[Category:Quality Assurance]]

Extensions releasing

2008-08-08T11:42:22Z

Jj: reworked the page

= Release builds of Extensions (Draft) =

== High-level requirements ==
Extensions are a way to leverage the modularization of OpenOffice.org. The code of Extensions and the core OpenOffice.org needs to be separated to decouple the code and to allow less prerequisites for Extension building. Ideally, at least for Java extensions, all that is necessary to create and/or build an Extension is the OpenOffice.org SDK, a JDK, an IDE like Netbeans (a plain editor will also do, if preferred) and perhaps one or two small tools. This lowers the hurdles for new contributors to start developing for OpenOffice.org.

The release of OpenOffice.org Extensions is done independently from the OpenOffice.org Release Schedule.

Localization communities need to be able to identify whether strings belong to the OpenOffice.org core product or to an Extension to make the independent release schedule possible.

== Consequences ==

* To take advantage of the modularization introduced with Extensions, the core OpenOffice.org build should be possible without the inclusion of extensions and of course vice versa.

* To keep the release schedule of the extensions independent from the OpenOffice.org release schedule there should be an own 'target' in IssueZilla and EIS.

* For the development and release of C++ Extensions, environments for Windows, MacOS X (Intel), Solaris x86 and Solaris Sparc, Linux x86-32 and Linux x86-64 should be available (other environments may be added).

* The development and release of OpenOffice.org extensions should be lightweight and should encourage developers to contribute since the chance of breaking the vanilla OpenOffice.org build with an extension is not likely. In most case there is also no big development team involved. So it should be possible for contributors to choose the development process of their own choice. The contributor of an extension is able to have full control about the release process (development, qa, release).

* To enable localization communities to identify whether strings belong to the OpenOffice.org core product or to an Extension, the code and translatable strings of Extensions should be placed in separate modules. String changes in these modules indicate translations for Extensions need to be done, strings changes in other modules indicate translation work for the core OpenOffice.org product.

* Automated QA must be possible for Extensions (at least this is a requirement of Sun provided extensions).

* The build system for Extensions should be the same as for the core OpenOffice.org.

== Recommendations ==

* It is recommended to develop extensions in Java or other platform independent supported language so that the resulting extensions are able to run on every supported platform.

* Extensions should be buildable by an automated build service to encourage contributions of Extensions into OpenOffice.org repository (also non SCA'd contribution hosted on [http://external.openoffice.org/source/browse/external/exemptedextensions/ Exempted Extensions repository]).

* For every new release of OpenOffice.org all existing extensions should get tested (recompile is not necessary, since API's are stable). A new extension will be build on the latest available OOo release even if a lower baseline can be used.

== ToDos ==
* SCM - all extensions should be hosted in the extensions project (or http://external.openoffice.org/source/browse/external/exemptedextensions/)
* Bugtracking
** Target Milestones for an independent release schedule
** Component extensions plus subcomponent
* Developing - branch/release model - choice of the developer
* Code required for localization, e.g. the module transex3 and modules it depends on, needs to be moved to the SDK.

== Releasing ==

* [[Extensions/website/submission]]
* A list current extensions and their extensions is available at [[Extensions_Overview]]

[[Category:Extensions]]
[[Category:Quality Assurance]]

Java Coding Standards

2008-06-13T11:28:27Z

Jj:

=== Purpose ===
See the [[Cpp Coding Standards|C++ Coding Standards]] for the general purpose of Standards.

=== Rules for Java ===
==== Code Conventions ====
===== Java Code Conventions (Conv) =====
Follow Sun's Java Code Conventions [http://java.sun.com/docs/codeconv/CodeConventions.pdf] unless one of the rules below says otherwise. Keep local naming conventions.

==== Declarations: Scoping and Names ====
===== Naming Conventions (Names) =====
Descriptive variable, constant and method names must be used in accord with naming conventions.

===== Javadoc Headers (Javadoc) =====
Every class / non-private method needs to have a complete header in accordance with the javadoc style. When overriding a method of a superclass this header can be omitted if the content of the superclass description is still true for the implementation of the subclass. In these cases, if using Java5 or later, the @Override annotation must be used.

===== Comments (Comments) =====
Use enough comments in the code to make it understandable.

===== Access Modifiers (Access) =====
All attributes / methods must have appropriate access modifiers (private/protected/public). Make all class member data private.

===== Single Class (SingleClass) =====
Each file must only contain one class (except inner classes).

===== Explicit Imports (Import) =====
Don't import complete packages but name the classes to import explicitly.

==== Implementation Details ====
===== Static vs. Non-Static (Static) =====
Are there static attributes / methods that should be non-static or vice-versa?

===== Static Initializers =====
Avoid usage of classes other than from the Java class libraries in static initializers.

===== Variable Initialization (Init) =====
All variables need to be properly initialized.

===== Constants (Const) =====
Are there literal constants that should be named constants or are there variables that should be constants?

===== Keep Internals (Internal) =====
Better not expose member variables by giving out mutable class references as return values. Example: String (immutable) instead of StringBuffer (mutable).

===== Use a Single Return Value (ReturnVal) =====
Do not change parameter references in methods as a substitution for return values.

===== Parentheses (Paren) =====
Always use parentheses to avoid ambiguity.

===== Close I/O Resources (IO) =====
Opened files or connections need to be closed explicitly. Keep in mind that throwing exceptions can hinder closing resources. In those cases use finally to guarantee closing resources.

===== Assert Assumptions (Assert) =====
Assert liberally to document internal assumptions and invariants. Don't use assertions for runtime errors. Ensure that assertions don't perform side effects.
* [http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html Programming With Assertions/Sun Microsystems]
* [[Assertions in NetBeans]]

===== Exception Handling (Exception) =====
Use exception-handling to handle errors, this helps everyone to identify and locate errors. Try to use the standard exceptions of the Java API and avoid empty Catch-blocks.
* [http://today.java.net/pub/a/today/2003/12/04/exceptions.html Three Rules for Effective Exception Handling by Jim Cushing/Sun Microsystems]

===== Casting (Cast) =====
Avoid casting values to reduce ClassCastException or may be a data loss. Generics or methods as toString(), intValue() etc. offer a way to avoid casts.

* [http://java.sun.com/docs/books/jls/second_edition/html/conversions.doc.html Conversions and Promotions/Sun Microsystems]
* [http://java.sun.com/j2se/1.5.0/docs/guide/language/generics.html Generics/Sun Microsystems]

==== Control Flow ====
===== Switch Default (Switch) =====
Every switch statement must have a default case.

===== Switch Fall-through (FallThrough) =====
Every case of a switch statement should be ended by a break statement. If that is not the case and a fall-through is intended, then this must be marked by a comment.

===== No Switch on Types (NoSoT) =====
Don't use switch, when the cases represent types. Prefer polymorphism.

===== If to Switch (IfToSwitch) =====
Nested if-statements should to be converted to switch-statements.

==== Modularity ====
===== Duplicate Code (Dupli) =====
Avoid and remove duplicate code. Put common code into an extra function.
Duplicate code may be okay, if otherwise dependencies among so far unrelated modules would be created.

===== Use of Class Library Classes (Reuse) =====
Classes and methods from the Java class libraries should be used instead of creating an own implementation.

===== Make Functions Short (Short) =====
Make functions short. A comment line or large control structures are hints to extract functions, making the containing function more concise and readable.

==== Design ====
===== No Cyclic Dependencies (CyclDep) =====
Avoid cyclic dependencies.

===== No Premature Generalization (PremGen) =====
Do not generalize before the second occurrence and no later than the third.

===== One Responsibility (OneResp) =====
Give one class one cohesive responsibility.

===== How to Inherit (Inherit) =====
Inherit to be reused, not to reuse. Else prefer composition over inheritance.

===== Liskov Substitution Principle (LSP) =====
Everything one can do with a base class, or is offered by an interface, has to be doable with all derived/implementing classes. If a subclass is allowed to omit the implementation of a given method, then this should be listed in the documentation of the base classes' method.

==== Security ====
===== Validate Input (ValInput) =====
Validate all input coming from external

===== No Types Overflows (TypesOver) =====
Be aware that primitive types have limited range.

==== Interfaces ====
===== Consistency (Consi) =====
Give the same thing the same name everywhere in the interface.
Let parameters with the same semantic always occur in the same order in different functions.
All parameters used for output should be at the end of the parameter list. Additionally it needs to be stated in the method documentation if a parameter is an output parameter.

===== Minimality (Min) =====
Provide only one way to do anything. Move functions that do not belong to the core functionality of the interface to more appropriate locations.
For classes: Put convenience functions as non-member functions in the same namespace beside the class.

=== Links ===
See the [[Java Best Practices]] page for hints and best practices for Java programming.

The first draft of these guidelines was based on the [[Perl Coding Standards]] and the [http://www.fing.edu.uy/inco/cursos/ingsoft/iis/files/JavaChk.html Java Inspection Checklist].
----
[[Category:Coding Standards]]

Java Best Practices

2008-06-13T11:27:30Z

Jj:

This page is meant to collect best practices for Java programming generally and within the OpenOffice.org environment. It is an amendment to the [[Java Coding Standards]].

==== Collections ====

==== Threading ====

==== OpenOffice.org ====
===== Query Interface (Qifc) =====
UnoRuntime.queryInterface() is costly regarding performance. When it has to be used in loops, it should be done outside of the loop and the result reused inside.

===== License (Lic) =====
tbd

Java Coding Standards

2008-06-13T11:25:00Z

Jj: /* Rules for Java */

=== Purpose ===
See the [[Cpp Coding Standards|C++ Coding Standards]] for the general purpose of Standards.

=== Rules for Java ===
==== Code Conventions ====
===== Java Code Conventions (Conv) =====
Follow Sun's Java Code Conventions [http://java.sun.com/docs/codeconv/CodeConventions.pdf] unless one of the rules below says otherwise. Keep local naming conventions.

==== Declarations: Scoping and Names ====
===== Naming Conventions (Names) =====
Descriptive variable, constant and method names must be used in accord with naming conventions.

===== Javadoc Headers (Javadoc) =====
Every class / non-private method needs to have a complete header in accordance with the javadoc style. When overriding a method of a superclass this header can be omitted if the content of the superclass description is still true for the implementation of the subclass. In these cases, if using Java5 or later, the @Override annotation must be used.

===== Comments (Comments) =====
Use enough comments in the code to make it understandable.

===== Access Modifiers (Access) =====
All attributes / methods must have appropriate access modifiers (private/protected/public). Make all class member data private.

===== Single Class (SingleClass) =====
Each file must only contain one class (except inner classes).

===== Explicit Imports (Import) =====
Don't import complete packages but name the classes to import explicitly.

==== Implementation Details ====
===== Static vs. Non-Static (Static) =====
Are there static attributes / methods that should be non-static or vice-versa?

===== Static Initializers =====
Avoid usage of classes other than from the Java class libraries in static initializers.

===== Variable Initialization (Init) =====
All variables need to be properly initialized.

===== Constants (Const) =====
Are there literal constants that should be named constants or are there variables that should be constants?

===== Keep Internals (Internal) =====
Better not expose member variables by giving out mutable class references as return values. Example: String (immutable) instead of StringBuffer (mutable).

===== Use a Single Return Value (ReturnVal) =====
Do not change parameter references in methods as a substitution for return values.

===== Parentheses (Paren) =====
Always use parentheses to avoid ambiguity.

===== Close I/O Resources (IO) =====
Opened files or connections need to be closed explicitly. Keep in mind that throwing exceptions can hinder closing resources. In those cases use finally to guarantee closing resources.

===== Assert Assumptions (Assert) =====
Assert liberally to document internal assumptions and invariants. Don't use assertions for runtime errors. Ensure that assertions don't perform side effects.
* [http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html Programming With Assertions/Sun Microsystems]
* [[Assertions in NetBeans]]

===== Exception Handling (Exception) =====
Use exception-handling to handle errors, this helps everyone to identify and locate errors. Try to use the standard exceptions of the Java API and avoid empty Catch-blocks.
* [http://today.java.net/pub/a/today/2003/12/04/exceptions.html Three Rules for Effective Exception Handling by Jim Cushing/Sun Microsystems]

===== Casting (Cast) =====
Avoid casting values to reduce ClassCastException or may be a data loss. Generics or methods as toString(), intValue() etc. offer a way to avoid casts.

* [http://java.sun.com/docs/books/jls/second_edition/html/conversions.doc.html Conversions and Promotions/Sun Microsystems]
* [http://java.sun.com/j2se/1.5.0/docs/guide/language/generics.html Generics/Sun Microsystems]

==== Control Flow ====
===== Switch Default (Switch) =====
Every switch statement must have a default case.

===== Switch Fall-through (FallThrough) =====
Every case of a switch statement should be ended by a break statement. If that is not the case and a fall-through is intended, then this must be marked by a comment.

===== No Switch on Types (NoSoT) =====
Don't use switch, when the cases represent types. Prefer polymorphism.

===== If to Switch (IfToSwitch) =====
Nested if-statements should to be converted to switch-statements.

==== Modularity ====
===== Duplicate Code (Dupli) =====
Avoid and remove duplicate code. Put common code into an extra function.
Duplicate code may be okay, if otherwise dependencies among so far unrelated modules would be created.

===== Use of Class Library Classes (Reuse) =====
Classes and methods from the Java class libraries should be used instead of creating an own implementation.

===== Make Functions Short (Short) =====
Make functions short. A comment line or large control structures are hints to extract functions, making the containing function more concise and readable.

==== Design ====
===== No Cyclic Dependencies (CyclDep) =====
Avoid cyclic dependencies.

===== No Premature Generalization (PremGen) =====
Do not generalize before the second occurrence and no later than the third.

===== One Responsibility (OneResp) =====
Give one class one cohesive responsibility.

===== How to Inherit (Inherit) =====
Inherit to be reused, not to reuse. Else prefer composition over inheritance.

===== Liskov Substitution Principle (LSP) =====
Everything one can do with a base class, or is offered by an interface, has to be doable with all derived/implementing classes. If a subclass is allowed to omit the implementation of a given method, then this should be listed in the documentation of the base classes' method.

==== Security ====
===== Validate Input (ValInput) =====
Validate all input coming from external

===== No Types Overflows (TypesOver) =====
Be aware that primitive types have limited range.

==== Interfaces ====
===== Consistency (Consi) =====
Give the same thing the same name everywhere in the interface.
Let parameters with the same semantic always occur in the same order in different functions.
All parameters used for output should be at the end of the parameter list. Additionally it needs to be stated in the method documentation if a parameter is an output parameter.

===== Minimality (Min) =====
Provide only one way to do anything. Move functions that do not belong to the core functionality of the interface to more appropriate locations.
For classes: Put convenience functions as non-member functions in the same namespace beside the class.

The first draft of these guidelines was based on the [[Perl Coding Standards]] and the [http://www.fing.edu.uy/inco/cursos/ingsoft/iis/files/JavaChk.html Java Inspection Checklist].
----
[[Category:Coding Standards]]

Java Best Practices

2008-06-13T11:24:37Z

Jj: New page: This page is meant to collect best practices for Java programming generally and within the OpenOffice.org environment. It is an amendment to the [Java Coding Standards]. ==== Collections...

This page is meant to collect best practices for Java programming generally and within the OpenOffice.org environment. It is an amendment to the [Java Coding Standards].

==== Collections ====

==== Threading ====

==== OpenOffice.org ====
===== Query Interface (Qifc) =====
UnoRuntime.queryInterface() is costly regarding performance. When it has to be used in loops, it should be done outside of the loop and the result reused inside.

===== License (Lic) =====
tbd

Java Coding Standards

2008-06-13T10:35:05Z

Jj: /* Rules for Java */

=== Purpose ===
See the [[Cpp Coding Standards|C++ Coding Standards]] for the general purpose of Standards.

=== Rules for Java ===
==== Code Conventions ====
===== Java Code Conventions (Conv) =====
Follow Sun's Java Code Conventions [http://java.sun.com/docs/codeconv/CodeConventions.pdf] unless one of the rules below says otherwise. Keep local naming conventions.

==== Declarations: Scoping and Names ====
===== Naming Conventions (Names) =====
Descriptive variable, constant and method names must be used in accord with naming conventions.

===== Javadoc Headers (Javadoc) =====
Every class / non-private method needs to have a complete header in accordance with the javadoc style. When overriding a method of a superclass this header can be omitted if the content of the superclass description is still true for the implementation of the subclass. In these cases, if using Java5 or later, the @Override annotation must be used.

===== Comments (Comments) =====
Use enough comments in the code to make it understandable.

===== Access Modifiers (Access) =====
All attributes / methods must have appropriate access modifiers (private/protected/public). Make all class member data private.

===== Single Class (SingleClass) =====
Each file must only contain one class (except inner classes).

===== Explicit Imports (Import) =====
Don't import complete packages but name the classes to import explicitly.

==== Implementation Details ====
===== Static vs. Non-Static (Static) =====
Are there static attributes / methods that should be non-static or vice-versa?

===== Static Initializers =====
Avoid usage of classes other than from the Java class libraries in static initializers.

===== Variable Initialization (Init) =====
All variables need to be properly initialized.

===== Constants (Const) =====
Are there literal constants that should be named constants or are there variables that should be constants?

===== Keep Internals (Internal) =====
Better not expose member variables by giving out mutable class references as return values. Example: String (immutable) instead of StringBuffer (mutable).

===== Use a Single Return Value (ReturnVal) =====
Do not change parameter references in methods as a substitution for return values.

===== Parentheses (Paren) =====
Always use parentheses to avoid ambiguity.

===== Close I/O Resources (IO) =====
Opened files or connections need to be closed explicitly. Keep in mind that throwing exceptions can hinder closing resources. In those cases use finally to guarantee closing resources.

===== Assert Assumptions (Assert) =====
Assert liberally to document internal assumptions and invariants. Don't use assertions for runtime errors. Ensure that assertions don't perform side effects.
* [http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html Programming With Assertions/Sun Microsystems]
* [[Assertions in NetBeans]]

===== Exception Handling (Exception) =====
Use exception-handling to handle errors, this helps everyone to identify and locate errors. Try to use the standard exceptions of the Java API and avoid empty Catch-blocks.
* [http://today.java.net/pub/a/today/2003/12/04/exceptions.html Three Rules for Effective Exception Handling by Jim Cushing/Sun Microsystems]

===== Casting (Cast) =====
Avoid casting values to reduce ClassCastException or may be a data loss. Generics or methods as toString(), intValue() etc. offer a way to avoid casts.

* [http://java.sun.com/docs/books/jls/second_edition/html/conversions.doc.html Conversions and Promotions/Sun Microsystems]
* [http://java.sun.com/j2se/1.5.0/docs/guide/language/generics.html Generics/Sun Microsystems]

==== Control Flow ====
===== Switch Default (Switch) =====
Every switch statement must have a default case.

===== Switch Fall-through (FallThrough) =====
Every case of a switch statement should be ended by a break statement. If that is not the case and a fall-through is intended, then this must be marked by a comment.

===== No Switch on Types (NoSoT) =====
Don't use switch, when the cases represent types. Prefer polymorphism.

===== If to Switch (IfToSwitch) =====
Nested if-statements should to be converted to switch-statements.

==== Modularity ====
===== Duplicate Code (Dupli) =====
Avoid and remove duplicate code. Put common code into an extra function.
Duplicate code may be okay, if otherwise dependencies among so far unrelated modules would be created.

===== Use of Class Library Classes (Reuse) =====
Classes and methods from the Java class libraries should be used instead of creating an own implementation.

===== Make Functions Short (Short) =====
Make functions short. A comment line or large control structures are hints to extract functions, making the containing function more concise and readable.

==== Design ====
===== No Cyclic Dependencies (CyclDep) =====
Avoid cyclic dependencies.

===== No Premature Generalization (PremGen) =====
Do not generalize before the second occurrence and no later than the third.

===== One Responsibility (OneResp) =====
Give one class one cohesive responsibility.

===== How to Inherit (Inherit) =====
Inherit to be reused, not to reuse. Else prefer composition over inheritance.

===== Liskov Substitution Principle (LSP) =====
Everything one can do with a base class, or is offered by an interface, has to be doable with all derived/implementing classes. If a subclass is allowed to omit the implementation of a given method, then this should be listed in the documentation of the base classes' method.

==== Security ====
===== Validate Input (ValInput) =====
Validate all input coming from external

===== No Types Overflows (TypesOver) =====
Be aware that primitive types have limited range.

==== Interfaces ====
===== Consistency (Consi) =====
Give the same thing the same name everywhere in the interface.
Let parameters with the same semantic always occur in the same order in different functions.
All parameters used for output should be at the end of the parameter list. Additionally it needs to be stated in the method documentation if a parameter is an output parameter.

===== Minimality (Min) =====
Provide only one way to do anything. Move functions that do not belong to the core functionality of the interface to more appropriate locations.
For classes: Put convenience functions as non-member functions in the same namespace beside the class.

==== OpenOffice.org ====
===== Query Interface (Qifc) =====
UnoRuntime.queryInterface() is costly regarding performance. When it has to be used in loops, it should be done outside of the loop and the result reused inside.

===== License (Lic) =====
tbd

The first draft of these guidelines was based on the [[Perl Coding Standards]] and the [http://www.fing.edu.uy/inco/cursos/ingsoft/iis/files/JavaChk.html Java Inspection Checklist].
----
[[Category:Coding Standards]]

Java Coding Standards

2008-06-13T10:29:01Z

Jj: /* Rules for Java */

=== Purpose ===
See the [[Cpp Coding Standards|C++ Coding Standards]] for the general purpose of Standards.

=== Rules for Java ===
==== Code Conventions ====
===== Java Code Conventions (Conv) =====
Follow Sun's Java Code Conventions [http://java.sun.com/docs/codeconv/CodeConventions.pdf] unless one of the rules below says otherwise. Keep local naming conventions.

==== Declarations: Scoping and Names ====
===== Naming Conventions (Names) =====
Descriptive variable, constant and method names must be used in accord with naming conventions.

===== Javadoc Headers (Javadoc) =====
Every class / non-private method needs to have a complete header in accordance with the javadoc style. When overriding a method of a superclass this header can be omitted if the content of the superclass description is still true for the implementation of the subclass. In these cases, if using Java5 or later, the @Override annotation must be used.

===== Comments (Comments) =====
Use enough comments in the code to make it understandable.

===== Access Modifiers (Access) =====
All attributes / methods must have appropriate access modifiers (private/protected/public). Make all class member data private.

===== Single Class (SingleClass) =====
Each file must only contain one class (except inner classes).

===== Explicit Imports (Import) =====
Don't import complete packages but name the classes to import explicitly.

==== Implementation Details ====
===== Static vs. Non-Static (Static) =====
Are there static attributes / methods that should be non-static or vice-versa?

===== Static Initializers =====
Avoid usage of classes other than from the Java class libraries in static initializers.

===== Variable Initialization (Init) =====
All variables need to be properly initialized.

===== Constants (Const) =====
Are there literal constants that should be named constants or are there variables that should be constants?

===== Keep Internals (Internal) =====
Better not expose member variables by giving out mutable class references as return values. Example: String (immutable) instead of StringBuffer (mutable).

===== Use a Single Return Value (ReturnVal) =====
Do not change parameter references in methods as a substitution for return values.

===== Parentheses (Paren) =====
Always use parentheses to avoid ambiguity.

===== Close I/O Resources (IO) =====
Opened files or connections need to be closed explicitly. Keep in mind that throwing exceptions can hinder closing resources. In those cases use finally to guarantee closing resources.

===== Assert Assumptions (Assert) =====
Assert liberally to document internal assumptions and invariants. Don't use assertions for runtime errors. Ensure that assertions don't perform side effects.
* [http://java.sun.com/j2se/1.4.2/docs/guide/lang/assert.html Programming With Assertions/Sun Microsystems]
* [[Assertions in NetBeans]]

===== Exception Handling (Exception) =====
Use exception-handling to handle errors, this helps everyone to identify and locate errors. Try to use the standard exceptions of the Java API and avoid empty Catch-blocks.
* [http://today.java.net/pub/a/today/2003/12/04/exceptions.html Three Rules for Effective Exception Handling by Jim Cushing/Sun Microsystems]

===== Casting (Cast) =====
Avoid casting values to reduce ClassCastException or may be a data loss. Generics or methods as toString(), intValue() etc. offer a way to avoid casts.

* [http://java.sun.com/docs/books/jls/second_edition/html/conversions.doc.html Conversions and Promotions/Sun Microsystems]
* [http://java.sun.com/j2se/1.5.0/docs/guide/language/generics.html Generics/Sun Microsystems]

==== Control Flow ====
===== Switch Default (Switch) =====
Every switch statement must have a default case.

===== Switch Fall-through (FallThrough) =====
Every case of a switch statement should be ended by a break statement. If that is not the case and a fall-through is intended, then this must be marked by a comment.

===== No Switch on Types (NoSoT) =====
Don't use switch, when the cases represent types. Prefer polymorphism.

===== If to Switch (IfToSwitch) =====
Nested if-statements should to be converted to switch-statements.

==== Modularity ====
===== Duplicate Code (Dupli) =====
Avoid and remove duplicate code. Put common code into an extra function.
Duplicate code may be okay, if otherwise dependencies among so far unrelated modules would be created.

===== Use of Class Library Classes (Reuse) =====
Classes and methods from the Java class libraries should be used instead of creating an own implementation.

===== Make Functions Short (Short) =====
Make functions short. A comment line or large control structures are hints to extract functions, making the containing function more concise and readable.

==== Design ====
===== No Cyclic Dependencies (CyclDep) =====
Avoid cyclic dependencies.

===== No Premature Generalization (PremGen) =====
Do not generalize before the second occurrence and no later than the third.

===== One Responsibility (OneResp) =====
Give one class one cohesive responsibility.

===== How to Inherit (Inherit) =====
Inherit to be reused, not to reuse. Else prefer composition over inheritance.

===== Liskov Substitution Principle (LSP) =====
Everything one can do with a base class, or is offered by an interface, has to be doable with all derived/implementing classes. If a subclass is allowed to omit the implementation of a given method, then this should be listed in the documentation of the base classes' method.

==== Security ====
===== Validate Input (ValInput) =====
Validate all input coming from external

===== No Types Overflows (TypesOver) =====
Be aware that primitive types have limited range.

==== Interfaces ====
===== Consistency (Consi) =====
Give the same thing the same name everywhere in the interface.
Let parameters with the same semantic always occur in the same order in different functions.
All parameters used for output should be at the end of the parameter list. Additionally it needs to be stated in the method documentation if a parameter is an output parameter.

===== Minimality (Min) =====
Provide only one way to do anything. Move functions that do not belong to the core functionality of the interface to more appropriate locations.
For classes: Put convenience functions as non-member functions in the same namespace beside the class.

===== Unambiguous Overloads (Over) =====
''Can integer overloads of function parameters be ambiguous in Java?''
Let all overloads of a function be unambiguous. Be aware of default arguments and integral vs. pointer parameters. Provide either only one version of an integral type or (rarely) overloads for all Java integer-types.

==== OpenOffice.org ====
===== Query Interface (Qifc) =====
UnoRuntime.queryInterface() is costly regarding performance. When it has to be used in loops, it should be done outside of the loop and the result reused inside.

===== License (Lic) =====
tbd

The first draft of these guidelines was based on the [[Perl Coding Standards]] and the [http://www.fing.edu.uy/inco/cursos/ingsoft/iis/files/JavaChk.html Java Inspection Checklist].
----
[[Category:Coding Standards]]

Java Coding Standards

2008-06-06T11:44:17Z

Jj: /* Rules for Java */

=== Purpose ===
See the [[Cpp Coding Standards|C++ Coding Standards]] for the general purpose of Standards.

=== Rules for Java ===
==== Code Conventions ====
===== Java Code Conventions (Conv) =====
Follow Sun's Java Code Conventions [http://java.sun.com/docs/codeconv/CodeConventions.pdf] unless one of the rules below says otherwise.

==== Declarations: Scoping and Names ====
===== Naming Conventions (Names) =====
Descriptive variable, constant and method names must be used in accord with naming conventions.

===== Javadoc Headers (Javadoc) =====
Every class / non-private method needs to have a complete header in accordance with the javadoc style. When overriding a method of a superclass this header can be omitted if the content of the superclass description is still true for the implementation of the subclass. In these cases, if using Java5 or later, the @Override annotation must be used.

===== Comments (Comments) =====
Use enough comments in the code to make it understandable.

===== Access Modifiers (Access) =====
All attributes / methods must have appropriate access modifiers (private/protected/public). Make all class member data private.

===== Single Class (SingleClass) =====
Each file must only contain one class (except inner classes).

===== Explicit Imports (Import) =====
Don't import complete packages but name the classes to import explicitly.

==== Implementation Details ====
===== Static vs. Non-Static (Static) =====
Are there static attributes / methods that should be non-static or vice-versa?

===== Static Initializers =====
Avoid usage of classes other than from the Java class libraries in static initializers.

===== Variable Initialization (Init) =====
All variables need to be properly initialized.

===== Constants (Const) =====
Are there literal constants that should be named constants or are there variables that should be constants?

===== Keep Internals (Internal) =====
Better not expose member variables by giving out mutable class references as return values. Example: String (immutable) instead of StringBuffer (mutable).

===== Parentheses (Paren) =====
Always use parentheses to avoid ambiguity.

===== Close I/O Resources (IO) =====
Opened files or connections need to be closed explicitly.

===== Assert Assumptions (Assert) =====
Assert (''what is the way to do this in Java?'') liberally to document internal assumptions and invariants. Don't use assertions for runtime errors. Ensure that assertions don't perform side effects.

==== Control Flow ====
===== Switch Default (Switch) =====
Every switch statement must have a default case.

===== Switch Fall-through (FallThrough) =====
Every case of a switch statement should be ended by a break statement. If that is not the case and a fall-through is intended, then this must be marked by a comment.

===== No Switch on Types (NoSoT) =====
Don't use switch, when the cases represent types. Prefer polymorphism.

===== If to Switch (IfToSwitch) =====
Nested if-statements should to be converted to switch-statements.

==== Modularity ====
===== Duplicate Code (Dupli) =====
Avoid and remove duplicate code. Put common code into an extra function.
Duplicate code may be okay, if otherwise dependencies among so far unrelated modules would be created.

===== Use of Class Library Classes (Reuse) =====
Classes and methods from the Java class libraries should be used instead of creating an own implementation.

===== Make Functions Short (Short) =====
Make functions short. A comment line or large control structures are hints to extract functions, making the containing function more concise and readable.

==== Design ====
===== No Cyclic Dependencies (CyclDep) =====
Avoid cyclic dependencies.

===== No Premature Generalization (PremGen) =====
Do not generalize before the second occurrence and no later than the third.

===== One Responsibility (OneResp) =====
Give one class one cohesive responsibility.

===== How to Inherit (Inherit) =====
Inherit to be reused, not to reuse. Else prefer composition over inheritance.

===== Liskov Substitution Principle (LSP) =====
Everything one can do with a base class, or is offered by an interface, has to be doable with all derived/implementing classes. If a subclass is allowed to omit the implementation of a given method, then this should be listed in the documentation of the base classes' method.

==== Security ====
===== Validate Input (ValInput) =====
Validate all input coming from external

===== No Types Overflows (TypesOver) =====
Be aware that primitive types have limited range.

==== Interfaces ====
===== Consistency (Consi) =====
Give the same thing the same name everywhere in the interface.
Let parameters with the same semantic always occur in the same order in different functions.
All parameters used for output should be at the end of the parameter list. Additionally it needs to be stated in the method documentation if a parameter is an output parameter.

===== Minimality (Min) =====
Provide only one way to do anything. Move functions that do not belong to the core functionality of the interface to more appropriate locations.
For classes: Put convenience functions as non-member functions in the same namespace beside the class.

===== Unambiguous Overloads (Over) =====
''Can integer overloads of function parameters be ambiguous in Java?''
Let all overloads of a function be unambiguous. Be aware of default arguments and integral vs. pointer parameters. Provide either only one version of an integral type or (rarely) overloads for all Java integer-types.

The first draft of these guidelines was based on the [[Perl Coding Standards]] and the [http://www.fing.edu.uy/inco/cursos/ingsoft/iis/files/JavaChk.html Java Inspection Checklist].
----
[[Category:Coding Standards]]

Java Coding Standards

2008-06-06T11:37:35Z

Jj: /* Rules for Java */

=== Purpose ===
See the [[Cpp Coding Standards|C++ Coding Standards]] for the general purpose of Standards.

=== Rules for Java ===
==== Code Conventions ====
===== Java Code Conventions (Conv) =====
Follow Sun's Java Code Conventions [http://java.sun.com/docs/codeconv/CodeConventions.pdf] unless one of the rules below says otherwise.

==== Declarations: Scoping and Names ====
===== Naming Conventions (Names) =====
Descriptive variable, constant and method names must be used in accord with naming conventions.

===== Javadoc Headers (Javadoc) =====
Every class / non-private method needs to have a complete header in accordance with the javadoc style. When overriding a method of a superclass this header can be omitted if the content of the superclass description is still true for the implementation of the subclass. In these cases, if using Java5 or later, the @Override annotation must be used.

===== Comments (Comments) =====
Use enough comments in the code to make it understandable.

===== Access Modifiers (Access) =====
All attributes / methods must have appropriate access modifiers (private/protected/public).

===== Private Data (PrivData) =====
Make all class member data private.

===== Single Class (SingleClass) =====
Each file must only contain one class (except inner classes).

===== Explicit Imports (Import) =====
Don't import complete packages but name the classes to import explicitly.

==== Implementation Details ====
===== Static vs. Non-Static (Static) =====
Are there static attributes / methods that should be non-static or vice-versa?

===== Static Initializers =====
Avoid usage of classes other than from the Java class libraries in static initializers.

===== Variable Initialization (Init) =====
All variables need to be properly initialized.

===== Constants (Const) =====
Are there literal constants that should be named constants or are there variables that should be constants?

===== Keep Internals (Internal) =====
Better not expose member variables by giving out mutable class references as return values. Example: String (immutable) instead of StringBuffer (mutable).

===== Parentheses (Paren) =====
Always use parentheses to avoid ambiguity.

===== Close I/O Resources (IO) =====
Opened files or connections need to be closed explicitly.

===== Assert Assumptions (Assert) =====
Assert (''what is the way to do this in Java?'') liberally to document internal assumptions and invariants. Don't use assertions for runtime errors. Ensure that assertions don't perform side effects.

==== Control Flow ====
===== Switch Default (Switch) =====
Every switch statement must have a default case.

===== Switch Fall-through (FallThrough) =====
Every case of a switch statement should be ended by a break statement. If that is not the case and a fall-through is intended, then this must be marked by a comment.

===== No Switch on Types (NoSoT) =====
Don't use switch, when the cases represent types. Prefer polymorphism.

===== If to Switch (IfToSwitch) =====
Nested if-statements should to be converted to switch-statements.

==== Modularity ====
===== Duplicate Code (Dupli) =====
Avoid and remove duplicate code. Put common code into an extra function.
Duplicate code may be okay, if otherwise dependencies among so far unrelated modules would be created.

===== Use of Class Library Classes (Reuse) =====
Classes and methods from the Java class libraries should be used instead of creating an own implementation.

===== Make Functions Short (Short) =====
Make functions short. A comment line or large control structures are hints to extract functions, making the containing function more concise and readable.

==== Design ====
===== No Cyclic Dependencies (CyclDep) =====
Avoid cyclic dependencies.

===== No Premature Generalization (PremGen) =====
Do not generalize before the second occurrence and no later than the third.

===== One Responsibility (OneResp) =====
Give one class one cohesive responsibility.

===== How to Inherit (Inherit) =====
Inherit to be reused, not to reuse. Else prefer composition over inheritance.

===== Liskov Substitution Principle (LSP) =====
Everything one can do with a base class, or is offered by an interface, has to be doable with all derived/implementing classes. If a subclass is allowed to omit the implementation of a given method, then this should be listed in the documentation of the base classes' method.

==== Security ====
===== Validate Input (ValInput) =====
Validate all input coming from external

===== No Types Overflows (TypesOver) =====
Be aware that primitive types have limited range.

==== Interfaces ====
===== Consistency (Consi) =====
Give the same thing the same name everywhere in the interface.
Let parameters with the same semantic always occur in the same order in different functions.
All parameters used for output should be at the end of the parameter list. Additionally it needs to be stated in the method documentation if a parameter is an output parameter.

===== Minimality (Min) =====
Provide only one way to do anything. Move functions that do not belong to the core functionality of the interface to more appropriate locations.
For classes: Put convenience functions as non-member functions in the same namespace beside the class.

===== Unambiguous Overloads (Over) =====
''Can integer overloads of function parameters be ambiguous in Java?''
Let all overloads of a function be unambiguous. Be aware of default arguments and integral vs. pointer parameters. Provide either only one version of an integral type or (rarely) overloads for all Java integer-types.

The first draft of these guidelines was based on the [[Perl Coding Standards]] and the [http://www.fing.edu.uy/inco/cursos/ingsoft/iis/files/JavaChk.html Java Inspection Checklist].
----
[[Category:Coding Standards]]

Java Coding Standards

2008-06-06T11:36:46Z

Jj: /* Rules for Java */

=== Purpose ===
See the [[Cpp Coding Standards|C++ Coding Standards]] for the general purpose of Standards.

=== Rules for Java ===
==== Code Conventions ====
===== Java Code Conventions (Conv) =====
Follow Sun's Java Code Conventions [http://java.sun.com/docs/codeconv/CodeConventions.pdf] unless one of the rules below says otherwise.

==== Declarations: Scoping and Names ====
===== Naming Conventions (Names) =====
Descriptive variable, constant and method names must be used in accord with naming conventions.

===== Javadoc Headers (Javadoc) =====
Every class / non-private method needs to have a complete header in accordance with the javadoc style. When overriding a method of a superclass this header can be omitted if the content of the superclass description is still true for the implementation of the subclass. In these cases, if using Java5 or later, the @Override annotation must be used.

===== Comments (Comments) =====
Use enough comments in the code to make it understandable.

===== Access Modifiers (Access) =====
All attributes / methods must have appropriate access modifiers (private/protected/public).

===== Private Data (PrivData) =====
Make all class member data private.

===== Single Class (SingleClass) =====
Each file must only contain one class (except inner classes).

===== Explicit Imports (Import) =====
Don't import complete packages but name the classes to import explicitly.

==== Implementation Details ====
===== Static vs. Non-Static (Static) =====
Are there static attributes / methods that should be non-static or vice-versa?

===== Static Initializers =====
Avoid usage of classes other than from the Java class libraries in static initializers.

===== Variable Initialization (Init) =====
All variables need to be properly initialized.

===== Constants (Const) =====
Are there literal constants that should be named constants or are there variables that should be constants?

===== Keep Internals (Internal) =====
Better not expose member variables by giving out mutable class references as return values. Example: String (immutable) instead of StringBuffer (mutable).

===== Parentheses (Paren) =====
Always use parentheses to avoid ambiguity.

===== Close I/O Resources (IO) =====
Opened files or connections need to be closed explicitly.

===== Assert Assumptions (Assert) =====
Assert (''what is the way to do this in Java?'') liberally to document internal assumptions and invariants. Don't use assertions for runtime errors. Ensure that assertions don't perform side effects.

==== Control Flow ====
===== Switch Default (Switch) =====
Every switch statement must have a default case.

===== Switch Fall-through (FallThrough) =====
Every case of a switch statement should be ended by a break statement. If that is not the case and a fall-through is intended, then this must be marked by a comment.

===== No Switch on Types (NoSoT) =====
Don't use switch, when the cases represent types. Prefer polymorphism.

===== If to Switch (IfToSwitch) =====
Nested if-statements should to be converted to switch-statements.

==== Modularity ====
===== Duplicate Code (Dupli) =====
Avoid and remove duplicate code. Put common code into an extra function.
Duplicate code may be okay, if otherwise dependencies among so far unrelated modules would be created.

===== Use of Class Library Classes (Reuse) =====
Classes and methods from the Java class libraries should be used instead of creating an own implementation.

===== Make Functions Short (Short) =====
Make functions short. A comment line or large control structures are hints to extract functions, making the containing function more concise and readable.

==== Design ====
===== No Cyclic Dependencies (CyclDep) =====
Avoid cyclic dependencies.

===== No Premature Generalization (PremGen) =====
Do not generalize before the second occurrence and no later than the third.

===== One Responsibility (OneResp) =====
Give one class one cohesive responsibility.

===== How to Inherit (Inherit) =====
Inherit to be reused, not to reuse. Else prefer composition over inheritance.

===== Liskov Substitution Principle (LSP) =====
Everything one can do with a base class, or is offered by an interface, has to be doable with all derived/implementing classes. If a subclass is allowed to omit the implementation of a given method, then this should be listed in the documentation of the base classes' method.

==== Security ====
===== Validate Input (ValInput) =====
Validate all input coming from external

===== No Types Overflows (TypesOver) =====
Be aware that primitive types have limited range.

==== Interfaces ====
===== Consistency (Consi) =====
Give the same thing the same name everywhere in the interface.
Let parameters with the same semantic always occur in the same order in different functions.
All parameters used for output should be at the end of the parameter list. Additionally it needs to be stated in the method documentation if a parameter is an output parameter.

===== Minimality (Min) =====
Provide only one way to do anything. Move functions that do not belong to the core functionality of the interface to more appropriate locations.
For classes: Put convenience functions as non-member functions in the same namespace beside the class.

===== Unambiguous Overloads (Over) =====
''Can integer overloads of function parameters be ambiguous in Java?''
Let all overloads of a function be unambiguous. Be aware of default arguments and integral vs. pointer parameters. Provide either only one version of an integral type or (rarely) overloads for all Java integer-types.

The first draft of these guidelines was based on the [[Perl Coding Standards]] and the [http://www.fing.edu.uy/inco/cursos/ingsoft/iis/files/JavaChk.html Java Inspection Checklist].
----
[[Category:Coding Standards]]

Java Coding Standards

2008-06-06T11:35:40Z

Jj: /* Rules for Java */

=== Purpose ===
See the [[Cpp Coding Standards|C++ Coding Standards]] for the general purpose of Standards.

=== Rules for Java ===
==== Code Conventions ====
===== Java Code Conventions (Conv) =====
Follow Sun's Java Code Conventions [http://java.sun.com/docs/codeconv/CodeConventions.pdf] unless one of the rules below says otherwise.

==== Declarations: Scoping and Names ====
===== Naming Conventions (Names) =====
Descriptive variable, constant and method names must be used in accord with naming conventions.

===== Javadoc Headers (Javadoc) =====
Every class / non-private method needs to have a complete header in accordance with the javadoc style. When overriding a method of a superclass this header can be omitted if the content of the superclass description is still true for the implementation of the subclass. In these cases, if using Java5 or later, the @Override annotation must be used.

===== Comments (Comments) =====
Use enough comments in the code to make it understandable.

===== Access Modifiers (Access) =====
All attributes / methods must have appropriate access modifiers (private/protected/public).

===== Private Data (PrivData) =====
Make all class member data private.

===== Single Class (SingleClass) =====
Each file must only contain one class (except inner classes).

===== Explicit Imports (Import) =====
Don't import complete packages but name the classes to import explicitly.

==== Implementation Details ====
===== Static vs. Non-Static (Static) =====
Are there static attributes / methods that should be non-static or vice-versa?

===== Static Initializers =====
Avoid usage of classes other than from the Java class libraries in static initializers.

===== Variable Initialization (Init) =====
All variables need to be properly initialized.

===== Constants (Const) =====
Are there literal constants that should be named constants or are there variables that should be constants?

===== Return Values (Return) =====
Every method needs to return the correct value at every function return point.

===== Keep Internals (Internal) =====
Better not expose member variables by giving out mutable class references as return values. Example: String (immutable) instead of StringBuffer (mutable).

===== Parentheses (Paren) =====
Always use parentheses to avoid ambiguity.

===== Close I/O Resources (IO) =====
Opened files or connections need to be closed explicitly.

===== Assert Assumptions (Assert) =====
Assert (''what is the way to do this in Java?'') liberally to document internal assumptions and invariants. Don't use assertions for runtime errors. Ensure that assertions don't perform side effects.

==== Control Flow ====
===== Switch Default (Switch) =====
Every switch statement must have a default case.

===== Switch Fall-through (FallThrough) =====
Every case of a switch statement should be ended by a break statement. If that is not the case and a fall-through is intended, then this must be marked by a comment.

===== No Switch on Types (NoSoT) =====
Don't use switch, when the cases represent types. Prefer polymorphism.

===== If to Switch (IfToSwitch) =====
Nested if-statements should to be converted to switch-statements.

==== Modularity ====
===== Duplicate Code (Dupli) =====
Avoid and remove duplicate code. Put common code into an extra function.
Duplicate code may be okay, if otherwise dependencies among so far unrelated modules would be created.

===== Use of Class Library Classes (Reuse) =====
Classes and methods from the Java class libraries should be used instead of creating an own implementation.

===== Make Functions Short (Short) =====
Make functions short. A comment line or large control structures are hints to extract functions, making the containing function more concise and readable.

==== Design ====
===== No Cyclic Dependencies (CyclDep) =====
Avoid cyclic dependencies.

===== No Premature Generalization (PremGen) =====
Do not generalize before the second occurrence and no later than the third.

===== One Responsibility (OneResp) =====
Give one class one cohesive responsibility.

===== How to Inherit (Inherit) =====
Inherit to be reused, not to reuse. Else prefer composition over inheritance.

===== Liskov Substitution Principle (LSP) =====
Everything one can do with a base class, or is offered by an interface, has to be doable with all derived/implementing classes. If a subclass is allowed to omit the implementation of a given method, then this should be listed in the documentation of the base classes' method.

===== Instantiate Only Leaves (Leaves) =====
In an inheritance tree of virtual classes, instantiate only the leaves. Make constructors of base classe protected, so instantiation is impossible.

==== Security ====
===== Validate Input (ValInput) =====
Validate all input coming from external

===== No Types Overflows (TypesOver) =====
Be aware that primitive types have limited range.

==== Interfaces ====
===== Consistency (Consi) =====
Give the same thing the same name everywhere in the interface.
Let parameters with the same semantic always occur in the same order in different functions.
All parameters used for output should be at the end of the parameter list. Additionally it needs to be stated in the method documentation if a parameter is an output parameter.

===== Minimality (Min) =====
Provide only one way to do anything. Move functions that do not belong to the core functionality of the interface to more appropriate locations.
For classes: Put convenience functions as non-member functions in the same namespace beside the class.

===== Unambiguous Overloads (Over) =====
''Can integer overloads of function parameters be ambiguous in Java?''
Let all overloads of a function be unambiguous. Be aware of default arguments and integral vs. pointer parameters. Provide either only one version of an integral type or (rarely) overloads for all Java integer-types.

The first draft of these guidelines was based on the [[Perl Coding Standards]] and the [http://www.fing.edu.uy/inco/cursos/ingsoft/iis/files/JavaChk.html Java Inspection Checklist].
----
[[Category:Coding Standards]]

Java Coding Standards

2008-06-06T11:28:50Z

Jj: /* Rules for Java */

=== Purpose ===
See the [[Cpp Coding Standards|C++ Coding Standards]] for the general purpose of Standards.

=== Rules for Java ===
==== Code Conventions ====
===== Java Code Conventions (Conv) =====
Follow Sun's Java Code Conventions [http://java.sun.com/docs/codeconv/CodeConventions.pdf] unless one of the rules below says otherwise.

==== Declarations: Scoping and Names ====
===== Naming Conventions (Names) =====
Descriptive variable, constant and method names must be used in accord with naming conventions.

===== Javadoc Headers (Javadoc) =====
Every class / non-private method needs to have a complete header in accordance with the javadoc style. When overriding a method of a superclass this header can be omitted if the content of the superclass description is still true for the implementation of the subclass. In these cases, if using Java5 or later, the @Override annotation must be used.

===== Comments (Comments) =====
Use enough comments in the code to make it understandable.

===== Access Modifiers (Access) =====
All attributes / methods must have appropriate access modifiers (private/protected/public).

===== Private Data (PrivData) =====
Make all class member data private.

===== Single Class (SingleClass) =====
Each file must only contain one class (except inner classes).

===== Explicit Imports (Import) =====
Don't import complete packages but name the classes to import explicitly.

==== Implementation Details ====
===== Static vs. Non-Static (Static) =====
Are there static attributes / methods that should be non-static or vice-versa?

===== Variable Initialization (Init) =====
All variables need to be properly initialized.

===== Constants (Const) =====
Are there literal constants that should be named constants
 ''seems to be the same as MagNum ?''

or are there variables that should be constants?

===== No Magic Numbers (MagNum) =====
Do not use unnamed constants in your code. Give them descriptive names.

===== Return Values (Return) =====
Every method needs to return the correct value at every function return point.

===== Keep Internals (Internal) =====
Be careful not to expose member variables by giving out mutable class references as return values. Example: String (immutable) instead of StringBuffer (mutable).

===== Parentheses (Paren) =====
Always use parentheses to avoid ambiguity.

===== Close I/O Resources (IO) =====
Opened files or connections need to be closed explicitly.

===== Assert Assumptions (Assert) =====
Assert (''what is the way to do this in Java?'') liberally to document internal assumptions and invariants. Don't use assertions for runtime errors. Ensure that assertions don't perform side effects.

==== Control Flow ====
===== Switch Default (Switch) =====
Every switch statement must have a default case.

===== Switch Fall-through (FallThrough) =====
Every case of a switch statement should be ended by a break statement. If that is not the case and a fall-through is intended, then this must be marked by a comment.

===== No Switch on Types (NoSoT) =====
Don't use switch, when the cases represent types. Prefer polymorphism.

===== If to Switch (IfToSwitch) =====
Nested if-statements should to be converted to switch-statements.
 ''is that really a rule? possible with non-integer values in Java?''

==== Modularity ====
===== Duplicate Code (Dupli) =====
Avoid and remove duplicate code. Put common code into an extra function.
Duplicate code may be okay, if otherwise dependencies among so far unrelated modules would be created.

===== Use of Class Library Classes (Reuse) =====
Classes and methods from the Java class libraries should be used instead of creating an own implementation.

===== Make Functions Short (Short) =====
Make functions short. A comment line or large control structures are hints to extract functions, making the containing function more concise and readable.

==== Design ====
===== No Cyclic Dependencies (CyclDep) =====
Avoid cyclic dependencies.

===== No Premature Generalization (PremGen) =====
Do not generalize before the second occurrence and no later than the third.

===== One Responsibility (OneResp) =====
Give one class one cohesive responsibility.

===== How to Inherit (Inherit) =====
Inherit to be reused, not to reuse. Else prefer composition over inheritance.

===== Liskov Substitution Principle (LSP) =====
Everything one can do with a base class, or is offered by an interface, has to be doable with all derived/implementing classes.

===== Instantiate Only Leaves (Leaves) =====
In an inheritance tree of virtual classes, instantiate only the leaves. Make constructors of base classe protected, so instantiation is impossible.

==== Security ====
===== Validate Input (ValInput) =====
Validate all input coming from external

===== No Types Overflows (TypesOver) =====
Be aware that primitive types have limited range.

==== Interfaces ====
===== Consistency (Consi) =====
Give the same thing the same name everywhere in the interface.
Let parameters with the same semantic always occur in the same order in different functions.

===== Minimality (Min) =====
Provide only one way to do anything. Move functions that do not belong to the core functionality of the interface to more appropriate locations.
For classes: Put convenience functions as non-member functions in the same namespace beside the class.

===== Unambiguous Overloads (Over) =====
''Can integer overloads of function parameters be ambiguous in Java?''
Let all overloads of a function be unambiguous. Be aware of default arguments and integral vs. pointer parameters. Provide either only one version of an integral type or (rarely) overloads for all Java integer-types.

The first draft of these guidelines was based on the [[Perl Coding Standards]] and the [http://www.fing.edu.uy/inco/cursos/ingsoft/iis/files/JavaChk.html Java Inspection Checklist].
----
[[Category:Coding Standards]]

Java Coding Standards

2008-05-30T11:12:00Z

Jj: First draft of Java Coding Standards

=== Purpose ===
See the [[Cpp Coding Standards|C++ Coding Standards]] for the general purpose of Standards.

=== Rules for Java ===
==== Declarations: Scoping and Names ====
===== Naming Conventions (Names) =====
Descriptive variable, constant and method names must be used in accord with naming conventions.

===== Javadoc Headers (Javadoc) =====
Every class / non-private method needs to have a complete header in accordance with the javadoc style. When overriding a method of a superclass this header can be omitted if the content of the superclass description is still true for the implementation of the subclass.

===== Comments (Comments) =====
Use enough comments in the code to make it understandable.

===== Access Modifiers (Access) =====
All attributes / methods must have appropriate access modifiers (private/protected/public).

===== Single class (SingleClass) =====
Each file must only contain one class (except inner classes).

==== Implementation Details ====
===== Static vs. Non-Static (Static) =====
Are there static attributes / methods that should be non-static or vice-versa?

===== Variable Initialization (Init) =====
All variables need to be properly initialized.

===== Constants (Const) =====
Are there literal constants that should be named constants or are the variables that should be constants?

===== Return Values (Return) =====
Every method needs to return the correct value at every function return point.

===== Paranthesis (Paren) =====
Always use paranthesis to avoid ambiguity.

===== Close I/O Resources (IO) =====
Opened files or connections need to be closed explicitly.

==== Control Flow ====
===== Switch Default (Switch) =====
Every switch statement must have a default case.

===== Switch Fall-through (FallThrough) =====
Every case of a switch statement should be ended by a break statement. If that is not the case and a fall-through is intended, then this must be marked by a comment.

===== If to Switch (IfToSwitch) =====
Nested if-statements should to be converted to switch-statements.

==== Modularity ====
===== Duplicate Code (Dupli) =====
Avoid and remove duplicate code. Put common code into an extra function.
Duplicate code may be okay, if otherwise dependencies among so far unrelated modules would be created.

===== Use of Class Library Classes (Reuse) =====
Classes and methods from the Java class libraries should be used instead of creating an own implementation.

===== Make Functions Short (Short) =====
Make functions short. A comment line or large control structures are hints to extract functions, making the containing function more concise and readable.

The first draft of these guidelines was based on the [[Perl Coding Standards]] and the [http://www.fing.edu.uy/inco/cursos/ingsoft/iis/files/JavaChk.html Java Inspection Checklist].
----
[[Category:Coding Standards]]

OOoRelease30

2008-05-21T12:28:04Z

Jj: /* OOo 3.0 Final */

= OOo 3.0 =

* <s>first translation handover: January 18th, 2008</s>
* <s>UI and [[Feature_freeze]]: March 6th, 2008</s>
* <s>[[Translation for 3.0|Translation update 3.0]] start: March 13th, 2008</s>

== OOo 3.0 Beta ==

* Translation update 3.0 delivery: April 3rd, 2008, code freeze for Beta
* Code Freeze: April 3rd, 2008
* begin TCM sanity testing: April 10th, 2008
* "last cws integration" for Beta: April 17th, 2008
** draft for [[OOoRelease30_Readme | OOo 3.0 Readme]]
* OpenOffice.org 3.0 Beta: April 30th, 2008
** BEA300_m1 build: April 24th, 2008
** BEA300_m2 build: April 28th, 2008 -> available for download April 30th
** May 5th: release status meeting: decision for releasing m2 as OOo 3.0 Beta -> official release announcement May 7th.

* TCM Beta testing: May 5th - 26th, 2008

There is the [http://www.openoffice.org/issues/show_bug.cgi?id=87736 Meta issue 87736] to track the potential stoppers for the beta release. If anyone would like to raise an issue for the release, please add the issue id of the issue you want to raise as dependent issue to the Meta Issue and drop a note on releases@openoffice.org, that and why you want to declare that issue as a stopper for releases.

Please note that there is no special IZ target and no cws target for the Beta release. The branch "BEA300" for the 3.0 Beta release will be opened in the week of April 7th to 11th once the childworkspace <changefileheader> has been integrated. Only stoppers for the Beta release will get accepted on that branch.

please also see [[ReleaseStatus_Minutes#Agenda_for_next_meeting]] for decision making.

=== Release Plan for 3.0.0 Beta release ===

{| border = "1" CELLPADDING=2
|-
! Task !! Who !! Deadline !! Comments
|-
! last cws integration for Beta build / BEA300_mx
| mh, RE || ||done
|-
! release notes
| mh, ja || || 'final release' release notes to be provided by Erwin
|-
! Setup Guides
| || ||
|-
! Upload of Beta build
| ja || done || '''full install sets for:''' en-US da de es fr it ja nl ko pl ru sv pt-BR zh-CN zh-TW gl

'''language packs for:''' af ar as-IN be-BY bg br bs ca cs da de dz el en-GB en-ZA es et fi fr ga gu he hi-IN hr hu it ja ka km ko ku lt mk ml-IN mr-IN nb ne nl nn nr ns or-IN pa-IN pl pt pt-BR rw sh sk sl sr ss st sv sw-TZ ta te-IN tg th ti-ER tr ts uk ur-IN ve vi xh zh-CN zh-TW zu

|-
! Trigger QA of final builds
| ja || ||
|-
! Track Status of localized builds
| ja || not tracked || [http://qatrack.services.openoffice.org]
|-
! Publish status of [http://qa.openoffice.org/qatesttool automated GUI testing]
| [[User:wg|wg]] || ||
|-
! Update of Beta pages
| ja || || done
|-
! QA of English Beta builds
| ja || ||
|-
! Update of SDK
| ja || || no SDK update for Beta build
|-
! Update of URE
| ja || || no URE update for Beta build
|-
! Update of SDK Release Notes and update of redirect page
[http://download.openoffice.org/sdk.html download.openoffice.org/sdk.html]
| jsc/ja || || not necessary for Beta build
|-
! Upload of src tarballs
| ja || || done
|-
! msg to announce@ooo content
| louis || ||
|-
!
| ja || ||
|-
! download pages
| ja || || done http://download.openoffice.org/3.0beta
|-
! upload of solver tarballs
| ja || || not for Beta build
|-
! notification of mirrors
| ja || || done
|-
! Update of Bittorrents
| (mike!) || ||
|-
! Update of P2P page
| antbryan || ||
|-
! press kit update
| jpmcc/lsp || ||
|-
! press release/alert
| jpmcc || ||
|-
! homepage
| louis || ||
|-
! release
| all || ||
|-
|}

== OOo 3.0 Final ==

* UI string fixes, translation handover: June 5th, 2008
* [[code_freeze]], last regular translation delivery: July 4th, 2008
* l10n CWS builds available: July 11th, 2008
* TCM sanity testing on CWS builds: July 11-17th, 2008
* [[Last cws integration]] for fixes: July 18th, 2008
* release candidate for all languages: July 25th, 2008, begin of TCM testing
* Product release: September 2nd, 2008

'''Download these events as an iCal-File: [[Media:Ooo3-events-2008.doc]]. (Rename to .ics after download)'''

{{OOo Releases}}

[[Category:Releases]]

OOoRelease30 BEA300

2008-04-25T15:55:48Z

Jj: added obo28, sw30beta02 and dba30beta1 to the list, removed dba30c

Since there is no EIS target OOo 3.0 Beta ( for good reason) we will track with this table which cws will go into which codeline.

{| class="prettytable"
| '''BEA300'''
| '''DEV300'''

|-
| mav32 (88424, 88435) (cloned, integrated m1)
| hr50 (Linux 64 bit changes)

|-
| native148 (installation of language packs, 88445) (cloned, integrated m1)
| Cmcfixes43

|-
| <strike>dba30c (cloned)</strike>
| mib07

|-
| sw30beta01 (cloned)
| aw055

|-
| registrationurl (cloned, integrated m1)
| tl50

|-
| dba30beta (cloned)
|

|-
| obr08b (cloned)
|

|-
| ab49 (cloned, integrated m1)
|

|-
| pdfimportfix (cloned, integrated m1)
|

|-
| tkr12
|

|-
| clbetafix01
|

|-
| l10nfixooo3b
|

|-
| obo28
|

|-
| sw30beta02
|

|-
| dba30beta1
|
|}

OOoRelease30 BEA300

2008-04-24T14:50:40Z

Jj: added l10nfixooo3b to the list

Since there is no EIS target OOo 3.0 Beta ( for good reason) we will track with this table which cws will go into which codeline.

{| class="prettytable"
| '''BEA300'''
| '''DEV300'''

|-
| mav32 (88424, 88435) (cloned, integrated m1)
| hr50 (Linux 64 bit changes)

|-
| native148 (installation of language packs, 88445) (cloned,integrated m1)
| Cmcfixes43

|-
| dba30c (cloned)
| mib07

|-
| sw30beta01 (cloned)
| aw055

|-
| registrationurl (cloned, integrated m1)
| tl50

|-
| dba30beta (cloned)
|

|-
| obr08b (cloned)
|

|-
| ab49 (cloned, integrated m1)
|

|-
| pdfimportfix (cloned, integrated m1)
|

|-
| tkr12
|

|-
| clbetafix01
|

|-
| l10nfixooo3b
|
|}

OOoRelease30 BEA300

2008-04-24T14:42:15Z

Jj:

Since there is no EIS target OOo 3.0 Beta ( for good reason) we will track with this table which cws will go into which codeline.

{| class="prettytable"
| '''BEA300'''
| '''DEV300'''

|-
| mav32 (88424, 88435) (cloned, integrated m1)
| hr50 (Linux 64 bit changes)

|-
| native148 (installation of language packs, 88445) (cloned,integrated m1)
| Cmcfixes43

|-
| dba30c (cloned)
| mib07

|-
| sw30beta01 (cloned)
| aw055

|-
| registrationurl (cloned, integrated m1)
| tl50

|-
| dba30beta (cloned)
|

|-
| obr08b (cloned)
|

|-
| ab49 (cloned, integrated m1)
|

|-
| pdfimportfix (cloned, integrated m1)
|

|-
| tkr12
|

|-
| clbetafix01
|
|}

OOoRelease30 BEA300

2008-04-24T14:41:40Z

Jj: added tkr12 and clbetafix01 to the list

Since there is no EIS target OOo 3.0 Beta ( for good reason) we will track with this table which cws will go into which codeline.

{| class="prettytable"
| BEA300
| DEV300

|-
| mav32 (88424, 88435) (cloned, integrated m1)
| hr50 (Linux 64 bit changes)

|-
| native148 (installation of language packs, 88445) (cloned,integrated m1)
| Cmcfixes43

|-
| dba30c (cloned)
| mib07

|-
| sw30beta01 (cloned)
| aw055

|-
| registrationurl (cloned, integrated m1)
| tl50

|-
| dba30beta (cloned)
|

|-
| obr08b (cloned)
|

|-
| ab49 (cloned, integrated m1)
|

|-
| pdfimportfix (cloned, integrated m1)
|

|-
| tkr12
|

|-
| clbetafix01
|
|}

Infrastructure Requirements

2007-11-27T16:35:57Z

Jj:

The following list contains the major functionalities expected from the
OpenOffice.org infrastructure. The bullet points have been collected with focus on
software developerment but are also applicable for the user oriented needs.

== Prioritized Item List ==

# Framework / Core
#* lightweight role / user administration / SSH key management [incl. authorization / authentication interfaces for cmdline / web based apps] (e.g. LDAP directory, could be placed on the SVN/CVS server)
#* SubProjects and SubProject Categories:
#** The OpenOffice.org project is being organized into different SubProjects having their own DNS entries for WebSpace and Mailinglists eg. xml.openoffice.org; '''must'''; see also DNS
#** Subprojects are classified into the 3 subproject catagories Accepted Project, Incubator Project, Native Language Project; '''must'''
#** Access rights configurable for individual Subprojects; '''must'''
#** A Domain Developer role gives access rights to all subprojects of the openoffice.org project; '''must'''
#** documents and files feature per subproject where documents can be uploaded; edited etc.; '''must'''
#** search feature - search in all OpenOffice.org subprojects or inside current OpenOffice.org subproject; '''must'''
#** project announcements; '''should'''
#* Sign-on
#** Single sign-on across the different applications; '''must'''
#** API to enable third-party applications to use the single sign-on; '''must'''
#* Site Search
#** covering web pages, issues, mailing lists; '''must'''
#** no of pages: ~450k
# DNS
#* Required Domain Name Service DNS Entries:
#** DNS Records for SubProjects of openoffice.org eg. gsl.openoffice.org, api.openoffice.org, tools.openoffice.org, de.openoffice.org. This includes Entries for Native Language Communities for example de.openoffice.org. All entries must have IP Address under which the sub-projects web content is being served and also MX records for the projects mailing lists.; '''must'''
#** DNS Entry for SubDomain services.openoffice.org in control of DNS Server operated by StarOffice department, for tools like the Environment Information System (EIS); '''must'''
#** DNS Entry for download.openoffice.org serving own web content; '''must'''
#** DNS Entry for support.openoffice.org serving own web content; '''must'''
#** DNS Entry for contributing.openoffice.org serving own web content; '''must'''
#** DNS Entry for about.openoffice.org serving own web content; '''must'''
# Web pages
#* subprojects need own DNS entries, see DNS; '''must'''; external sites contain links to web content of subprojects which we would otherwise break
#* special purpose web pages on own website (download, support, contributing, about), see DNS; '''must'''; If not otherwise possible these may be configured as individual subprojects but it´s preferable to have the www.openoffice.org main site plus these special sites belong to just one subproject named website where content developers can join.
#* Navigation Bar on top available to all sub-projects and special purpose websites; '''must'''
#* Navigation Bar left, project specific; '''must'''
#* global info boxes on right side of MyPage, with eg. Community Council Announcements, Download section
#* project specific announcements on MyPage; '''must'''
#** Default Content of left navigation bar per subproject but overrideable per subdirectory; '''must'''
#** Migration for files specifying content of left navigation bar in subdirectories; '''nice to have'''
#** Content modification:
#* all webpages in the repository are automatically surrounded by standard header (including login possibility, logo and top navigation bar), procject/directory specific left navigation bar and standard footer (including eg. copyright information); '''must'''
#* possibility to get HTML pages without the surrounding navigation, header and footer content via /nonav/ in URL; '''must'''
# Version Control System for source code [For web publishing and documentation see CMS.] [Some time ago we created a requirements list for a new OpenOffice.org SCM system. This can be found here: http://wiki.services.openoffice.org/wiki/SCM_Requirements.] The most important ones (distilled from the mentioned list):
#* Clients:
#** Clients must be available for all our supported platforms; '''must'''; OK for Subversion
#* Branches:
#** SCM system needs to easily support a multitude of branches; '''must'''; OK for Subversion; not supported for Mercurial
#** Merge tracking should be either available or can be implemented by hand; '''must'''; OK for Subversion;
#* Authentication:
#** Passwords must be securely transmitted to prevent malicious commits; '''must'''
#* Import:
#** Import from CVS needs to be history preserving; '''must'''
#** Import from CVS should be customizable (for example leave out old branches etc); '''should'''
#** Import from CVS needs to be doable in days during final migration phase; '''must'''; OK for Subversion with fsfs backend; not OK for Subversion with bdb backend; not OK for Mercurial;
#* Performance:
#** The performance of common used operations (checkout, commit, log, merge) should not be significantly slower than CVS as presented by CN; '''must'''
#* Replication:
#** There needs to be a way to replicate the repository to save bandwidth; '''must'''
#* Binary files, LF/CR conversions
#** Proper handling of binary files; '''must'''; OK for Subversion;
#** LF/CR conversions; '''should'''; OK for Subversion;
#* admin access for deletion, move
#* functionality similar to cvsup, anoncvs, viewcvs, notification mails; '''must'''
#* simple permission system; '''should'''
#* Sudo root access for selected admins; '''should'''
#* Functionality similar to bonsai, lxr, fisheye / CIA etc.; '''should'''
#Bugtracking
#* Number of issues inside OOo:
#** total 82600 (closed 57693)
#** number of distinct submitters: 18500
#** number of distinct assignees: 1600
#** number of attached files: 49000
#* States:
#** ASSIGNED, CLOSED, NEW, REOPEN, RESOLVED, STARTED, UNCONFIRMED, VERIFIED; '''must'''
#* Resolution:
#** DUPLICATE, FIXED, INVALID, LATER, REMIND, WONTFIX, WORKSFORME; '''must''' (Further details about the workflow and the relationship between State and Resolution http://www.openoffice.org/scdocs/issue_lifecycle.html)
#* Types:
#** DEFECT, ENHANCEMENT, FEATURE, PATCH, TASK; '''must''' (may be PATCH can be dropped later -> Was a request for CollabNet)
#* Additional fields and values:
#* Import- and export of data:
#** XML; '''must'''
#** remove export as 'Word'/'Excel'; '''must'''
#* Attachments:
#** Possibility to attach any type of file to the issue, eg. OpenOffice.org documents, pictures, source code, source code patches; '''must'''
#* Keywords:
#** List of Keywords or tags to assign to issues as a method to organize QA work; '''must'''
#* central configuration; '''must'''
#* Email-notification of modified issues; '''must'''
#* One issue-tracking instance for more than one project; '''must'''
# Wiki (CMS)
#* MediaWiki, version ? ; '''should'''
#* Required extensions/features:
#** DisplayTitle feature ; '''must''' for Docs
#** DynamicPageList; '''should'''
#** Syntax Highlighter (GeSHi) ; '''must''' for Docs
#** Breadcrumbs ; '''must''' for Docs
#** Hierarchical pages ; '''must''' for Docs;
#** Category Tree; '''should'''
#** wfGFlashExtension; '''should'''
#** wfLabeledSectionTransclusion ; '''must''' for Docs
#** Parser extensions (own implementation) ; '''must''' for Docs
#* Possibility of installing own extensions ; '''must'''
#* Number of categories: 200
#* Number of pages: 7723 within 2000 content pages (Docs will soon increase this number by 900 (DevGuide) and possibly another 2,000 (Help)
#* Number of uploaded files: 2200
#* Number of edit/day: 7
#* Number of users: 10181 Further details http://wiki.services.openoffice.org/wiki/Special:Statistics
#* allow branding; '''must'''
#* localized UI; '''should'''
#* versioned; '''must'''
#* namespaces; '''must'''
#* reuse of content (templates, server-side-include); '''must'''
#* publication routes for wiki-based documentation (ODF/PDF); '''should'''
#* localization of wiki-based content; '''should'''
# Mailing Lists
#* Types:
#**unmoderated;open to anyone(mostly unused at collab); '''must'''
#**discuss;subcribed users Post/Read allowed,archive Read allowed others moderated (most common); '''must'''
#**moderated;Post always moderated; Read archive; '''must'''
#**allowed poster:
#**domain wide allowed poster:
#**sublist;subcribed to another List; gathering global Information eg; issues@<project>.openoffice.org to ML issues@openoffice; '''must'''
#* non-site-member subscription (external archives); '''must'''
#* Archiving; '''must'''
#* Toplevel mailinglists: allcvs@openoffice.org; '''must'''
#* migrating current Archives; '''must'''
#* round about 850 Mailinglists with different types to migrate; '''must'''
#* SPAM / Virus protected (Important especially for agenda@council.openoffice.org. See "Comm b/w CC and CMs" below); '''must'''
#* [RSS] for easy syndication of new from various parts of the site, including the home page and mac port pages.; '''should'''
#* webbased forums; '''should'''
#* NNTP; '''must'''
#* attachment stripping; '''must'''
#* customizable headers, footers, robot replies; '''must'''
# Audit
# Communication between Community Council and Community Members
#* Protect [http://council.openoffice.org/servlets/BrowseList?listName=agenda&by=date&from=2007-10-01&to=2007-10-31&first=1&count=22 agenda@council.openoffice.org] against spams and make it easy-to-post and easy-to-find community-proposals which should not be buried in spams.
#* Additional infrastructure where CC can listen to contributors, developers and other Community members and talk with them daily.
# L10n and T9n for about 100 languages
#* Storage for:
#** Pootle
#** translation memories
#** glossaries
#** KeyID builds
#** extensions translation process
#** documentation translation process
#* Management tools

== Unprioritized List ==

* localization of UI parts (bugtracking, webpages, ...) and process for new locales
* reporting / stats / logfiles
* Search via Google, Yahoo, ...
* mail forwarding (xxx@openoffice.org)
* IP / domain blocking
* blog / planet
* download, documents & files structured in folders
* surveys / votes / polls
* general open-ness for integration of scripting (PHP, Perl, ...)
* MySQL databases
* provide SSL logon for security reasons
* rise the limit for mail attachments from 2 MB to 10 MB

== Migration process ==
* public access to the staging server

== Key Numbers ==

Per day the main site (actually the accelerators) receives 4-6M hits / 100,000 - 150,000 visits and sends 40-60GB. In peaks like the OpenOffice.org 2.0 launch there were > 16M hits per day with more than 400,000 visits.

The mail server has to be prepared to handle 50 msg/sec and 300 parallel sessions when the rising tide flows in.

== See also ==
* [[Infrastructure_Overview]]
* [[Infrastructure_Problems]]

[[Category:Website]]

Infrastructure Requirements

2007-11-27T16:06:02Z

Jj:

The following list contains the major functionalities expected from the
OpenOffice.org infrastructure. The bullet points have been collected with focus on
software developerment but are also applicable for the user oriented needs.

== Prioritized Item List ==

# Framework / Core
#* lightweight role / user administration / SSH key management [incl. authorization / authentication interfaces for cmdline / web based apps] (e.g. LDAP directory, could be placed on the SVN/CVS server)
#* SubProjects and SubProject Categories:
#** The OpenOffice.org project is being organized into different SubProjects having their own DNS entries for WebSpace and Mailinglists eg. xml.openoffice.org; '''must'''; see also DNS
#** Subprojects are classified into the 3 subproject catagories Accepted Project, Incubator Project, Native Language Project; '''must'''
#** Access rights configurable for individual Subprojects; '''must'''
#** A Domain Developer role gives access rights to all subprojects of the openoffice.org project; '''must'''
#** documents and files feature per subproject where documents can be uploaded; reserved; edited etc.; '''must'''
#** search feature - search in all OpenOffice.org subprojects or inside current OpenOffice.org subproject; '''must'''
#** project announcements; '''should'''
#* Sign-on
#** Single sign-on across the different applications; '''must'''
#** API to enable third-party applications to use the single sign-on; '''must'''
#* Site Search
#** covering web pages, issues, mailing lists; '''must'''
#** no of pages: ~450k
# DNS
#* Required Domain Name Service DNS Entries:
#** DNS Records for SubProjects of openoffice.org eg. gsl.openoffice.org, api.openoffice.org, tools.openoffice.org, de.openoffice.org. This includes Entries for Native Language Communities for example de.openoffice.org. All entries must have IP Address under which the sub-projects web content is being served and also MX records for the projects mailing lists.; '''must'''
#** DNS Entry for SubDomain services.openoffice.org in control of DNS Server operated by StarOffice department, for tools like the Environment Information System (EIS); '''must'''
#** DNS Entry for download.openoffice.org serving own web content; '''must'''
#** DNS Entry for support.openoffice.org serving own web content; '''must'''
#** DNS Entry for contributing.openoffice.org serving own web content; '''must'''
#** DNS Entry for about.openoffice.org serving own web content; '''must'''
# Web pages
#* subprojects need own DNS entries, see DNS; '''must'''; external sites contain links to web content of subprojects which we would otherwise break
#* special purpose web pages on own website (download, support, contributing, about), see DNS; '''must'''; If not otherwise possible these may be configured as individual subprojects but it´s preferable to have the www.openoffice.org main site plus these special sites belong to just one subproject named website where content developers can join.
#* Navigation Bar on top available to all sub-projects and special purpose websites; '''must'''
#* Navigation Bar left, project specific; '''must'''
#* global info boxes on right side of MyPage, with eg. Community Council Announcements, Download section
#* project specific announcements on MyPage; '''must'''
#** Default Content of left navigation bar per subproject but overrideable per subdirectory; '''must'''
#** Migration for files specifying content of left navigation bar in subdirectories; '''nice to have'''
#** Content modification:
#* all webpages in the repository are automatically surrounded by standard header (including login possibility, logo and top navigation bar), procject/directory specific left navigation bar and standard footer (including eg. copyright information); '''must'''
#* possibility to get HTML pages without the surrounding navigation, header and footer content via /nonav/ in URL; '''must'''
# Version Control System for source code [For web publishing and documentation see CMS.] [Some time ago we created a requirements list for a new OpenOffice.org SCM system. This can be found here: http://wiki.services.openoffice.org/wiki/SCM_Requirements.] The most important ones (distilled from the mentioned list):
#* Clients:
#** Clients must be available for all our supported platforms; '''must'''; OK for Subversion
#* Branches:
#** SCM system needs to easily support a multitude of branches; '''must'''; OK for Subversion; not supported for Mercurial
#** Merge tracking should be either available or can be implemented by hand; '''must'''; OK for Subversion;
#* Authentication:
#** Passwords must be securely transmitted to prevent malicious commits; '''must'''
#* Import:
#** Import from CVS needs to be history preserving; '''must'''
#** Import from CVS should be customizable (for example leave out old branches etc); '''should'''
#** Import from CVS needs to be doable in days during final migration phase; '''must'''; OK for Subversion with fsfs backend; not OK for Subversion with bdb backend; not OK for Mercurial;
#* Performance:
#** The performance of common used operations (checkout, commit, log, merge) should not be significantly slower than CVS as presented by CN; '''must'''
#* Replication:
#** There needs to be a way to replicate the repository to save bandwidth; '''must'''
#* Binary files, LF/CR conversions
#** Proper handling of binary files; '''must'''; OK for Subversion;
#** LF/CR conversions; '''should'''; OK for Subversion;
#* admin access for deletion, move
#* functionality similar to cvsup, anoncvs, viewcvs, notification mails; '''must'''
#* simple permission system; '''should'''
#* Sudo root access for selected admins; '''should'''
#* Functionality similar to bonsai, lxr, fisheye / CIA etc.; '''should'''
#Bugtracking
#* Number of issues inside OOo:
#** total 82600 (closed 57693)
#** number of distinct submitters: 18500
#** number of distinct assignees: 1600
#** number of attached files: 49000
#* States:
#** ASSIGNED, CLOSED, NEW, REOPEN, RESOLVED, STARTED, UNCONFIRMED, VERIFIED; '''must'''
#* Resolution:
#** DUPLICATE, FIXED, INVALID, LATER, REMIND, WONTFIX, WORKSFORME; '''must''' (Further details about the workflow and the relationship between State and Resolution http://www.openoffice.org/scdocs/issue_lifecycle.html)
#* Types:
#** DEFECT, ENHANCEMENT, FEATURE, PATCH, TASK; '''must''' (may be PATCH can be dropped later -> Was a request for CollabNet)
#* Additional fields and values:
#* Import- and export of data:
#** XML; '''must'''
#** remove export as 'Word'/'Excel'; '''must'''
#* Attachments:
#** Possibility to attach any type of file to the issue, eg. OpenOffice.org documents, pictures, source code, source code patches; '''must'''
#* Keywords:
#** List of Keywords or tags to assign to issues as a method to organize QA work; '''must'''
#* central configuration; '''must'''
#* Email-notification of modified issues; '''must'''
#* One issue-tracking instance for more than one project; '''must'''
# Wiki (CMS)
#* MediaWiki, version ? ; '''should'''
#* Required extensions/features:
#** DisplayTitle feature ; '''must''' for Docs
#** DynamicPageList; '''should'''
#** Syntax Highlighter (GeSHi) ; '''must''' for Docs
#** Breadcrumbs ; '''must''' for Docs
#** Hierarchical pages ; '''must''' for Docs;
#** Category Tree; '''should'''
#** wfGFlashExtension; '''should'''
#** wfLabeledSectionTransclusion ; '''must''' for Docs
#** Parser extensions (own implementation) ; '''must''' for Docs
#* Possibility of installing own extensions ; '''must'''
#* Number of categories: 200
#* Number of pages: 7723 within 2000 content pages (Docs will soon increase this number by 900 (DevGuide) and possibly another 2,000 (Help)
#* Number of uploaded files: 2200
#* Number of edit/day: 7
#* Number of users: 10181 Further details http://wiki.services.openoffice.org/wiki/Special:Statistics
#* allow branding; '''must'''
#* localized UI; '''should'''
#* versioned; '''must'''
#* namespaces; '''must'''
#* reuse of content (templates, server-side-include); '''must'''
#* publication routes for wiki-based documentation (ODF/PDF); '''should'''
#* localization of wiki-based content; '''should'''
# Mailing Lists
#* Types:
#**unmoderated;open to anyone(mostly unused at collab); '''must'''
#**discuss;subcribed users Post/Read allowed,archive Read allowed others moderated (most common); '''must'''
#**moderated;Post always moderated; Read archive; '''must'''
#**allowed poster:
#**domain wide allowed poster:
#**sublist;subcribed to another List; gathering global Information eg; issues@<project>.openoffice.org to ML issues@openoffice; '''must'''
#* non-site-member subscription (external archives); '''must'''
#* Archiving; '''must'''
#* Toplevel mailinglists: allcvs@openoffice.org; '''must'''
#* migrating current Archives; '''must'''
#* round about 850 Mailinglists with different types to migrate; '''must'''
#* SPAM / Virus protected (Important especially for agenda@council.openoffice.org. See "Comm b/w CC and CMs" below); '''must'''
#* [RSS] for easy syndication of new from various parts of the site, including the home page and mac port pages.; '''should'''
#* webbased forums; '''should'''
#* NNTP; '''must'''
#* attachment stripping; '''must'''
#* customizable headers, footers, robot replies; '''must'''
# Audit
# Communication between Community Council and Community Members
#* Protect [http://council.openoffice.org/servlets/BrowseList?listName=agenda&by=date&from=2007-10-01&to=2007-10-31&first=1&count=22 agenda@council.openoffice.org] against spams and make it easy-to-post and easy-to-find community-proposals which should not be buried in spams.
#* Additional infrastructure where CC can listen to contributors, developers and other Community members and talk with them daily.
# L10n and T9n for about 100 languages
#* Storage for:
#** Pootle
#** translation memories
#** glossaries
#** KeyID builds
#** extensions translation process
#** documentation translation process
#* Management tools

== Unprioritized List ==

* localization of UI parts (bugtracking, webpages, ...) and process for new locales
* reporting / stats / logfiles
* Search via Google, Yahoo, ...
* mail forwarding (xxx@openoffice.org)
* IP / domain blocking
* blog / planet
* download, documents & files structured in folders
* surveys / votes / polls
* general open-ness for integration of scripting (PHP, Perl, ...)
* MySQL databases
* provide SSL logon for security reasons
* rise the limit for mail attachments from 2 MB to 10 MB

== Migration process ==
* public access to the staging server

== Key Numbers ==

Per day the main site (actually the accelerators) receives 4-6M hits / 100,000 - 150,000 visits and sends 40-60GB. In peaks like the OpenOffice.org 2.0 launch there were > 16M hits per day with more than 400,000 visits.

The mail server has to be prepared to handle 50 msg/sec and 300 parallel sessions when the rising tide flows in.

== See also ==
* [[Infrastructure_Overview]]
* [[Infrastructure_Problems]]

[[Category:Website]]

Infrastructure Requirements

2007-11-27T16:04:38Z

Jj:

The following list contains the major functionalities expected from the
OpenOffice.org infrastructure. The bullet points have been collected with focus on
software developerment but are also applicable for the user oriented needs.

== Prioritized Item List ==

# Framework / Core
#* lightweight role / user administration / SSH key management [incl. authorization / authentication interfaces for cmdline / web based apps] (e.g. LDAP directory, could be placed on the SVN/CVS server)
#* SubProjects and SubProject Categories:
#** The OpenOffice.org project is being organized into different SubProjects having their own DNS entries for WebSpace and Mailinglists eg. xml.openoffice.org; '''must'''; see also DNS
#** Subprojects are classified into the 3 subproject catagories Accepted Project, Incubator Project, Native Language Project; '''must'''
#** Access rights configurable for individual Subprojects; '''must'''
#** A Domain Developer role gives access rights to all subprojects of the openoffice.org project; '''must'''
#** documents and files feature per subproject where documents can be uploaded; reserved; edited etc.; '''must'''
#** search feature - search in all OpenOffice.org subprojects or inside current OpenOffice.org subproject; '''must'''
#** project announcements; '''should'''
#* Sign-on
#** Single sign-on across the different applications; '''must'''
#** API to enable third-party applications to use the single sign-on; '''must'''
#* Site Search
#** covering web pages, issues, mailing lists; '''must'''
#** no of pages: ~450k
# DNS
#* Required Domain Name Service DNS Entries:
#** DNS Records for SubProjects of openoffice.org eg. gsl.openoffice.org, api.openoffice.org, tools.openoffice.org, de.openoffice.org. This includes Entries for Native Language Communities for example de.openoffice.org. All entries must have IP Address under which the sub-projects web content is being served and also MX records for the projects mailing lists.; '''must'''
#** DNS Entry for SubDomain services.openoffice.org in control of DNS Server operated by StarOffice department, for tools like the Environment Information System (EIS); '''must'''
#** DNS Entry for download.openoffice.org serving own web content; '''must'''
#** DNS Entry for support.openoffice.org serving own web content; '''must'''
#** DNS Entry for contributing.openoffice.org serving own web content; '''must'''
#** DNS Entry for about.openoffice.org serving own web content; '''must'''
# Web pages
#* subprojects need own DNS entries, see DNS; '''must'''; external sites contain links to web content of subprojects which we would otherwise break
#* special purpose web pages on own website (download, support, contributing, about), see DNS; '''must'''; If not otherwise possible these may be configured as individual subprojects but it´s preferable to have the www.openoffice.org main site plus these special sites belong to just one subproject named website where content developers can join.
#* Navigation Bar on top available to all sub-projects and special purpose websites; '''must'''
#* Navigation Bar left, project specific; '''must'''
#* global info boxes on right side of MyPage, with eg. Community Council Announcements, Download section
#* project specific announcements on MyPage; '''must'''
#** Default Content of left navigation bar per subproject but overrideable per subdirectory; '''must'''
#** Migration for files specifying content of left navigation bar in subdirectories; '''nice to have'''
#** Content modification:
#* all webpages in the repository are automatically surrounded by standard header (including login possibility, logo and top navigation bar), procject/directory specific left navigation bar and standard footer (including eg. copyright information); '''must'''
#* possibility to get HTML pages without the surrounding navigation, header and footer content via /nonav/ in URL; '''must'''
# Version Control System for source code [For web publishing and documentation see CMS.] [Some time ago we created a requirements list for a new OpenOffice.org SCM system. This can be found here: http://wiki.services.openoffice.org/wiki/SCM_Requirements.] The most important ones (distilled from the mentioned list):
#* Clients:
#** Clients must be available for all our supported platforms; '''must'''; OK for Subversion
#* Branches:
#** SCM system needs to easily support a multitude of branches; '''must'''; OK for Subversion; not supported for Mercurial
#** Merge tracking should be either available or can be implemented by hand; '''must'''; OK for Subversion;
#* Authentication:
#** Passwords must be securely transmitted to prevent malicious commits; '''must'''
#* Import:
#** Import from CVS needs to be history preserving; '''must'''
#** Import from CVS should be customizable (for example leave out old branches etc); '''should'''
#** Import from CVS needs to be doable in days during final migration phase; '''must'''; OK for Subversion with fsfs backend; not OK for Subversion with bdb backend; not OK for Mercurial;
#* Performance:
#** The performance of common used operations (checkout, commit, log, merge) should not be significantly slower than CVS as presented by CN; '''must'''
#* Replication:
#** There needs to be a way to replicate the repository to save bandwidth; '''must'''
#* Binary files, LF/CR conversions
#** Proper handling of binary files; '''must'''; OK for Subversion;
#** LF/CR conversions; '''should'''; OK for Subversion;
#* admin access for deletion, move
#* functionality similar to cvsup, anoncvs, viewcvs, notification mails; '''must'''
#* simple permission system; '''should'''
#* Sudo root access for selected admins; '''should'''
#* Functionality similar to bonsai, lxr, fisheye / CIA etc.; '''should'''
#Bugtracking
#* Number of issues inside OOo:
#** total 82600 (closed 57693)
#** number of distinct submitters: 18500
#** number of distinct assignees: 1600
#** number of attached files: 49000
#* States:
#** ASSIGNED, CLOSED, NEW, REOPEN, RESOLVED, STARTED, UNCONFIRMED, VERIFIED; '''must'''
#* Resolution:
#** DUPLICATE, FIXED, INVALID, LATER, REMIND, WONTFIX, WORKSFORME; '''must''' (Further details about the workflow and the relationship between State and Resolution http://www.openoffice.org/scdocs/issue_lifecycle.html)
#* Types:
#** DEFECT, ENHANCEMENT, FEATURE, PATCH, TASK; '''must''' (may be PATCH can be dropped later -> Was a request for CollabNet)
#* Additional fields and values:
#* Import- and export of data:
#** XML; '''must'''
#** remove export as 'Word'/'Excel'; '''must'''
#* Attachments:
#** Possibility to attach any type of file to the issue, eg. OpenOffice.org documents, pictures, source code, source code patches; '''must'''
#* Keywords:
#** List of Keywords or tags to assign to issues as a method to organize QA work; '''must'''
#* central configuration; '''must'''
#* Email-notification of modified issues; '''must'''
#* One issue-tracking instance for more than one project; '''must'''
# Wiki (CMS)
#* MediaWiki, version ? ; '''should'''
#* Required extensions/features:
#** DisplayTitle feature ; '''must''' for Docs
#** DynamicPageList; '''should'''
#** Syntax Highlighter (GeSHi) ; '''must''' for Docs
#** Breadcrumbs ; '''must''' for Docs
#** Hierarchical pages ; '''must''' for Docs;
#** Category Tree; '''should'''
#** wfGFlashExtension; '''should'''
#** wfLabeledSectionTransclusion ; '''must''' for Docs
#** Parser extensions (own implementation) ; '''must''' for Docs
#* Possibility of installing own extensions ; '''must'''
#* Number of categories: 200
#* Number of pages: 7723 within 2000 content pages (Docs will soon increase this number by 900 (DevGuide) and possibly another 2,000 (Help)
#* Number of uploaded files: 2200
#* Number of edit/day: 7
#* Number of users: 10181 Further details http://wiki.services.openoffice.org/wiki/Special:Statistics
#* allow branding; '''must'''
#* localized UI; '''should'''
#* versioned; '''must'''
#* namespaces; '''must'''
#* reuse of content (templates, server-side-include); '''must'''
#* publication routes for wiki-based documentation (ODF/PDF); '''should'''
#* localization of wiki-based content; '''should'''
# Mailing Lists
#* Types:
#**unmoderated;open to anyone(mostly unused at collab); '''must'''
#**discuss;subcribed users Post/Read allowed,archive Read allowed others moderated (most common); '''must'''
#**moderated;Post always moderated; Read archive; '''must'''
#**allowed poster:
#**domain wide allowed poster:
#**sublist;subcribed to another List; gathering global Information eg; issues@<project>.openoffice.org to ML issues@openoffice; '''must'''
#* non-site-member subscription (external archives); '''must'''
#* Archiving; '''must'''
#* Toplevel mailinglists: allcvs@openoffice.org; '''must'''
#* migrating current Archives; '''must'''
#* round about 850 Mailinglists with different types to migrate; '''must'''
#* SPAM / Virus protected (Important especially for agenda@council.openoffice.org. See "Comm b/w CC and CMs" below); '''must'''
#* [RSS] for easy syndication of new from various parts of the site, including the home page and mac port pages.; '''should'''
#* webbased forums; '''should'''
#* NNTP; '''must'''
#* attachment stripping; '''must'''
#* customizable headers, footers, robot replies; '''must'''
# Audit
# Communication between Community Council and Community Members
#* Protect [http://council.openoffice.org/servlets/BrowseList?listName=agenda&by=date&from=2007-10-01&to=2007-10-31&first=1&count=22 agenda@council.openoffice.org] against spams and make it easy-to-post and easy-to-find community-proposals which should not be buried in spams.
#* Additional infrastructure where CC can listen to contributors, developers and other Community members and talk with them daily.
# L10n and T9n for about 100 languages
#* Storage for:
#** Pootle
#** translation memories
#** glossaries
#** KeyID builds
#** extensions translation process
#** documentation translation process
#* Management tools

== Unprioritized List ==

* localization of UI parts (bugtracking, webpages, ...) and process for new locales
* reporting / stats / logfiles
* Search via Google, Yahoo, ...
* mail forwarding (xxx@openoffice.org)
* IP / domain blocking
* blog / planet
* download, documents & files structured in folders
* surveys / votes / polls
* general open-ness for integration of scripting (PHP, Perl, ...)
* MySQL databases
* provide SSL logon for security reasons
* rise the limit for mail attachments from 2 MB to 10 MB

== Key Numbers ==

Per day the main site (actually the accelerators) receives 4-6M hits / 100,000 - 150,000 visits and sends 40-60GB. In peaks like the OpenOffice.org 2.0 launch there were > 16M hits per day with more than 400,000 visits.

The mail server has to be prepared to handle 50 msg/sec and 300 parallel sessions when the rising tide flows in.

== See also ==
* [[Infrastructure_Overview]]
* [[Infrastructure_Problems]]

[[Category:Website]]

Infrastructure Requirements

2007-11-27T09:31:13Z

Jj: Major rework of the prioritized item list

The following list contains the major functionalities expected from the
OpenOffice.org infrastructure. The bullet points have been collected with focus on
software developerment but are also applicable for the user oriented needs.

== Prioritized Item List ==

# Framework / Core
#* lightweight role / user administration / SSH key management [incl. authorization / authentication interfaces for cmdline / web based apps] (e.g. LDAP directory, could be placed on the SVN/CVS server)
#* SubProjects and SubProject Categories:
#** The OpenOffice.org project is being organized into different SubProjects having their own DNS entries for WebSpace and Mailinglists eg. xml.openoffice.org; '''must'''; see also DNS
#** Subprojects are classified into the 3 subproject catagories Accepted Project, Incubator Project, Native Language Project; '''must'''
#** Access rights configurable for individual Subprojects; '''must'''
#** A Domain Developer role gives access rights to all subprojects of the openoffice.org project; '''must'''
#** documents and files feature per subproject where documents can be uploaded; reserved; edited etc.; '''must'''
#** search feature - search in all OpenOffice.org subprojects or inside current OpenOffice.org subproject; '''must'''
#** project announcements; '''should'''
#* Sign-on
#** Single sign-on across the different applications; '''must'''
#** API to enable third-party applications to use the single sign-on; '''must'''
#* Site Search
#** covering web pages, issues, mailing lists; '''must'''
#** no of pages: ~450k
# DNS
#* Required Domain Name Service DNS Entries:
#** DNS Records for SubProjects of openoffice.org eg. gsl.openoffice.org, api.openoffice.org, tools.openoffice.org, de.openoffice.org. This includes Entries for Native Language Communities for example de.openoffice.org. All entries must have IP Address under which the sub-projects web content is being served and also MX records for the projects mailing lists.; '''must'''
#** DNS Entry for SubDomain services.openoffice.org in control of DNS Server operated by StarOffice department, for tools like the Environment Information System (EIS); '''must'''
#** DNS Entry for download.openoffice.org serving own web content; '''must'''
#** DNS Entry for support.openoffice.org serving own web content; '''must'''
#** DNS Entry for contributing.openoffice.org serving own web content; '''must'''
#** DNS Entry for about.openoffice.org serving own web content; '''must'''
# Web pages
#* subprojects need own DNS entries, see DNS; '''must'''; external sites contain links to web content of subprojects which we would otherwise break
#* special purpose web pages on own website (download, support, contributing, about), see DNS; '''must'''; If not otherwise possible these may be configured as individual subprojects but it´s preferable to have the www.openoffice.org main site plus these special sites belong to just one subproject named website where content developers can join.
#* Navigation Bar on top available to all sub-projects and special purpose websites; '''must'''
#* Navigation Bar left, project specific; '''must'''
#* global info boxes on right side of MyPage, with eg. Community Council Announcements, Download section
#* project specific announcements on MyPage; '''must'''
#** Default Content of left navigation bar per subproject but overrideable per subdirectory; '''must'''
#** Migration for files specifying content of left navigation bar in subdirectories; '''nice to have'''
#** Content modification:
#* all webpages in the repository are automatically surrounded by standard header (including login possibility, logo and top navigation bar), procject/directory specific left navigation bar and standard footer (including eg. copyright information); '''must'''
#* possibility to get HTML pages without the surrounding navigation, header and footer content via /nonav/ in URL; '''must'''
# Version Control System for source code [For web publishing and documentation see CMS.] [Some time ago we created a requirements list for a new OpenOffice.org SCM system. This can be found here: http://wiki.services.openoffice.org/wiki/SCM_Requirements.] The most important ones (distilled from the mentioned list):
#* Clients:
#** Clients must be available for all our supported platforms; '''must'''; OK for Subversion
#* Branches:
#** SCM system needs to easily support a multitude of branches; '''must'''; OK for Subversion; not supported for Mercurial
#** Merge tracking should be either available or can be implemented by hand; '''must'''; OK for Subversion;
#* Authentication:
#** Passwords must be securely transmitted to prevent malicious commits; '''must'''
#* Import:
#** Import from CVS needs to be history preserving; '''must'''
#** Import from CVS should be customizable (for example leave out old branches etc); '''should'''
#** Import from CVS needs to be doable in days during final migration phase; '''must'''; OK for Subversion with fsfs backend; not OK for Subversion with bdb backend; not OK for Mercurial;
#* Performance:
#** The performance of common used operations (checkout, commit, log, merge) should not be significantly slower than CVS as presented by CN; '''must'''
#* Replication:
#** There needs to be a way to replicate the repository to save bandwidth; '''must'''
#* Binary files, LF/CR conversions
#** Proper handling of binary files; '''must'''; OK for Subversion;
#** LF/CR conversions; '''should'''; OK for Subversion;
#* admin access for deletion, move
#* functionality similar to cvsup, anoncvs, viewcvs, notification mails; '''must'''
#* simple permission system; '''should'''
#* Sudo root access for selected admins; '''should'''
#* Functionality similar to bonsai, lxr, fisheye / CIA etc.; '''should'''
#Bugtracking
#* Number of issues inside OOo:
#** total 82600 (closed 57693)
#** number of distinct submitters: 18500
#** number of distinct assignees: 1600
#** number of attached files: 49000
#* States:
#** ASSIGNED, CLOSED, NEW, REOPEN, RESOLVED, STARTED, UNCONFIRMED, VERIFIED; '''must'''
#* Resolution:
#** DUPLICATE, FIXED, INVALID, LATER, REMIND, WONTFIX, WORKSFORME; '''must''' (Further details about the workflow and the relationship between State and Resolution http://www.openoffice.org/scdocs/issue_lifecycle.html)
#* Types:
#** DEFECT, ENHANCEMENT, FEATURE, PATCH, TASK; '''must''' (may be PATCH can be dropped later -> Was a request for CollabNet)
#* Additional fields and values:
#* Import- and export of data:
#** XML; '''must'''
#** remove export as 'Word'/'Excel'; '''must'''
#* Attachments:
#** Possibility to attach any type of file to the issue, eg. OpenOffice.org documents, pictures, source code, source code patches; '''must'''
#* Keywords:
#** List of Keywords or tags to assign to issues as a method to organize QA work; '''must'''
#* central configuration; '''must'''
# Wiki (CMS)
#* MediaWiki, version ? ; '''should'''
#* Required extensions/features:
#** DisplayTitle feature ; '''must''' for Docs
#** DynamicPageList; '''should'''
#** Syntax Highlighter (GeSHi) ; '''must''' for Docs
#** Breadcrumbs ; '''must''' for Docs
#** Hierarchical pages ; '''must''' for Docs;
#** Category Tree; '''should'''
#** wfGFlashExtension; '''should'''
#** wfLabeledSectionTransclusion ; '''must''' for Docs
#** Parser extensions (own implementation) ; '''must''' for Docs
#* Possibility of installing own extensions ; '''must'''
#* Number of categories: 200
#* Number of pages: 7723 within 2000 content pages (Docs will soon increase this number by 900 (DevGuide) and possibly another 2,000 (Help)
#* Number of uploaded files: 2200
#* Number of edit/day: 7
#* Number of users: 10181 Further details http://wiki.services.openoffice.org/wiki/Special:Statistics
#* allow branding; '''must'''
#* localized UI; '''should'''
#* versioned; '''must'''
#* namespaces; '''must'''
#* reuse of content (templates, server-side-include); '''must'''
#* publication routes for wiki-based documentation (ODF/PDF); '''should'''
#* localization of wiki-based content; '''should'''
# Mailing Lists
#* Types:
#**unmoderated;open to anyone(mostly unused at collab); '''must'''
#**discuss;subcribed users Post/Read allowed,archive Read allowed others moderated (most common); '''must'''
#**moderated;Post always moderated; Read archive; '''must'''
#**allowed poster:
#**domain wide allowed poster:
#**sublist;subcribed to another List; gathering global Information eg; issues@<project>.openoffice.org to ML issues@openoffice; '''must'''
#* non-site-member subscription (external archives); '''must'''
#* Archiving; '''must'''
#* Toplevel mailinglists: allcvs@openoffice.org; '''must'''
#* migrating current Archives to bbc; '''must'''
#* round about 850 Mailinglists with different types to migrate; '''must'''
#* SPAM / Virus protected (Important especially for agenda@council.openoffice.org. See "Comm b/w CC and CMs" below); '''must'''
#* [RSS] for easy syndication of new from various parts of the site, including the home page and mac port pages.; '''should'''
#* webbased forums; '''should'''
#* NNTP; '''must'''
#* attachment stripping; '''must'''
#* customizable headers, footers, robot replies; '''must'''
# Audit
# Communication between Community Council and Community Members
#* Protect [http://council.openoffice.org/servlets/BrowseList?listName=agenda&by=date&from=2007-10-01&to=2007-10-31&first=1&count=22 agenda@council.openoffice.org] against spams and make it easy-to-post and easy-to-find community-proposals which should not be buried in spams.
#* Additional infrastructure where CC can listen to contributors, developers and other Community members and talk with them daily.
# L10n and T9n for about 100 languages
#* Storage for:
#** Pootle
#** translation memories
#** glossaries
#** KeyID builds
#** extensions translation process
#** documentation translation process
#* Management tools

== Unprioritized List ==

* localization of UI parts (bugtracking, webpages, ...) and process for new locales
* reporting / stats / logfiles
* Search via Google, Yahoo, ...
* mail forwarding (xxx@openoffice.org)
* IP / domain blocking
* blog / planet
* download, documents & files structured in folders
* surveys / votes / polls
* general open-ness for integration of scripting (PHP, Perl, ...)
* MySQL databases
* provide SSL logon for security reasons
* rise the limit for mail attachments from 2 MB to 10 MB

== Key Numbers ==

Per day the main site (actually the accelerators) receives 4-6M hits / 100,000 - 150,000 visits and sends 40-60GB. In peaks like the OpenOffice.org 2.0 launch there were > 16M hits per day with more than 400,000 visits.

The mail server has to be prepared to handle 50 msg/sec and 300 parallel sessions when the rising tide flows in.

== See also ==
* [[Infrastructure_Overview]]
* [[Infrastructure_Problems]]

[[Category:Website]]

OOoRelease24

2007-11-15T09:52:21Z

Jj: updated Translation start date due to "Feature Freeze OOo 2.4" announcement on releases@ooo

== OpenOffice.org 2.4 ==

* November 15th 2007: UI and [[Feature_freeze]]
* November 29th 2007: [[Translation for 2.4|Translation update 2.4]] start
* December 13th 2007: Translation update 2.4 delivery
* December 20th 2007: TCM l10n testing
* January 17th 2008: [[code_freeze]]
* February 7th 2008: [[Last cws integration]] for fixes
* February 21th 2008: release candidate for all languages
* March 4th 2008: OpenOffice.org 2.4 release

{{OOo Releases}}

[[Category:Releases]]

Steps towards regular automated regression testing

2007-06-01T07:29:20Z

Jj: /* Current pitfalls for regular regression testing */

== Current state ==

Automated testing with [[TestTool]] at the moment has several [http://qa.openoffice.org/ooQAReloaded/AutomationTeamsite/ooQA-TeamAutomationTestlist.html sets of test cases] available which are used for testing on Master Workspaces ([[MWS]]s) or Child Workspaces ([[CWS]]s). The tests on the MWS are used as a reference when testing a CWS derived from this MWS, so that it can be determined whether a bug found by means of an automated test was introduced on the CWS or on the MWS. Our current Master Workspaces, be it SRC680 or OOF680, do by no means succeed with all automated tests. Instead there are always some tests which fail. For such failed tests bugs are created within [[Issue Tracker]]. These are treated as normal bugs so that sooner or later they are fixed and the test works again.

== Current pitfalls for regular regression testing ==

When a [[QA]] engineer or developer wants to do some more automated regression tests for a CWS than the [[SmokeTest]] offers, he does encounter several problems:

# As some tests also fail on the Master Workspace the tester has to check whether a failed test was newly introduced by the CWS or whether it already existed on the [[ReleaseMilestone]] his CWS is based on. If automated testing was done for this milestone or if at least an installation set for this milestone is still available then this check can be done with acceptable effort. If neither is available it is rather difficult to find out where the bug was introduced.
# Too many hands work on a CWS which have not run enough automated tests. Often the automated test scripts run parallel to manual testing. Sometimes they need to do that testing more than once because an automated test reported a defect.
# Too many different test environments sometimes report on some '''functional tests''' different results. This means that if a test fails, which did not fail on the corresponding MWS, it does not always mean that a new bug was introduced. Instead it might be that a new test run finishes without this error.
# If all existing test cases are run, the whole test cycle takes a few days - far too much to do this on every CWS. But reduced sets exist that run overnight.

== What does this mean for the quality of OpenOffice.org? ==

The effect of the above pitfalls is that it is quite hard for a developer to do extended regression testing for his CWSs. If he feels that the changes he made on his CWS should be verified by automated testing, he will usually try to get hold of one of the test automators - a limited resource, especially when we are in the middle of an OOo release. Even the QA representative for the CWS will in many cases not be able to run more than a few basic automated tests as the effort to run a larger set is too high for him.

So we have to rely on the SmokeTest, the normal testing done by the developer and testers, and those automated tests the few test automators are able to do, to ensure the quality of the CWSs. But there is room for more. If we were able to do more automated tests then we could find some more bugs early, before they get into the codeline and the product and thus create OOo releases in an even better quality...

== A possible way out ==

To enable automated tests on every CWS we would have to eliminate the above two problems. So a tester encountering a failed test during automated testing should not be required to check whether the bug was really introduced on the CWS and he should be certain that a failed test means that a bug exists and not have to retry the test again to be sure. Additionally the tests should run in an acceptable time i.e. a few hours at the most.

# The CWSs gh13 (already introduced) and gh14 are supposed to improve the usability and the speed of the TestTool.
# With a small set of tests being used, which always run safely and deterministic and with the tests being finished within a few hours (we might add more tests later), that leaves us with the problem of having to check whether all those failed tests were introduced with the CWS or whether they existed on the MWS.

These checks - at least at the moment - take the most time for the test automators. They could be eliminated if the MWS were always free of bugs that cause automated tests to fail. Then a failed test would automatically mean that the corresponding bug was introduced with the new CWS - no need to check the MWS. A failed test then always means that a bug was introduced with the CWS.

But how to ensure that the MWS stays free of bugs that cause the automated tests to fail?
# It looks like we would have to make the automated tests, at least a certain set, mandatory for every CWS. Otherwise, sooner or later, via some CWSs bugs would again be introduced that cause the automated tests to fail. So for every CWS the owner or the QA representative would have to run the automated tests. Ideally the test run would send the information whether the tests all succeeded directly to the [[EIS]] tool. Approval of a CWS would then require the tests to be successfully run. That way we should be able to ensure that the automated tests don't get "corrupted" on the MWS. If - for whatever reason - we would indeed later detect a failed test on the MWS, then this would cause a P1 bug that would have to be fixed with the milestone before making it ready for usage, or on the next milestone if a fix is not possible in acceptable time. A milestone containing such a bug should not be used for CWS creation and CWSs already having been created on it should be resynced to the next milestone.
# If a CWS is introducing changes which affect the selected automated tests the automator need to make the changes at the same time as the CWS is in development, Both changes have to integrated at the same time to the versiong systems (CVS).

== Open questions ==

Automatic testing on the MWS for each milestone might postpone the time when the milestone is ready for usage compared to now. This ranges from a few hours for pure testing to whole days in case of real regressions which have to get fixed. Is this acceptable?

Running automated tests that take several hours to run requires hardware to run the tests on. Do we need separate hardware to run the tests, or should this be done on the machines where the developers do the builds? Is the additional required machine time acceptable at all?

Is it possible to integrate such testing into tinderbox builds?

What platforms are required for the automated tests? Does one platform suffice? Should the developer have freedom to determine the necessary platforms and e.g. normally run the tests on Windows & Linux but be able to say that one platform is sufficient if he can safely say that his changes should not affect other platforms?

Changes in the UI might make it necessary to adapt a corresponding test case. This requires some work from the QA engineers responsible for creating automated tests, who then might become the bottleneck. This might be mitigated by informing the automated tester early during CWS development. Do we accept this potential increase in development time?

How does this all relate to unit test? From time to time there are efforts to push usage of unit tests or even make them mandatory, for the same reasons as given here.

== A vision of a future with regular regression testing ==

The following is a "vision" of an idealized future where we do more regression testing via automated tests:

''In the past few months the quality of OOo has significantly improved. A set of automated tests is now run on each and every CWS before it gets integrated, so that the quality of CWSs has improved further and thus the Master Workspace where OOo is released from.''

''Now, once the owner sets his CWS to the state "ready for QA", the QA representative (or the owner himself) triggers the run of the automated tests. This is quite easy for him as it is a simple command in his command shell. The tests then run while the tester does the normal manual testing on the CWS and is usually finished even before all normal tests are done, so that it costs little or no additional time. With the finished test, the test script also reports its state to the EIS application, so that it is easy for the QA representative to see whether the tests were successful. Without successful automated tests, nearly (*) no CWS nowadays gets integrated in the MWS. (There are exceptions for special cases like pure build fixes, cws tooling changes, and the like.)''

''The test automators now have much less effort with checking failed tests, as - at least for the mandatory set of tests for every CWS - the MWS is usually free of bugs in automated tests, so that there is no such effort at least for this part of the existing tests. This leaves them the necessary time to adapt tests to modified UI in CWSs and also a bit more time to develop new test cases. Now and then they also add a test case to the set of mandatory tests, so that this set of tests has slightly increased over the past weeks.''

--[[User:Jj|Jj]] 13:19, 10 May 2007 (CEST)

Steps towards regular automated regression testing

2007-05-15T07:49:45Z

Jj:

== Current state ==

Automated testing with [[TestTool]] at the moment has several [http://qa.openoffice.org/ooQAReloaded/AutomationTeamsite/ooQA-TeamAutomationTestlist.html sets of test cases] available which are used for testing on Master Workspaces ([[MWS]]s) or Child Workspaces ([[CWS]]s). The tests on the MWS are used as a reference when testing a CWS derived from this MWS, so that it can be determined whether a bug found by means of an automated test was introduced on the CWS or on the MWS. Our current Master Workspaces, be it SRC680 or OOF680, do by no means succeed with all automated tests. Instead there are always some tests which fail. For such failed tests bugs are created within [[Issue Tracker]]. These are treated as normal bugs so that sooner or later they are fixed and the test works again.

== Current pitfalls for regular regression testing ==

When a [[QA]] engineer or developer wants to do some more automated regression tests for a CWS than the [[SmokeTest]] offers, he does encounter several problems:

1. As some tests also fail on the Master Workspace the tester has to check whether a failed test was newly introduced by the CWS or whether it already existed on the [[ReleaseMilestone]] his CWS is based on. If automated testing was done for this milestone or if at least an installation set for this milestone is still available then this check can be done with acceptable effort. If neither is available it is rather difficult to find out where the bug was introduced.

2. The [[Testtool]] does not always work in a deterministic way. This means that if a test fails, which did not fail on the corresponding MWS, it does not always mean that a new bug was introduced. Instead it might be that a new test run finishes without this error. The reasons are different test environments or timing issues for some test cases.

3. If all existing test cases are run, the whole test cycle takes a few days - far too much to do this on every CWS. But reduced sets exist that run overnight.

== What does this mean for the quality of OpenOffice.org? ==

The effect of the above pitfalls is that it is quite hard for a developer to do extended regression testing for his CWSs. If he feels that the changes he made on his CWS should be verified by automated testing, he will usually try to get hold of one of the automated testers - a limited resource, especially when we are in the middle of an OOo release. Even the QA representative for the CWS will in many cases not be able to run more than a few basic automated tests as the effort to run a larger set is too high for him.

So we have to rely on the SmokeTest, the normal testing done by the developer and testers, and those automated tests the few automated testers are able to do, to ensure the quality of the CWSs. But there is room for more. If we were able to do more automated tests then we could find some more bugs early, before they get into the codeline and the product and thus create OOo releases in an even better quality...

== A possible way out ==

To enable automated tests on every CWS we would have to eliminate the above two problems. So a tester encountering a failed test during automated testing should not be required to check whether the bug was really introduced on the CWS and he should be certain that a failed test means that a bug exists and not have to retry the test again to be sure. Additionally the tests should run in an acceptable time i.e. a few hours at the most.

The CWSs gh13 and gh14 are supposed to improve the speed of the TestTool and also improve its deterministic behaviour. With a small set of tests being used, which always run safely and deterministic and with the tests being finished within a few hours (we might add more tests later), that leaves us with the problem of having to check whether all those failed tests were introduced with the CWS or whether they existed on the MWS.

These checks - at least at the moment - take the most time for the automated testers. They could be eliminated if the MWS were always free of bugs that cause automated tests to fail. Then a failed test would automatically mean that the corresponding bug was introduced with the new CWS - no need to check the MWS. A failed test then always means that a bug was introduced with the CWS.

But how to ensure that the MWS stays free of bugs that cause the automated tests to fail? It looks like we would have to make the automated tests, at least a certain set, mandatory for every CWS. Otherwise, sooner or later, via some CWSs bugs would again be introduced that cause the automated tests to fail. So for every CWS the owner or the QA representative would have to run the automated tests. Ideally the test run would send the information whether the tests all succeeded directly to the [[EIS]] tool. Approval of a CWS would then require the tests to be successfully run. That way we should be able to ensure that the automated tests don't get "corrupted" on the MWS. If - for whatever reason - we would indeed later detect a failed test on the MWS, then this would cause a P1 bug that would have to be fixed with the milestone before making it ready for usage, or on the next milestone if a fix is not possible in acceptable time. A milestone containing such a bug should not be used for CWS creation and CWSs already having been created on it should be resynced to the next milestone.

== Open questions ==

Automatic testing on the MWS for each milestone might postpone the time when the milestone is ready for usage by a few hours compared to now. Is this acceptable?

Running automated tests that take several hours to run requires hardware to run the tests on. Do we need separate hardware to run the tests, or should this be done on the machines where the developers do the builds? Is the additional required machine time acceptable at all?

What platforms are required for the automated tests? Does one platform suffice? Should the developer have freedom to determine the necessary platforms and e.g. normally run the tests on Windows & Linux but be able to say that one platform is sufficient if he can safely say that his changes should not affect other platforms?

Changes in the UI might make it necessary to adapt a corresponding test case. This requires some work from the QA engineers responsible for creating automated tests, who then might become the bottleneck. This might be mitigated by informing the automated tester early during CWS development. Do we accept this potential increase in development time?

== A vision of a future with regular regression testing ==

The following is a "vision" of an idealized future where we do more regression testing via automated tests:

''In the past few months the quality of OOo has significantly improved. A set of automated tests is now run on each and every CWS before it gets integrated, so that the quality of CWSs has improved further and thus the Master Workspace where OOo is released from.''

''Now, once the owner sets his CWS to the state "ready for QA", the QA representative (or the owner himself) triggers the run of the automated tests. This is quite easy for him as it is a simple command in his command shell. The tests then run while the tester does the normal manual testing on the CWS and is usually finished even before all normal tests are done, so that it costs little or no additional time. With the finished test, the test script also reports its state to the EIS application, so that it is easy for the QA representative to see whether the tests were successful. Without successful automated tests, no CWS nowadays gets integrated in the MWS.''

''The automated testers now have much less effort with checking failed tests, as - at least for the mandatory set of tests for every CWS - the MWS is usually free of bugs in automated tests, so that there is no such effort at least for this part of the existing tests. This leaves them the necessary time to adapt tests to modified UI in CWSs and also a bit more time to develop new test cases. Now and then they also add a test case to the set of mandatory tests, so that this set of tests has slightly increased over the past weeks.''

--[[User:Jj|Jj]] 13:19, 10 May 2007 (CEST)

OOoRelease22

2007-05-10T13:39:24Z

Jj: /* Release Plan for 2.2 release */

== OOo 2.2 ==

* UI and [[Feature_freeze]] : December 28th, 2006
* [[Translation for 2.2|Translation update 2.2]] start: January 4th, 2007
* Translation update 2.2 delivery: January 18th, 2007
* [[code_freeze]]: January 25th, 2007
* l10n CWS builds available: January 25th, 2007
* TCM l10n testing on CWS builds: January 25th - 31st
* pre release candidate (en_US only): February 1st, 2007
* [[Last cws integration]] for fixes: February 8th, 2007
* release candidate for all languages: February 22th, 2007
* Product release: March 28th, 2007

=== Release Plan for 2.2 release===

{| border = "1"
|-
! Task !! Who !! Deadline !! Comments
|-
! last cws integration for first RC / OOF680_m8
| mh, RE || || done
|-
! release notes
| mh, ja || || done for http://development.openoffice.org/releases/2.2.0rc4.html
|-
! Setup Guides
| || ||
|-
! Upload of RC builds
| ja || done for 2.2.0rc4 ||
full install sets for: en-US da de es fr it ja nl ko pl sv pt-BR zh-CN zh-TW

language packs for: en-US af as-IN be-BY bg br bs ca cs cy da de dz el en-GB en-ZA eo es et fa fi fr ga gl gu-IN he hi-IN hr hu it ja ka km ko ku lt mk ml-IN mr-IN nb ne nl nn nr ns or-IN pa-IN pl pt pt-BR ru rw sh-YU sk sl sr-CS ss st sv sw-TZ ta-IN te-IN tg th ti-ER tn tr ts uk ur-IN ve vi xh zh-CN zh-TW zu 
(same as for OOo 2.1 plus 'dz' and 'gl')
|-
! Trigger QA of final builds
| ja || || announcement of 2.2.0rc4 done
|-
! Track Status of localized builds
| ja || || 2.2.0rc4 builds added to http://qatrack.services.openoffice.org/view.php
|-
! Publish status of [http://qa.openoffice.org/qatesttool automated GUI testing]
| [[User:jsi|jsi]] || || [[OOoRelease22AutomationTestMatrix|http://wiki.services.openoffice.org/wiki/OOoRelease22AutomationTestMatrix]]
|-
! Update of 2.2 pages for RC
| ja || || http://download.openoffice.org/680/index.html
|-
! QA of English RC builds
| ja || || done for 2.2.0rc4
|-
! Update of SDK
| ja || || download available from ../contrib/rc/2.2.0rc4
|-
! Update of SDK Release Notes and update of redirect page http://download.openoffice.org/sdk.html
| jsc/ja || || done
|-
! Upload of src tarballs
| ja || || done for 2.2.0rc4
|-
! msg to announce@ooo content
| louis || || done
|-
! move RC to final
| ja || || done
|-
! download pages
| ja || || done
|-
! upload of solver tarballs
| ja || || tbd after 2.2 release
|-
! notification of mirrors
| ja || ||
|-
! Update of Bittorrents
| (mike!) || ||
|-
! Update of P2P page
| antbryan || ||
|-
! press kit update
| jpmcc/lsp || ||
|-
! press release/alert
| jpmcc, lsp || || http://wiki.services.openoffice.org/wiki/Press_release_2.2 - on timed release at PRWeb for March 29 PST ||
|-
! homepage
| louis || ||
|-
! release
| all || ||
|-
|}

== Next Release ==
* [[OOoRelease221]]

[[Category:Releases]]

OOoRelease221

2007-05-10T13:38:41Z

Jj: /* Release Plan for 2.2.1 release */

== OOo 2.2.1 ==

as discussed on releases we're going to introduce a bugfix release 2.2.1 end of May, begin of June (http://www.openoffice.org/servlets/BrowseList?list=releases&by=thread&from=1594200). We agreed on fixing only the important bugfixes only. We discussed this during the latest release status meeting (http://wiki.services.openoffice.org/wiki/ReleaseStatus_Minutes#2007-01-22) that all issues with target 2.2.1 needs to get reviewed by the Release status meeting.
"Important issue" means that the issue get considered as major regression to 2.2 release or has been defined as a "must have" by the release status meeting.
So the default target for regular defects is OOo 2.3 in this moment (--[[User:Mh|Mh]] 14:58, 25 January 2007 (CET))

* [[code_freeze]]: April 26th, 2007
* [[Last cws integration]] for fixes: May 10th, 2007
* release candidate for all languages: May 24th, 2007
* Product release: June 5th, 2007

=== Release Plan for 2.2.1 release===

{| border = "1"
|-
! Task !! Who !! Deadline !! Comments
|-
! last cws integration for first RC / OOF680_mxx
| mh, RE || ||
|-
! release notes
| mh, ja || ||
|-
! Setup Guides
| || ||
|-
! Upload of RC builds
| ja || || full install sets for: en-US da de es fr it ja nl ko pl ru sv pt-BR zh-CN zh-TW (same as for OOo 2.2 plus 'ru')

language packs for: en-US af as-IN be-BY bg br bs ca cs cy da de dz el en-GB en-ZA eo es et fa fi fr ga gl gu-IN he hi-IN hr hu it ja ka km ko ku lt mk ml-IN mr-IN nb ne nl nn nr ns or-IN pa-IN pl pt pt-BR rw sh-YU sk sl sr-CS ss st sv sw-TZ ta-IN te-IN tg th ti-ER tn tr ts uk ur-IN ve vi xh zh-CN zh-TW zu (same as for OOo 2.2 minus 'ru')
|-
! Trigger QA of final builds
| aschnabel || ||
|-
! Track Status of localized builds
| ja || || http://qatrack.services.openoffice.org/view.php
|-
! Update of 2.2.1 pages for RC
| ja || || http://download.openoffice.org/680/index.html
|-
! QA of English RC builds
| ja || ||
|-
! Update of SDK
| ja || ||
|-
! Update of SDK Release Notes and update of redirect page http://download.openoffice.org/sdk.html
| jsc/ja || ||
|-
! Upload of src tarballs
| ja || ||
|-
! msg to announce@ooo content
| louis || ||
|-
! move RC to final
| ja || ||
|-
! download pages
| ja || ||
|-
! upload of solver tarballs
| ja || ||
|-
! notification of mirrors
| ja || ||
|-
! Update of Bittorrents
| (mike!) || ||
|-
! Update of P2P page
| antbryan || ||
|-
! press kit update
| jpmcc/lsp || ||
|-
! press release/alert
| jpmcc, lsp || ||
|-
! homepage
| louis || ||
|-
! release
| all || ||
|-
|}

== Next Release ==
* [[OOoRelease23]]

[[Category:Releases]]

Steps towards regular automated regression testing

2007-05-10T11:19:38Z

Jj:

== Current state ==

Automated testing at the moment has several sets of test cases available which are used for testing on Master Workspaces ([[MWS]]s) or Child Workspaces ([[CWS]]s). The tests on the MWS are used as a reference when testing a CWS derived from this MWS, so that it can be determined whether a bug found by means of an automated test was introduced on the CWS or on the MWS. Our current Master Workspaces, be it SRC680 or OOF680, do by no means succeed with all automated tests. Instead there are always some tests which fail. For such failed tests bugs are created within [[Issue Tracker]]. These are treated as normal bugs so that sooner or later they are fixed and the test works again.

== Current pitfalls for regular regression testing ==

When a [[QA]] engineer or developer wants to do some more automated regression tests for a CWS than the [[SmokeTest]] offers, he does encounter several problems:

1. As some tests also fail on the Master Workspace the tester has to check whether a failed test was newly introduced by the CWS or whether it already existed on the [[ReleaseMilestone]] his CWS is based on. If automated testing was done for this milestone or if at least an installation set for this milestone is still available then this check can be done with acceptable effort. If neither is available it is rather difficult to find out where the bug was introduced.

2. The [[Testtool]] does not always work in a deterministic way. This means that if a test fails, which did not fail on the corresponding MWS, it does not always mean that a new bug was introduced. Instead it might be that a new test run finishes without this error. The reasons are e.g. timing issues for some test cases.

3. If all existing test cases are run, the whole test cycle takes a few days - far too much to do this on every CWS. But reduced sets exist that run overnight.

== What does this mean for the quality of OpenOffice.org? ==

The effect of the above pitfalls is that it is quite hard for a developer to do extended regression testing for his CWSs. If he feels that the changes he made on his CWS should be verified by automated testing, he will usually try to get hold of one of the automated testers - a limited resource, especially when we are in the middle of an OOo release. Even the QA representative for the CWS will in many cases not be able to run more than a few basic automated tests as the effort to run a larger set is too high for him.

So we have to rely on the SmokeTest, the normal testing done by the developer and testers, and those automated tests the few automated testers are able to do, to ensure the quality of the CWSs. But there is room for more. If we were able to do more automated tests then we could find some more bugs early, before they get into the codeline and the product and thus create OOo releases in an even better quality...

== A possible way out ==

To enable automated tests on every CWS we would have to eliminate the above two problems. So a tester encountering a failed test during automated testing should not be required to check whether the bug was really introduced on the CWS and he should be certain that a failed test means that a bug exists and not have to retry the test again to be sure. Additionally the tests should run in an acceptable time i.e. a few hours at the most.

The CWSs gh13 and gh14 are supposed to solve the problem of the TestTool not always running in a deterministic way and should improve the speed of the TestTool. With a small set of tests being used, so that the tests are finished within a few hours (we might add more tests later), that leaves us with the problem of having to check whether all those failed tests were introduced with the CWS or whether they existed on the MWS.

These checks - at least at the moment - take the most time for the automated testers. They could be eliminated if the MWS were always free of bugs that cause automated tests to fail. Then a failed test would automatically mean that the corresponding bug was introduced with the new CWS - no need to check the MWS. A failed test then always means that a bug was introduced with the CWS.

But how to ensure that the MWS stays free of bugs that cause the automated tests to fail? It looks like we would have to make the automated tests, at least a certain set, mandatory for every CWS. Otherwise, sooner or later, via some CWSs bugs would again be introduced that cause the automated tests to fail. So for every CWS the owner or the QA representative would have to run the automated tests. Ideally the test run would send the information whether the tests all succeeded directly to the [[EIS]] tool. Approval of a CWS would then require the tests to be successfully run. That way we should be able to ensure that the automated tests don't get "corrupted" on the MWS. If - for whatever reason - we would indeed later detect a failed test on the MWS, then this would cause a P1 bug that would have to be fixed with the milestone before making it ready for usage, or on the next milestone if a fix is not possible in acceptable time. A milestone containing such a bug should not be used for CWS creation and CWSs already having been created on it should be resynced to the next milestone.

== Open questions ==

Automatic testing on the MWS for each milestone might postpone the time when the milestone is ready for usage by a few hours compared to now. Is this acceptable?

Running automated tests that take several hours to run requires hardware to run the tests on. Do we need separate hardware to run the tests, or should this be done on the machines where the developers do the builds? Is the additional required machine time acceptable at all?

What platforms are required for the automated tests? Does one platform suffice? Should the developer have freedom to determine the necessary platforms and e.g. normally run the tests on Windows & Linux but be able to say that one platform is sufficient if he can safely say that his changes should not affect other platforms?

Changes in the UI might make it necessary to adapt a corresponding test case. This requires some work from the QA engineers responsible for creating automated tests, who then might become the bottleneck. This might be mitigated by informing the automated tester early during CWS development. Do we accept this potential increase in development time?

== A vision of a future with regular regression testing ==

The following is a "vision" of an idealized future where we do more regression testing via automated tests:

''In the past few months the quality of OOo has significantly improved. A set of automated tests is now run on each and every CWS before it gets integrated, so that the quality of CWSs has improved further and thus the Master Workspace where OOo is released from.''

''Now, once the owner sets his CWS to the state "ready for QA", the QA representative (or the owner himself) triggers the run of the automated tests. This is quite easy for him as it is a simple command in his command shell. The tests then run while the tester does the normal manual testing on the CWS and is usually finished even before all normal tests are done, so that it costs little or no additional time. With the finished test, the test script also reports its state to the EIS application, so that it is easy for the QA representative to see whether the tests were successful. Without successful automated tests, no CWS nowadays gets integrated in the MWS.''

''The automated testers now have much less effort with checking failed tests, as - at least for the mandatory set of tests for every CWS - the MWS is usually free of bugs in automated tests, so that there is no such effort at least for this part of the existing tests. This leaves them the necessary time to adapt tests to modified UI in CWSs and also a bit more time to develop new test cases. Now and then they also add a test case to the set of mandatory tests, so that this set of tests has slightly increased over the past weeks.''

--[[User:Jj|Jj]] 13:19, 10 May 2007 (CEST)

OOoRelease22

2007-01-17T17:20:38Z

Jj: /* Release Plan for 2.2 release */

== OOo 2.2 ==

* UI and [[Feature_freeze]] : December 28th, 2006
* [[Translation for 2.2|Translation update 2.2]] start: January 4th, 2007
* Translation update 2.2 delivery: January 18th, 2007
* [[code_freeze]]: January 25th, 2007
* l10n CWS builds available: January 25th, 2007
* TCM l10n testing on CWS builds: January 25th - 31st
* pre release candidate (en_US only): February 1st, 2007
* [[Last cws integration]] for fixes: February 8th, 2007
* release candidate for all languages: February 15th, 2007
* Product release: February 27th, 2007

=== Release Plan for 2.2 release===

{| border = "1"
|-
! Task !! Who !! Deadline !! Comments
|-
! last cws integration for first RC / SRC680_m1xx
| mh, RE || ||
|-
! release notes
| mh, ja || ||
|-
! Setup Guides
| || ||
|-
! Upload of RC builds
| ja || || (Draft)
full install sets for: en-US da de es fr it ja nl ko pl sv pt-BR zh-CN zh-TW

language packs for:
|-
! Trigger QA of final builds
| aschnabel || ||
|-
! Track Status of localized builds
| ja || || http://www.qatrack.org/ooo/view.php
|-
! Publish status of [http://qa.openoffice.org/qatesttool automated GUI testing]
| [[User:jsi|jsi]] || || [[OOoRelease1AutomationTestMatrix|http://wiki.services.openoffice.org/wiki/OOoRelease1AutomationTestMatrix]]
|-
! Update of 2.2 pages for RC
| ja || || http://download.openoffice.org/680/index.html
|-
! QA of English RC builds
| ja || ||
|-
! Update of SDK
| ja || ||
|-
! Update of SDK Release Notes and update of redirect page http://download.openoffice.org/sdk.html
| jsc/ja || ||
|-
! Upload of src tarballs
| ja || ||
|-
! msg to announce@ooo content
| louis || ||
|-
! move RC to final
| ja || ||
|-
! download pages
| ja || ||
|-
! upload of solver tarballs
| ja || ||
|-
! notification of mirrors
| ja || ||
|-
! Update of Bittorrents
| (mike!) || ||
|-
! Update of P2P page
| antbryan || ||
|-
! press kit update
| jpmcc/lsp || ||
|-
! press release/alert
| jpmcc, lsp || ||
|-
! homepage
| louis || ||
|-
! release
| all || ||
|-
|}

== Next Release ==
* [[OOoRelease221]]

[[Category:Quality Assurance]]

Buildbot

2006-12-19T14:46:28Z

Jj: /* Allocation */

A buildbot is now deployed for OpenOffice.org.
'''http://ooo-staging.osuosl.org:8010/'''

From the Buildbot README: http://buildbot.sourceforge.net/

Please see how you can '''[[Buildbot Steps | add your own buildbot]]!'''

Find out about the successor to the Buildbot, which is named [[Termite]].

The BuildBot is a system to automate the compile/test cycle required by most software projects to validate code changes. By automatically rebuilding and testing the tree each time something has changed, build problems are pinpointed quickly, before other developers are inconvenienced by the failure. The guilty developer can be identified and harassed without human intervention. By running the builds on a variety of platforms, developers who do not have the facilities to test their changes everywhere before checkin will at least know shortly afterwards whether they have broken the build or not. Warning counts, lint checks, image size, compile time, and other build parameters can be tracked over time, are more visible, and are therefore easier to improve.

== OpenOffice.org Buildbot ==
The Buildbot will:
* Build CWS/SVN branches on multiple platforms and make output available to developers
* Generate and make available install sets for multiple platforms
* Run tests (smoketest, performance tests, etc.) and make test reports available for tracking and regression.

== Buildbot vs. Tinderbox ==
Currently, there is a [[Tinderbox]]. In fact, the Buildbot uses or adapts several Tinderbox scripts. The Buildbot provides several advantages:
* At-a-glance, customizable statusboard
* Flexible, modular, extensible framework
* Bots can be commanded and coordinated from the botmaster

Both Buildbots and Tinderboxes are easy to setup and can be behind the firewall. Thanks to [[User:Cloph|Cloph]] for reminding about the similarities.

== Deployment & Hardware ==
Currently, the botmaster and several buildbots are hosted at OSU-OSL (http://osuosl.org). Additional machines will be added to the pool. Sun QA/RE plans to host a Solaris bot.

=== Allocation ===
Many buildbot based projects dedicate groups of bots to specific code branches. Thus, for example, checkins to HEAD will automatically trigger the associated pool of machines and the changes built, tested on multiple platforms. See for example: http://www.python.org/dev/buildbot/

However, this is impractical for OpenOffice.org due the numericity of branches (CWS'es). Instead, we focus on creating a reasonable sized pool of machines for each platform/variant, with flexible build policies (see below).

Currently, bots build for:
* debian
* suse 10.0
* suse 10.1 (jre and gij)
* suse 7.3 (several)
* windows xp (3+)
* Mac OS X Intel (X11)
* solaris 10 (sparc)
* solaris 10 (x86)

== Policies ==
The botmaster will schedule builds based on policies that take into account the pool size, machine status and build time. When a bot is busy doing a build, additional requests are automatically queued.

* At UTC 0200 + random() build HEAD
* At milestone release build milestone
* Build manually requested CWS or milestone
* Build automatically selected CWS

== Features ==
* When no CWS is provided --> checkout HEAD - '''Done'''
* Summaries - '''Done'''
** tail, warnings, errors, summary log like tinderbox
** error - show before/after buffer (15, 5) and skip ... between errors
* Deploy install-sets on bot-master - '''Done'''
* Increase length of status page. - '''Done'''
* Email notification of build result (fail, success, install, etc. with link to buildlogs)
** Send mail to requestor@openoffice.org when finished. (add a hint on the request form) - '''Done'''
** For CWS - send to CWS owner (from EIS)
* Fix smoke-test on some hosts
* CWS-Oriented View - '''Done'''
** Add header X axis (timeline)
** Three different views - all, ready for QA, new
* Buildslave info on slave web page
* Scheduler to prioritize and distribute builds on various slaves
** Collect changes by one user (settling) in one build
** AllCVS mailing list listener to auto trigger build on commit notification
* Header Row - provide number/link to last build (related to status)
* Extra config switches field in force build form. Developers can specify some extra configure switches specific to there CWSs. - '''Done'''
* Add suse 7.3 buildslave
* Generate buildbot results as RSS feed for planetizing
* For windows slaves, provide link to html build status page
* UserId/Password verification for force build and stop buid

== People ==
* Prasad Madhav (pmadhav) deployed and customizes the buildbot
* mikeleib, kaib, vq, dkeskar support and provide ideas

OOoRelease22

2006-09-25T11:00:34Z

Jj: /* OOo 2.2 */

== OOo 2.2 ==

* UI and [[Feature_freeze]] : January 4th, 2007
* Translation update 2.2 start: January 11th, 2007
* Translation update 2.2 delivery: January 18th, 2007
* [[code_freeze]]: January 25th, 2007
* l10n CWS builds available: January 25th, 2007
* TCM l10n testing on CWS builds: January 25th - 31st
* pre release candidate (en_US only): February 1st, 2007
* [[Last_cws_integration]] for fixes: February 8th, 2007
* release candidate for all languages: February 15th, 2007
* Product release: February 27th, 2007

[[Category:Quality Assurance]]

OOoRelease205

2006-09-06T11:52:03Z

Jj: /* OOo 2.1 (formerly known as 2.0.5) */

== OOo 2.1 (formerly known as 2.0.5) ==

* [[Feature_freeze]] : October 5th 2006
* Translation update 2.0.5 start: October 12th
* Translation update 2.0.5 delivery: October 26th, 2006
* [[code_freeze]]: November 2nd
* l10n CWS builds available: November 2nd
* pre release candidate (en_US only): November 9th 2006
* [[Last_cws_integration]] for fixes: November 16th 2006
* release candidate for all languages: November 23th 2006
* Product release: December 5th, 2006

[[Category:Quality Assurance]]