Commit bad53234 authored by Martyn Welch's avatar Martyn Welch

Add documentation on long term maintenance and testing

Highlight the potential long term maintenance and testing responsibilities
that can be expected with changes/additions to Apertis.
Signed-off-by: default avatarMartyn Welch <martyn.welch@collabora.com>
parent a37c29ee
......@@ -19,9 +19,9 @@ such as [coding conventions](coding_conventions.md) and
### Upstream First Policy
Apertis is a fully open source GNU/Linux distribution that carries a lot of
components for which it is not the upstream. The goal of `upstream first` is to
minimize the amount of deviation and fragmentation between Apertis components
and their upstreams.
components for which it is not the upstream. The goal of
[upstream first](upstreaming.md) is to minimize the amount of deviation and
fragmentation between Apertis components and their upstreams.
Deviation tends to duplicate work and adds a burden on the Apertis developers
when it comes to testing and updating to newer versions of upstream components.
......@@ -140,10 +140,23 @@ important that any additions to the main
and can be shown to fill a specific and real use case. Maintaining the
packaging, updating the codebases of which Apertis is comprised and performing
testing on supported platforms is a large part of the effort needed to provide
Apertis. As a result, it will be necessary to either be able to provide a
Apertis. As a result, it will be necessary to either be able to provide a
commitment to support any packages proposed for inclusion in the main Apertis
projects or gain such a commitment from an existing member.
The Apertis development team commit to maintaining the packages included in the
references images. Packages may be added to the main package repositories but
not form part of the reference images. Such packages will be maintained on a
best effort basis, that is as long as the effort remains reasonable the Apertis
team will attempt to keep the package in a buildable state, however runtime
testing will not be performed. Should the package fail to build or runtime
issues are reported and significant effort be required to modify the package
the original or subsequent users of the package may be approached to help
resource fixing the package. Ultimately the package may be removed if a
solution can not be found. Likewise, should a different common solution for
Apertis be chosen at a later date, the package may be deprecated and
subsequently removed.
Proposals for inclusion of new components are expected to be made in the form
of a written proposal. Such a proposal should contain the following
information:
......@@ -169,7 +182,12 @@ changes made do not need to work across the various supported hardware
platforms. It must be noted that whilst a dedicated project area would allow
some requirements with regard to platform support to be ignored, packages in
such areas would still be required to comply with other Apertis rules such as
[open source licensing](license-expectations.md).
[open source licensing](license-expectations.md). It should be expected that
the Apertis developers will take a very hands off approach to the maintenance
and testing of packages in such areas. If packages in such areas require work,
the project maintainers will be contacted. The Apertis maintainers may at their
discresion help with minor maintenance tasks should a package be of interest to
the Apertis project. Packages that become unmaintained may be removed.
Requests for dedicated project areas are also expected to be made in a form of
a written proposal. Such a proposal should contain the following information:
......@@ -178,6 +196,7 @@ a written proposal. Such a proposal should contain the following information:
- Preferred name to be used to refer to the project
- Expected use of the dedicated area
- Expected lifetime of the project area
- Contact details of project maintainers
Such submissions should be made via the devel [mailing list](https://lists.apertis.org/).
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment