[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [stp-dev] Committer/Developer commit page v2
|
Good point - plus the automatically generated mail is guaranteed to be
correct :)
How about keeping this in the commit guidelines until our continuous
build is capable of doing this?
Cheers,
David
Daniel Berg wrote:
Regarding the following statement:
* An email needs to be sent to _stp-dev@eclipse.org_
<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.
The process should not be a drain on the development staff.
Emails of this nature should be sent out automatically by the
build system (especially a continuous build). We do this all
the time for our internal products so there is no reason we
couldn't do it here as well.
Regards,
Dan
*David Bosschaert <davidb@xxxxxxxx>*
Sent by: stp-dev-bounces@xxxxxxxxxxx
02/02/2006 10:05 AM
Please respond to
STP Dev list
To
STP Dev list <stp-dev@xxxxxxxxxxx>
cc
Subject
Re: [stp-dev] Committer/Developer commit page v2
Just updated the HTML with some suggestions from Carl:
*Communicating Your Desires/Intentions*
Please mail _stp-user@eclipse.org_ <mailto:stp-user@xxxxxxxxxxx>
with your intentions. A full process will be defined later.
Reworded slightly:
_Automated build and test_: all new code is required to be
automatically built and should be automatically tested by the
STP build system.
I'm intending to put this page up tomorrow, so that would give
everybody today for further feedback. The file will be in CVS,
so can always be tweaked later.
Cheers,
David
David Bosschaert wrote:
Hi all,
I've updated the contributing.html page according to the
consensus reached yesterday during the IRC.
Comments/votes welcomed.
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 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.
*Commitment to Development*
*Communicating Your Desires/Intentions*
Please mail _stp-user@eclipse.org_ <mailto: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.
*Code and Commit Process*
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:
o _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.
o _Automated tests_: all code should have an automated test
suite that automatically runs as part of the overall test
process.
o _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:
o _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.
o _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@eclipse.org_
<mailto:stp-dev@xxxxxxxxxxx> containing:
* The same information as in the Log
above, plus:
* 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
------------------------------------------------------------------------
_______________________________________________
stp-dev mailing list
stp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/stp-dev
