Hudson Logo

Hudson Software Process

With the goal of providing a predictable, stable and high-quality product that can be contributed to by many different people in the Hudson community, we are proposing the following process be followed by committers for software development. The goal is to provide some structure and predictability to the process while not adding a lot of extra work to the developers contributing to the project. This process includes things that are very common in most open source projects. For simplicity we have focused separately on the processes for the Hudson Core and Plugins separately.

Note for the purposes of this process discussion Hudson Core is defined as being Core itself, the Hudson website repository (WWW) and certain Core or "tier 1" plugins such as Maven. These core plugins are documented in the Wiki.
All other plugins fall into the general plugins category documented in section 2 of this document.

Commenting on this Process

Any comments you have relating to this process can be recorded and tracked in the Hudson Wiki. When commenting, please be sure to refer to the reference number of the section or paragraph that you have the comment on.
Older versions of this document are archived for inspection in the WWW source control area.

1. Processes relating to Hudson Core

1.1 Becoming a Committer

  1. All committers to the Hudson Core need to sign the OCA (fka SCA). (This is the same as it has always been)
  2. Plugin developers do not automatically have the right to commit to Hudson Core, however, they can also graduate to becoming core committers (see #3). The current committers can vote (majority wins) to allow commit rights into the plugins repository.
  3. Community members showing consistent patch submission for core, or check ins to one of the Hudson plugins can either request permission or be nominated to become a committer on the Hudson Core. At that point, the current Hudson Core committers can vote (majority wins) on whether or not to make them a committer.

1.2 Tracking Issues and New Features

  1. All code to be committed to the Hudson Core should be associated with a JIRA issue. A developer should assign an existing issue to themselves or create and assign a new issue. Automatic messages from JIRA will inform the community of work being undertaken. This will provide better tracking and history of issues and changes to the software.
  2. For new functionality, a new JIRA issue should be created prior to starting the work whenever possible. This will both ensure features are properly tracked as well as allow others in the community to be aware of the work being done and provide comments, requirements or even offers to help up front. In some cases this may not be practical - such as work that is already done on an internal project and contributed back to the community at a later date - but the sooner a JIRA issue can be created, the better. This will also help avoid duplication of effort as well as disagreements at the time the work is submitted for review.
  3. For new functionality and major changes to the Hudson Core or APIs, a Wiki page should be created along with the JIRA issue to outline the changes. This can be linked from the JIRA issue and will be communicated to the community. Again, doing this at the beginning of the work will allow the user community the opportunity to discuss the changes if they are likely to affect them, and provide any requirements or feedback before the initial work is done. In this case the developer can use a branch rather than the trunk for development, review and test.
  4. Issues and features relating to Core should be entered and documented in the Core projects within JIRA.

1.3 Code Review

  1. All changes to Hudson Core must be approved by a Hudson Core committer (more on that in section IV below).
  2. All changes to Hudson Core should go through a code review. Developers are not constrained to using any particular tool although we will be adopting Gerrit for those wanting to use it. If the work being checked in is considered minor by the developer they can approve their own change. For bigger changes or ones that the developer would like a review, they can have another Hudson Core committer review and approve the change. The decision to review or not will be left up to the developer (except for cases covered in #3 below). If people are found continuously abusing this freedom they may loose their committer rights.
  3. Any new or major feature or API change to Hudson Core requires a review from another committer. Developers cannot approve their own work when that work is a new feature, major change or API change.

1.4 Committing Code

  1. Only developers with Core committer rights can commit into Hudson Core.
  2. Merges into the Hudson Core should have the associated JIRA issue number at the start of the merge message, and a short description of the work done. The JIRA issue number allows linking the merge with the JIRA issue and the short description provides a quick referenced without the need to go to JIRA. This will provide better insight into users as to what changes are in what version of the Hudson Core.
  3. Commits should be grouped by issue whenever possible/sensible.
  4. Hudson Core committers who commit patches on behalf of another community member should credit that member appropriately in the check in notes and JIRA issue.

1.5 Testing

  1. All code to be committed to the Hudson Core should have a corresponding test case checked in with the change whenever possible. (e.g. Some UI fixes might not be possible to cover with an automatic test). If a commit is already covered by an existing test then the developer should still endeavor to document which test will exercise the code.
    In the case where no test is possible or feasible the developer should make that clear and if necessary create a separate issue for the development of a relevant test in the future.
  2. Committers to the Hudson Core should run the necessary tests before they check in and any results posted with the JIRA issue for auditing and information purposes.
  3. Code coverage will be run nightly against both core and plugins. Developers should strive for 100% test coverage in their areas.

2. Processes relating to Hudson Plugins

2.1 Becoming a Committer

  1. Anyone can ask to be a committer for a new plugin on the Plugins repository. Just mail the Husdon Developer list to ask.
  2. Community members seeking to become a committer on an existing plugin project need only seek the permission of the current lead for that plugin project as listed in JIRA. If a plugin project currently has no lead then commit access permission on that project will be at the discretion of the Hudson Core committers.
  3. As stated in the preamble, in certain cases plugins are regarded as being part of Core rather than separate entities. In this case all of the rules defined for Core commits apply

2.2 Tracking Issues and New Features

Note the current proposal is that each new plugin will have it's own project in JIRA as well as its own SCM repository.

  1. Plugin committers are encouraged to follow the pattern laid down for Hudson Core and create a JIRA issue for any code changes along with Wiki pages for discussing major changes in the plugin. However, this is not mandatory.
  2. Plugin owners should ensure that the version of Core that a Plugin depends upon is clearly documented in the Hudson wiki.
  3. Plugin owners/leads are responsible for defining the attributes of their JIRA projects; Sub components, default assignees etc.
  4. Plugin owners/leads are responsible for ensuring up to date and accurate documentation for their components in the Hudson wiki

2.3 Code Review

  1. Code review is not required for plugins unless that process is agreed upon by plugins that have several contributors. However, again we encourage good practice and welcome peer review between plugin writers. Crucible can be used for this task.

2.4 Committing Code

  1. Only developers with committer rights on a specific plugin can commit into that plugin's repository,
  2. Commits should be grouped by issue whenever possible/sensible.
  3. Commits should be linked with the associated plugin JIRA issue for traceability.

2.5 Testing

Note having good tests is an essential part of being a good Hudson plugin. If a plugin is going to be promoted to Tier 1 or 2 then tests are an essential part of the evaluation criteria for that.

  1. Plugin writers are encouraged to provide tests along with the plugin code
  2. Plugin writers are encouraged to run the necessary tests before they check in and any results posted with the JIRA issue for auditing and information purposes.
  3. Code coverage will be run nightly against both core and plugins. Plugin developers should strive for 100% test coverage in their areas.

Comments or feedback? Head over to the wiki.

$LastChangedDate: 2011-03-14 18:15:29 +0000 (Mon, 14 Mar 2011) $