Re: [stp-dev] Committer/Developer commit page v2

[Daniel Berg <danberg@xxxxxxxxxx>]

Regarding the following statement:

• An email needs to be sent to stp-dev@xxxxxxxxxxx containing:
  • The same information as in the Log above, plus:
  • 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@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

  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@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:

  • 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:
        • 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 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