Development Guidance

Back To: Proposed SME Server Community Constitution Docs

The SME Server is a Linux server distribution focused on simplicity, stability, reliability, and security. It is built using only components that have an extensive track record in these areas. The server is designed to be maintained by people with little or no technical background.

Development Group Guidance

Package Categories

The SME Server packages are considered to be sorted into the following categories. Each level requires, but does not influence or control, the levels below it.

The components of an installed SME Server are considered to be sorted into the categories below. The categories do not map directly to YUM distribution channels. Each level requires, but does not control, the levels before it.

1) The base distribution - (the Linux kernel, hardware drivers, network protocols, etc.)

This has been, at various times, RedHat, Fedora Legacy, and CentOS. This category also includes many third-party packages like Apache, Samba, MySQL, etc. The reason for inclusion here is that these packages are released and maintained as part of the base distribution. The core developers shall choose the packages in this category.

2) The core "infrastructure" software - (e.g. e-smith-lib, firewall base rule set, installer, etc.) The most recent versions of these have been predominately released or repackaged by Mitel, with some community patches. It also includes some third-party packages that are not released as part of the base distribution, and have not been repackaged. Examples of all the above include djbdns, dovecot, horde, turba, etc. The reason for inclusion here is that these packages are not released as part of the base distribution. The core developers shall choose the packages in this category.
3) Smecore (e.g. i-bays, virtual domains, e-mail)
These are custom packages, written specifically for SME Server, sourced from Mitel, e-Smith, and/or the contribs or core developers. These packages are part of the core distribution, and will be supported for any patches or upgrades.
4) Smeaddons
These packages have been developed to extend the functionality of SME Server. To the extent possible, given time and resource constraints, an attempt will be made to work with the maintainer to mitigate the affect of any relevant patches or upgrades. These packages are not part of the core distribution.
5) Smetest packages
These packages have been selected to undergo a testing procedure toward eventual inclusion in the Smeaddons category. They are included here for testing purposes only.
6) Smedev packages
These packages have not been tested or examined by the community. These packages might replace software included in the categories below it. The user should understand the implications of using packages in this category, as they may work well, but be incompatible with each other, or cause problems with future system upgrades. No attempt will be made to test the affect of any patches or upgrades on packages in this category.

There are some packages that do not fit neatly into these categories. This occurs when one of the base or core packages is modified by anything higher in the list, creating a fork - whether by Smecore, Smeaddon, Smetest, or Smedev category packages. It is the intention of the Contribs community to keep the number of these files as close to zero as possible. In the event that there is seen to be no alternative other than to erase/modify the 'upstream' packages, then the developer will work with the original packager to find an acceptable way to commit the necessary changes to the upstream package or find a solution where the different packages can co-exist. The very last resort would be to create a fork in development. If a package that forks development is created then it should be appropriately labeled as such.

When a particular package is built with the intention of being included in a release, the necessity to fork upstream packages must be agreed upon in advance, by a method to be determined by the core developers and the Development Manager (DM).

Additional Package Details

Core Distribution

Packages from the base distribution will not be rebuilt. The core infrastructure and smecore will be rebuilt and signed by the community. This means that all packages in the core distribution will be signed.

The community will maintain a copy of all source code that make up the core distribution to be fully compliant with license requirements. It must be possible to build the complete SME Server distribution from these copies.

Release Cycle

Naming Convention
SME 7.0 New base = CentOS 4.x
SME 7.1 = CentOS 4.(x+1)
SME 7.2 = CentOS 4.(x+2)

SME 8.0 New base = CentOS 5

SME 9.0 New base = TBA

Explanation
A Major release will be created each time the base OS is substantially changed. These may occur every 18 months, although the next move can occur anytime from now.

A Minor release will be designated for each base OS update, and these are expected quarterly. The next one of these is expected any day now.

New development will be targeted for one of these releases to minimise the number of releases.

Only one base is supported for new development. All other bases are declared as being maintenance branches. The decision to switch the development branch will be at, or just before, the first Alpha release. It is not expected that any development would be back ported. At the moment the SME 7 branch is the development branch and SME 6 is in maintenance.

It is the responsibility of the maintenance team to make all releases for each of the maintenance branches. The release will be maintained for as long as the base os is maintained which could be for seven years.

Security Monitoring and Patching

All base, core and feature packages will be monitored for security vulnerabilities. Smeaddons packages will be monitored as closely as time and resource constraints permit. Smetest packages will not be monitored for security vulnerabilities.

The DM, or designate, is the person who makes the call on security issues - whether to put out an advisory, whether to put out a patch, gauge the severity level, etc.

A reasonable set of security oriented mailing lists and/or websites will be chosen as sources of security advisories, together with the appropriate CentOS information. Other sources may be used if deemed desirable. A process will be designed to organize the response to any potential security issues. At a minimum, the process will ensure that:

• Each identified potentially appropriate advisory will be listed in a central location, bug tracker, etc.;
  
• A decision will be made about whether the issue is appropriate and whether a "Known Issue" advisory is necessary - if so, it will be issued;
  
• Appropriate provision is made to allow the Security team time to review the issue and respond;
  
• Identify a person/role to create an advisory using the review responses;
  
• Identify a procedure to issue an advisory to the community;
  
• Identify a procedure to build, test, and release patches;
  
• Identify a procedure to update or close the advisory.
  

It is recognized that many of the patches will be issued from external sources; provision will be made in the security process to allow for this.

The security team needs close cooperation with the communications team - advisories are usually better if the technical content comes from the security team, but the “Why am I affected, and what should I do?” information should come from the communications team.
In a number of instances the issue looks very serious on first viewing, but detailed investigation shows it cannot be exploited on the SME Server, etc. Therefore, the process will allow the possibility of multiple updates to an advisory.
There should be a policy of full disclosure, but only once vendors have been given reasonable time to have a look at the issue.
The aim is to respond quickly to each advisory with at least:
“Looking into it/Not vulnerable/Not relevant”

If a table of packages is maintained then people can see for themselves that “sendmail isn’t in the load, so the SME Server is not vulnerable”. We need to include packages in the smeaddons tree, at least for those available through standard yum channels.

YUM Repository

All packages are expected to be distributed via the YUM software. A channel will be maintained for each of the following package types, for each SME Server release, plus any others deemed necessary. Each of the channels will be hosted by at least three mirrors.

os = The packages on the iso. This is a static channel. No packages will be allowed to be added or removed once the release is final. However, this channel is dynamic for unreleased versions. It is only frozen at the time of release.

addons = "Well-behaved"/tested add-ons. This channel is dynamic;
packages can be added or deleted at any time.

test = Add-ons undergoing testing. This channel is dynamic,
packages can be added or deleted at any time. It is expected that a
package will only be in this channel temporarily.

dev = Other add-ons. This channel is dynamic, packages
can be added or deleted at any time

updates = Packages from the maintenance team that are applied to smecore. Some packages may have been sourced from other teams, even translations from the documentation team, but are tested & pushed by the maintenance team.

updates-testing = Packages that are being tested by the maintenance team. Some packages may have been sourced from other teams, even translations from the documentation team, but are being tested by the maintenance team.

GForge

All smetest and smeaddons packages are expected to be hosted on the the community website using GForge, see http://gforge.org/. Appropriate provision will be made for packages that are under active development or are actively maintained, as opposed to packages that are simply posted to the site. A process will be designed to enable developers to request their own space in GForge for each package.
All packages that are distributed via the standard yum channels must be hosted on Gforge, both RPM and SRPM packages must be available, and it must be possible to build the complete package.
Packages hosted elsewhere can be fetched with yum, but will not be included in the standard yum channels.

Smedev & Smeaddons

A process will be designed to move custom packages between Smedev and Smeaddons. The selected packages will be moved into smetest during this process. At a minimum, the process will ensure that the packages:

• Have been made available to the community in both RPM and SRPM forms;
  
• Have been tested for functionality;
  
• Have no licensing issues;
  
• Have an identified maintainer;
  
• Have been determined not to require the modification or replacement of any of the base or core packages
  

Smeaddons & Smecore

A process will be designed to move custom packages between Smeaddons and Smecore, or directly into the Smecore. At a minimum, the process will ensure that the packages:

• Continues to meet all the requirements to move into Smeaddons
  
• Have either been determined not to require the modification or replacement of any of the base or core infra packages, or have had the necessity for these changes agreed upon in advance.