The sipXecs project process is pretty straight forward and easy. It's main focus is four things: a) Make sure we maintain high development velocity, b) Enforce quality of whatever we release where all contributions have to follow our guidelines for unit tests, c) Continue to use modern tools, and d) Make sure we all enjoy what we are doing and can work together. 

Click on "READ MORE" below to learn more about the process used by the sipXecs projects, and how that process is reflected in our two major project tools: The subversion source control system and the Jira issue tracker.

It is always a good idea to discuss changes you want to make or suggestions you have on the sipx-dev mailing list before starting your own implementation. Many improvement requests and ideas are already logged in the Jira tracker, so go look and do a search. 

Project Coordinator

The Project Coordinator is the person responsible for obtaining consensus among contributors for decisions pertaining to the project. The project coordinator is responsible for and has write access to the web content pertaining to the project. The project coordinator determines who has write access to the project subversion repository, and to the project issue tracker. Contributors may request that the project coordinator consider granting write access to the repository after demonstrating good design, development and testing practices in patches as well as good judgment as to what issues should be brought to the list.

The Project Coordinator is responsible for enforcing, interpreting, and modifying the standard policies based on the needs of the project.

Work in sipX:

• happens on Branches
• is tracked as Issues
• and becomes available as Releases

Branches

A branch is a named sequence of changes - the branch name is used in subversion as the name of a directory under the top level project directory branch (sipXportLib/branch/2.6/), and in the tracker as a version label (2.6). At any point in time, there are two kinds of branches in a sipX project:

Development Branch

A working branch to which enhancements and bug fixes are first submitted. A development branch may not be functional at times due to high risk submissions (these times should be minimized). There may be more than one development branch in a project in order to accommodate parallel effort (e.g. major changes that would disrupt other development, risky changes, etc.). Development branch names may be a string indicative of the functional goal (sctp), or be a pair of numbers (separated by '.') with an odd minor version number (2.5). At some times, the 'main' branch (the only one not under the 'branches' directory in subversion) may serve as a development branch; see the project status to see how the 'main' branch is being used.

Stable Branch

A fully functional branch with no major outstanding issues or known instability problems. A stable branch should be usable at all times. A stable branch name is always a pair of numbers with even minor version number (2.6).

Normally, there will be only one active stable branch in a project - once a development branch reaches its functional goals and is reliable enough, its minor version number is increased by one and it becomes the next stable branch. Once the new stable branch has existed for a sufficient time (in the opinion of the project coordinator), the previous stable branch status is changed to 'archived' in the tracker, and the tar files for it will no longer be available on the download area. No new submissions are made to an archived branch.

The project coordinator is responsible for creating branches as needed, and for publishing the submission criteria for each branch on the project web page. The project coordinator may designate someone else as the branch coordinator. A branch description includes:

Branch

the branch name

Status

either Development or Stable

Coordinator

the branch coordinators name

Goals

A general description of the goals of this branch. More specific information is found in the issues.

Submission Criteria

A description of what changes may be submitted to the branch; these criteria will change at different times, generally becoming more restrictive as the branch approaches release readiness. These may include such metrics as the issue priority and the amount of peer review required.

an example branch description

Issues

The detailed status of a branch or a release is reflected in the the issue tracker for the project as a set of issues. Issues have 5 properties that are key to the release process:

• Type
• Priority
• Status
• Fixed Version
• Assignee

Issue Type

The issue type describes what motivates a proposed change:

Bug

A problem which impairs or prevents the functions of the project.

New Feature

A new feature of the project, which has yet to be developed.

Task

A task that needs to be done.

Improvement

An improvement or enhancement to an existing feature or task.

Issue Priority

The issue priority describes the importance of the issue. In decreasing order of importance, the priorities are:

Blocker

Blocks development and/or testing work, production could not run. Any problem that prevents the project from being built is automatically a Blocker.

Critical

For a Bug, this means that the bug causes crashes, loss of data, or a significant memory leak.

An issue priority of Critical or Blocker whose Fix Version field is set to an unreleased version label (a planned future release) is a release critical issue; it is considered important enough that the release will not normally be made until the issue is resolved. Issues with the lower priorities below are release candidate issues; changes to address them may also be submitted for the planned release, but if all higher priority issues are resolved the release coordinator may elect to defer them to some future release.

Major

For a bug, an important loss of function that falls short of the Critical level, or in the case of a proposed feature or improvement, a significant upgrade.

Minor

A small problem or proposed improvement.

Trivial

Very small, but worth recording.

Issue Status

The status records the workflow progress of the issue:

New

This is the default status for a new issue; it indicates that the issue has not yet been reviewed by a developer. The project coordinator is responsible for monitoring the project for new issues, and ensuring that each is reviewed and either accepted or returned for more data.

Open

When a New issue is accepted, it becomes Open; this indicates that the issue is probably a real one and that there is probably enough information to begin investigation, but that it is not being actively worked on by anyone at this time.

In Progress

Someone (the Assignee) has taken responsibility for this issue and is working on it.

Need Information

This indicates that more information is needed from the reporter (or current assignee) before the issue can be Resolved; the comments must explain what information is needed.

Resolved

A submission has been made that addresses this issue, and the submitter believes that change to be complete. The comments in the issue description must indicate the subversion revision number (or numbers) that satisfy the issue. Normally, when an issue is status is set to Resolved, it is also assigned either back to the person who originally created the issue or to another appropriate reviewer to confirm that it is fully addressed.

Closed

The issue is fully addressed. If a change was made to address the issue, then the Fixed Version field indicates the release in which the change is (or will be) available, or the branch to which it was submitted (if a specific future release from that branch has not yet been defined).

Reopened

This is the same as Open, but indicates that it had previously been either Resolved or Closed; the comments must explain why the issue was reopened.

Fix Version

Version numbers and branch names may appear in an issue in either of two fields: "Affects Version/s" and/or "Fix Version". For a Bug issue, the Affects Version/s field should include all versions where it is a problem. The Fix Version field is used slightly differently - for planned releases it indicates when a fix is expected to be available. If it it set to a branch name, then that is the branch where the fix is (or will be, depending on the issue status) available. The Fix Version field may also be empty - this indicates that there is no plan yet to address the issue.

Assignee

The assignee is the developer responsible for an issue. If the Assignee value is Unassigned, then no developer has committed to resolving the issue - contact the project coordinator to volunteer to take responsibility for it, or (if your tracker account permits), you can assign it to yourself.

Releases

A release is a snapshot taken from either a stable or development branch; its name is constructed by adding another level to the branch name from which it came, sequentially starting with 1 (2.6.1). Each release is made available as a tar file whose name is constructed from the project name and release number (sipxportlib-2.6.1.tar.gz).

A development release is a snapshot taken from a development branch. Development releases are made to indicate that progress along that branch has satisfied some specified release criteria, but the fact that it is a development release (has an odd minor version) indicates that it it is not known to be suitable for use in environments that require full functionality or high reliablity.

In subversion, the release name is used to create a copy under the tags top-level directory in the project (sipXportLib/tags/2.6.1). Normally, once the release is completed and the tar file created, no further submissions will be made to that directory in subversion.

Release Criteria

The release criteria are the published constraints that a branch must satisfy to be tagged as a release. Deciding on these criteria, as well as final judgement of whether they have been acheived, are the responsibility of the project coordinator or a designated release coordinator. The criteria should include a statement of the overall release goals on the project web page, and the specific release critical and release candidate issues in the tracker.

In the issue tracker, the release name is used as a version label. The issue tracker is the primary way of determining the Release Status. A release progresses through three statuses:

Unreleased

This is a proposed future release; it has a Release Description on a project web page, and some number of release critical and release candidate issues in the tracker. The status of an Unreleased issue can be seen using the "Road Map" link on its project page in the tracker; this will show the status of all issues whose Fix Version field is set to the Unreleased version.

Released

This is an existing release - one for which a subversion tag and tar file are available. New Bug type issues may be reported against it, but if they are addressed it will be in some other release.

Archived

When, in the judgement of the project coordinator, a sufficiently stable subsequent release has been available for long enough, a release may be changed to Archived status; this means that the tar file for it is removed from the public downloads area.

Example Release Descriptions