People often ask, "What does it take to get involved with
the development of the STP?" There are many ways to get
involved. On the lightweight end of scale, there is involvement by
using the STP and providing feedback and sharing your experiences
on the Eclipse and STP mailing lists and newsgroups. Beyond that,
you can report problems that you discover, so that they may be
addressed in future releases. A deeper level of involvement would
be to actually solve some of the problems that you or others have
uncovered by modifying/writing the necessary code and creating
patches that can applied by the project committers. The final, and
most beneficial way to get involved is to take responsibility for
a significant piece of development work, whether it's enhancing a
particular area of the tool or creating new functionality.
The purpose of this document is to help people and
organizations understand what it means to "commit" to
STP Development at this highest level. Basically, it involves a
commitment to describe, develop, test and document your
contributions.
|
Communicating Your Desires/Intentions
Please mail stp-user@xxxxxxxxxxx
with your intentions. A full process will be defined later.
Becoming a committer
Every developer's contribution is welcomed. And in time,
developers can become committers. A committer is a developer who
has write access to the source code repository for the associated
subproject (or component), and has voting rights allowing to
affect the future of the subproject (or component); other
developers define patches and submit them, indirectly, through
committers. A developer gains such committer rights through
frequent and valuable contributions to a subproject, or component
of a subproject (in the case of large subprojects). We should
point out that creating and submitting quality patches is the best
way to obtain committer privileges for future work.
|
This section applies to code being committed to trunk
(HEAD/mainline) or a maintenance release branch. It does not apply
to temporary development branches. Temporary branches can serve as
an integration area for larger features during development and can
also help collaboration between multiple developers. When such a
temporary branch is merged to trunk the process described below
will apply.
Code quality
We adhere to the Eclipse Quality statement as is outlined here:
http://www.eclipse.org/projects/dev_process/eclipse-quality.php
In addition, we strongly suggest that developers adhere to the
following guidelines:
Javadoc: in addition to the general Eclipse Javadoc
rules: http://wiki.eclipse.org/index.php/Javadoc,
it is strongly advised that all classes have all
public methods Javadocced and a Javadoc section at the class
level. Additionally every package should have a package.html
Javadoc file.
Automated tests: all code should have an automated
test suite that automatically runs as part of the overall test
process.
Test quality: Code Coverage is a mechanism to
measure the quality of the tests. 100% of the public APIs should
be exercised in the test runs. As an overall principle, the
automated tests should exercise as much of all the code as
possible, with a guideline of at least 70% overall coverage. The
testing framework will automatically produce a coverage report as
part of the test run.
Code submission process
Before code is committed in to CVS, it needs to go through the
following process:
Automated build and test: all new code is required
to be automatically built and should be automatically tested by
the STP build system. In some cases this could mean that the
proposed submission also contains modifications to the build
system. Note that the developer can run the automated build
process in the local checkout, just as it will be invoked by the
automated build process.
Review: when you are happy with your code and the
tests, you should get your code reviewed by another committer.
This review process can be done in a variety of ways:
by actually showing the code to the other committer, if
you are working from the same location.
by emailing the code to another committer and conducting
a remote review
by showing the code to another committer from your
machine using a remote desktop sharing tool such as TightVNC
(http://sourceforge.net/projects/vnc-tight).
When the other committer is also happy with the code you can
proceed with the commit. If the original developer is not a
committer the reviewer will have to do the commit.
In short, if you cannot find another committer willing to put
his/her name in the check-in log of your code, the code should
not be committed.
Change Log:
on the commit, a detailed log entry needs to be provided (using
the -m switch on the commit
command) that contains the following information:
Name of the developer and name of the reviewer
(committer).
Revision number.
Brief description of the feature or fix, including a
description of any new configuration, API or user interface.
An email needs to be sent to stp-dev@xxxxxxxxxxx
containing:
Commitment to Documentation
An important part of any enhancement or addition to the STP is
making sure that the on-line help of the tool stays current with
the changes. The responsibility for updating/modifying/writing the
on-line help content that is associated with some part of the tool
lies with the contributors of the code. Unless the contributors
have commit privileges, the on-line documentation content would
get submitted as a patch, much the same as code. And, like code,
producing and submitting quality documentation patches is the way
to obtain documentation committer privileges.
Until a Documentation Style Guide is available for the STP
project, you may refer to the CDT
Documentation Style Guide to help maintain a constant look and
feel for documentation originating from different contributors.
There also a couple of links that take you to additional
information on how to contribute help content for Eclipse
projects.
So, finally, committing to contribute code to the STP also
means committing to contributing the associated on-line
documentation content for the part of the tool that is being
enhanced or created.
|