Changes

==Development Guidance==

 

 

'''Development Guidance'''

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.  

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.  

== Package Categories ==

=== 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 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.

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'''

<ol></li><li>'''The base distribution'''

(the Linux kernel, hardware drivers, network protocols, etc.)This has been, at various times, RedHat, Fedora Legacy, and CentOS.

(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

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.

and maintained as part of the base distribution. The core developers shall choose the packages in this category.

</li><li>'''The core "infrastructure" software'''

'''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.

(e.g. e-smith-lib, firewall base rule set, installer, etc.) The most recent versions of these have been predominately

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.

released or repackaged by Mitel,

</li><li>'''Smecore'''

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.

(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.

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

</li><li>'''Smeaddons'''

base distribution. The core developers shall choose the packages in this category.

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.

'''3) Smecore'''

</li><li>'''Smetest packages'''

(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

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.

contribs or core developers. These packages are part of the core distribution, and will be supported for any patches or upgrades.

</li><li>'''Smedev packages'''

'''4) Smeaddons'''

These packages have not been tested or examined by the community. These packages might replace software included in the categories below it.

These packages have been developed to extend the functionality of SME Server. To the extent possible, given time and resource constraints, an attempt

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.

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.

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).

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 ===

 

 

 

== 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.  

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.

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 ==

{| class="wikitable"

 

 

|+ Naming Convention

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 7.0 New base

 

| CentOS 4.x

SME 8.0 New base = CentOS 5

 

| SME 7.1

SME 9.0 New base = TBA

| 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

Explanation

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.

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 ===

== 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.

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.

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:

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.;

* 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;

* 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;

* 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 person/role to create an advisory using the review responses;

- Identify a procedure to issue an advisory to the community;

* Identify a procedure to issue an advisory to the community;

- Identify a procedure to build, test, and release patches;

* Identify a procedure to build, test, and release patches;

- Identify a procedure to update or close the advisory.

* 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.

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.

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.

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 ===

== 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.

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

| os  

package will only be in this channel temporarily.

| 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.

 

dev = Other add-ons. This channel is dynamic, packages

| addons  

can be added or deleted at any time

| "Well-behaved"/tested 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.

| 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.

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.

| 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 ==

=== 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 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.

Packages hosted elsewhere can be fetched with yum, but will not be included in the standard yum channels.

Packages hosted elsewhere can be fetched with yum, but will not be included in the standard yum channels.

== Smedev & Smeaddons ==

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

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 made available to the community in both RPM and SRPM forms;

- Have been tested for functionality;  

* Have been tested for functionality;  

- Have no licensing issues;

* Have no licensing issues;

- Have an identified maintainer;  

* Have an identified maintainer;  

- Have been determined not to require the modification or replacement of any of the base or core packages

* Have been determined not to require the modification or replacement of any of the base or core packages

== Smeaddons & Smecore ==

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

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

* 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.

* 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.

----

----

[[Category:SME Constitution]]

[[Category:Constitution]]