[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [stp-dev] STP Committer/Developer commit process page
|
Hi Everyone,
Stefan has already started this conversation earlier but the limits on
code coverage (>70%) and the code reviews mentioned in here make me
somewhat nervous about resource and being able to make good progress in
the project.
I should be on the IRC tomorrow though so we can chat about it and get
everyone's input tomorrow.
cheers
Antony
David Bosschaert wrote:
Hi all,
Here's is an initial cut at a commit process page. Its based on what
was discussed last week at the IRC.
BTW I left the section about 'Communication your desires/intentions'
(which is about what features are being developed) since it needs
input from PMC. We could go with the WTP approach (which uses Bugzilla
for this).
Please comment before next IRC (Wednesday).
Thanks,
David
------------------------------------------------------------------------
eclipse SOA tools platform project
contributing to the SOA project
/This document was inspired by the Contributing to the WTP document
<http://www.eclipse.org/webtools/development/contributing.html>/
*Introduction*
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
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.
*Commitment to Development*
Communicating Your Desires/Intentions
...
Becoming a committer
Every developer's contribution is welcomed. And by the 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.
Code submission process
Before code is committed in to CVS, it needs to go through the
following process:
*
_Automated build_: all new code should be automatically built by
the STP build system. In some cases this could mean that the
proposed submission also contains modifications to the build system.
*
_Automated tests_: all code should come with automated tests,
which should run as part of the overall test cycle. The
build-system provides a test coverage measurement tool. Test
coverage should be as high as possible, but certainly not below 70%.
*
_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:
o
by actually showing the code to the other committer, if
you are working from the same location.
o
by emailing the code to another committer and conducting a
remote review
o
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.
*
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:
o
Name of the developer and name of the reviewer (committer).
o
Revision number.
o
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
<mailto:stp-dev@xxxxxxxxxxx> containing:
o
The same information as in the Log above, plus:
o
A list of the files affected by the check-in.
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
<http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/cdt-home/user/docs.html?cvsroot=Tools_Project>
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./
------------------------------------------------------------------------
_______________________________________________
stp-dev mailing list
stp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/stp-dev
--
Antony Miguel
Scapa Technologies
antony.miguel@xxxxxxxxxxxxx
+44 131 550 1766