OpenSAF Technical Frequently Asked Questions

Mailing Lists

How do I join the OpenSAF users mailing list?

Instructions are on the OpenSAF  mailing list pages. This mailing list is used to discuss questions related to functionality, behavior and usage of OpenSAF.

How do I join the OpenSAF developers mailing list?

Instructions are on the OpenSAF  mailing list pages. This mailing list is used to discuss questions related to development of OpenSAF itself, or questions related to internal design of OpenSAF.

Contributing to OpenSAF

How can I contribute to the project?

The easiest way is to participate in the discussion on the OpenSAF users mailing list. You can subscribe to this list and other lists  here. You can also report bugs, propose enhancements or become a developer at OpenSAF (see below).

How do I report defects (bugs) to the project?

You can report defects by creating a ticket using the ticket creation tool provided by the  OpenSAF Developer's portal. While creating a ticket in summary start with the name of the module the ticket pertains to like for Availability Management Framework say "AMF: ...", for Checkpoint Service say "CKPT:..." etc. Give as much as information as is possible.

How do I propose enhancements to OpenSAF?

You can check the OpenSAF roadmap or list of active tickets on devel.opensaf.org to see if what you propose is already being worked on. The OpenSAF Development Process describes the process for proposing enhancements. This requires that you are an OpenSAF developer and have resources to implement the feature. If the enhancement is just an idea, feel free to post on the OpenSAF users mailing list.

How do I contribute bug fixes or new code to OpenSAF?

Contributing any code requires that you are an OpenSAF developer (see below). Contribution guidelines including coding style, function naming convention, patch submission procedures etc. are described in the OpenSAF Developer's Handbook. Following the rules, conventions and guidelines as described in the Developer's Handbook will increase the chances of acceptance of your contribution significantly.

You should only submit code for which you have a copyright - for instance, that you wrote yourself - or when the copyright holder has given you the right to do so. For bug fixes, you can do this because you are modifying code already licensed under LGPL v2.1, which is used by OpenSAF. When you make a contribution of new code that represents additional intellectual property, such as a new service, or significant enhancement, you should take care that such a contribution complies with the terms of the Individual Participation and Contribution Agreement that you signed. In this case the copyright and any intellectual property belongs to you (or the company you are working for), and should be identified in file headers, but you grant OpenSAF a copyright and patent license to use the code and release it under the LGPL v2.1 license, or any subsequent license OpenSAF may choose to use, subject to the terms and conditions of the OpenSAF bylaws. This allows you to use the specific code you contributed in any way you wish, including licensing your specific contribution under a different license for commercial purposes.

How do I become an OpenSAF developer?

All OpenSAF developers need to sign and submit the  Individual Participation and Contribution License Agreement (IPCA). After your IPCA have been received and processed you will get mail welcoming you to OpenSAF Developer community. To fully complete the application procedure you need to post two signed originals of Contribution License Agreement to the OpenSAF foundation within 30 days after faxing the agreement. President of OpenSAF foundation will sign both originals. One will be left in OpenSAF foundation and second one returned by post to you.

How do I get an account on developer server (devel.opensaf.org)?

Only OpenSAF developers could ask for an account on developer server. This account enables developer both to edit wiki content on developer site, and gives Unix account on developer server. Note that it is not necessary to have an account on developer server to issue and answer tickets, submit patches, etc. Unix account is useful in case developer wants to distribute early development Mercurial branch of some upcoming major feature to developer community for review or early test. For example, developer could upload development branch on his home directory on devel.opensaf.org and publish link to it on developer mailing list, so that other developers could pull code from that branch and test it.

Why do I have to sign a developer agreement to contribute to the project?

In the developer agreement, you affirm that you have intellectual rights to the code that you contribute, you grant the OpenSAF Foundation to use the code, and you grant a patent license to the contributed code, among other things. Only when all contributors do this can the OpenSAF Foundation release the source code with an open source license.

A developer agreement is a standard practice in many open source projects.

OpenSAF Services

Can I use OpenSAF complementary (non-standard) services in my application?

Yes, applications can use OpenSAF complementary (non-standard) services in their applications. Note that OpenSAF Project could decide in a future to change some of these services in non-backward compatible way. For example, in case a standardized service becomes available providing same features, or service is replaced with an alternative offering significant advantages.

OpenSAF releases

When will feature X be implemented in OpenSAF?

The roadmap for next releases of OpenSAF is published in the developer web site wiki. The roadmap is based on the change requests that OpenSAF developers have submitted. To be put on a roadmap, a feature needs to be classified as major, have an effort estimate, and there must be committed resources for its implementation.

The OpenSAF Roadmap is created according to the rules in the OpenSAF Development Process.

But feature X is not on the roadmap!

OpenSAF developers can submit new features to the roadmap by creating a change request according to the OpenSAF Development Process.

The roadmap lists only the major features, many smaller ones will be implemented without appearing on the roadmap.

What is new in OpenSAF release X.Y.Z?

Short release notes are in the  roadmap tab in the OpenSAF developer web page. A more complete change log is part of the download package (file called ChangeLog).

How do I find out when a new OpenSAF release comes out?

Subscribe to the "announce" mailing list on  mailing lists page on OpenSAF web page.

More information

What is the best source for technical information on the OpenSAF code base?

The OpenSAF download page has a good documentation package in PDF and HTML format. In that, the OpenSAF Overview document is probably the best starting place to start learning about OpenSAF.

Last modified by marioa, 11/05/08 10:17:30 (4 years ago)