Here is section two of the proposed constitution. Please note that there are three sections - only the first section is proposed as part of the constitution. The other two sections were created as supplementary material, and are not intended to be part of the constitution.
%%%%%%%%%%%%%%%%%%%%%%%%%%%
Developers Group
%%%%%%%%%%%%%%%%%%%%%%%%%%%
Overview
The developers group, supported by the Development Manager, can be split into four areas
* Core Platform Developers
* Contrib Developers
* Maintenance Team
* Support Team
Note that any individual volunteer may hold more than one role on more than one team.
The Development Manager (DM) will strive to support the efforts of all groups.
Core Platform Developers
The Core Platform Developers are responsible for the development of the core packages that make up the SME Server and for alignment with any upstream releases upon which the server is based. The output of this group is a set of packages that can form a new release. One becomes a core developer by volunteering and demonstrating competence to the current developers.
Contrib Developers
The Contrib Developers are responsible for packages that add functionality to an SME Server release. These packages are not part of the release, but some may be included in future releases. Others will always be maintained as separate packages. The output of this group is a set of "contribs", each of which may be composed of multiple packages. One becomes a contrib developer by either volunteering or developing and announcing a package.
Maintenance Team
The Maintenance Team is responsible for releases after the final release. The output of this team is a set of packages that should be applied to previous releases to maintain its functionality. The updates are not intended to extend the functionality of the release. The updates will include bug-fixes and security updates. One becomes a maintenance team member by volunteering.
There is also a closed sub-team, the Security Team, that will review security issues. It is expected that there will be some overlap between the core platform developers group and security sub-team. This group is the only closed group in the organization for security purposes. One becomes a member of the Security Team by application to the Development Manager, and approval by the existing Security Team members. The Development Manager will be a member of the Security Team.
Support Team
The purpose of the Support team is to help the other three teams as requested. The primary focus is on providing support services to developers, in any component category.
The Support team will be formed by the Development Manager.
Development Manager (DM)
This person will lead the volunteers in the support team. The DM is primarily a facilitator. The DM is an elected post, elected by the entire community, with a term of one year. The duties include:
* Facilitate the development of SME Server.
* Communication with all of the other groups and represent the Developers in these discussions.
* Communication with the teams within the Developers Group.
The Development Manager is specifically empowered to create and dissolve roles within the Support Team to delegate and accomplish the responsibilities listed above. These roles shall be carefully chosen and filled, based on the needs of the developers groups, the responsibilities listed above, and the available time and resources. A non-binding list of these roles, titled “Developer Group Roles”, is available in association with this constitution. This list is intended to be for reference only.
It is expected that each group will generate a living set of guidelines (similar to the "Guidance Document" associated with this constitution), for the practices and operation of that group. These guidelines will be maintained by the DM.
%%%%%%%%%%%%%%%%%%%%%%%%%%%
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.
! 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. 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 ruleset, 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 contribs.org. 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 contribs.org. This
means that all packages in the core distribution will be signed.
Contribs.org 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 3.x
SME 7.1 = CentOS 3.(x+1)
SME 7.2 = CentOS 3.(x+2)
SME 8.0 New base = CentOS 4
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 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 backported. 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 organise 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.
smecore = 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.
smeaddons = "Well-behaved"/tested add-ons. This channel is dynamic,
packages can be added or deleted at any time.
smetest = 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.
smedev = 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 sme
core. Some packages may have been sourced from other teams, even
translations from the docs team, but are tested & pushed by the maintenance
team.
! GForge
All smetest and smeaddons packages are expected to be hosted on the
contribs.org 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 contribs.org 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.
%%%%%%%%%%%%%%%%%%%%%%%%%%%
Developer Group Roles
%%%%%%%%%%%%%%%%%%%%%%%%%%%
This document consists of a list of a number of potential roles that may prove to be useful in the routine operations of the Developer Group. Because of the many unknowns in this use, the list is for reference purposes only. It is not intended to be binding.
Developer Group Roles
Development Manager (DM)
This person will lead the volunteers in the support team. The DM is primarily a facilitator. The DM is an elected post, elected by the entire community, with a term of one year. The duties include:
* Facilitate the development of SME Server.
* Communication with all of the other groups and represent the Developers in these discussions.
* Communication with the teams within the Developers Group.
*
Solicit and maintain a database of volunteers interested in the development side of SME server (contribs, core and maintenance) as well as their available time.
o Bug tracking, triage, and patching
The Development Manager is specifically empowered to create and dissolve roles within the Support Team to delegate and accomplish the responsibilities listed above. These roles shall be carefully chosen and filled, based on the needs of the developers groups, the responsibilities listed above, and the available time and resources. The proposed initial set of roles is listed below.
Release Leader(s) (RL).
A Release Leader is responsible for a given release, taking it from alpha to gold. The main duty of this role is to ensure that a high quality release is made in a timely fashion. This can be achieved by effective communication with the core developers and efficient use of the community. The DPM and Core Platform Developers will choose a RL in time for Alpha 1.
The Release Leader can be the DPM, or if not, needs to work closely with the DPM.
Build Manager
The build manager is responsible for building and signing the rpms and spinning the ISO.
The build manager is responsible for the tools used to build the rpms and the ISO.
The build manager has access to the code repository, and should be able to assemble an ISO for testing at any point during the build process.
Contribs Support Manager
The Contribs Support Manager is responsible for providing services to the contribs developers, and will provide help when requested by the contribs developers. The duties consist of:
* Coordinate with other groups to help find volunteers
* Facilitate the process of moving a contrib from smetest to smeaddons
GForge Admin
The GForge admin is responsible for the maintenance and upkeep of the GForge repository. The duties include:
* Establish and publish guidelines for the use of the repository.
* Contact developers in breach of those guidelines
YUM Admin
The Yum Admin will set up the required Yum channels and ensure that the packages can be retrieved from their respective channels.
Test Manager
The Test Manager is responsible for maintaining a set of test cases.
The Test Manager will co-ordinate volunteers to assist in writing test cases and testing scripts.
There can be test cases for testing a new candidate release, and tests for new contribs.
The Test Manager will co-ordinate the testing activity and collate the results from the testers.
The Test Manager works with the RL to decide the test set to be used for any given release.
Testers
This group of volunteers comprises people who are willing to test SME Server.
They may be testing a candidate release, or new contribs.
The testing may be planned testing following test cases, or ad-hoc testing.
All errors found in the testing should be recorded clearly in the bug database.
Security Team
There is also a closed sub-team, the Security Team, that will review security issues. It is expected that there will be some overlap between the core platform developers group and security sub-team. This group is the only closed group in the organization for security purposes. One becomes a member of the Security Team by application to the Development Manager, and approval by the existing Security Team members. The Development Manager will be a member of the Security Team. The roles for this sub team are:
Security team Leader (STL)
This person shall lead the volunteers associated with security issues for the SME server.
* The STL should be an experienced software engineer.
* The STL will determine who is included in this group.
* The initial STL should be a member of, or recommended by, the core developers team. Subsequent STL's will be chosen by the Security Team.
* The STL will organize any review of potential candidates prior to their acceptance into this group.
* The STL will prepare and present to the community the security policy.
Security team
This group is the only closed group in the organization for security purposes.
* The number of members is at the discretion of the STL.
* People who volunteer will be reviewed by the STL prior to acceptance
0 Replies
7496 Views