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
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
- All committers to the Hudson Core need to sign the OCA (fka SCA). (This is the same as it has always been)
- 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.
- 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
- 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.
- 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.
- 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.
- Issues and features relating to Core should be entered and documented in the Core projects within JIRA.
1.3 Code Review
- All changes to Hudson Core must be approved by a Hudson Core committer (more on that in
section IV below).
- 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
- 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
- Only developers with Core committer rights can commit into Hudson Core.
- 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.
- Commits should be grouped by issue whenever possible/sensible.
- 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.
- 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.
- 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
- 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
- Anyone can ask to be a committer for a new plugin on the Plugins repository. Just mail the Husdon Developer list to ask.
- 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.
- 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.
- 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.
- Plugin owners should ensure that the version of Core that a Plugin depends upon is clearly documented in the Hudson wiki.
- Plugin owners/leads are responsible for defining the attributes of their JIRA projects; Sub components, default assignees etc.
- Plugin owners/leads are responsible for ensuring up to date and accurate documentation for their components in the Hudson wiki
2.3 Code Review
- 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
- Only developers with committer rights on a specific plugin can commit into that plugin's repository,
- Commits should be grouped by issue whenever possible/sensible.
- Commits should be linked with the associated plugin JIRA issue for traceability.
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.
- Plugin writers are encouraged to provide tests along with the plugin code
- 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.
- 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) $