Requirements to promote to featured Server Role

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In order to seed the conversation for tomorrow's Server WG meeting,
I'm putting together a first draft of a document outlining the
requirements that must be met in order to promote an
application/server technology into a featured role of the Fedora
Server. Note: this must not preclude the ability for services not
considered "Featured" to deploy on Fedora Server.

I will tie these goals to the agreed-upon use-cases where appropriate
(see
https://fedoraproject.org/w/index.php?title=Server/Use_Cases&oldid=365234
for the numbering reference).

Mandatory requirements are exactly as they sound: if any one of these
requirements is not met, the server role is ineligible for elevation
to "featured" status. Optional requirements are different. This is
*not* a list of things you should ignore. Rather, this is a list of
things that if you implement them, you are committing that they must
continue to behave that way in the future. (The list below should make
this more clear).

This is a first draft, please add or criticize as necessary.



== Mandatory Requirements ==
 1. The Server Role *must* be packaged in such a way that it is
possible to install the complete set as a unit. AKA "One-click
Install". [Use Case 1]

 2. The Server Role *must* provide an API or similar stable external
interface for configuring the role post-installation. Exceptions to
this rule may be granted if and only if Optional Requirement 2 (below)
is met and it can be demonstrated that the default method of operation
is the only reasonable method of operation. [Use Case 1]

 3. The Server Role *must* provide an API to interrogate the
configurable settings of the role as identified by Mandatory
Requirement 2. [Use Case 2]

 4. The Server Role *must* add to the functionality of the Fedora
Server. In other words, a Server Role cannot be considered "Featured"
if its purpose is to further reduce the minimal system.

 5. A Server Role *must* have an identified point of contact that
agrees to maintain the Server Role in Fedora. If this person or group
becomes unresponsive, the Server Role will necessarily be demoted from
Featured status.

 6. A Server Role *must* be installable without a local graphical
utility. [Use Case 9]


== Optional Requirements ==
 1. The Server Role *may* be packaged in such a way that it can be
uninstalled as a complete unit. The mechanism to accomplish this
removal *must* remain consistent. [Use Case 1]

 2. The Server Role *may* provide a sane, usable default. If it does
so, it *must* remain capable of accepting input through its
configuration API to change this default. [Use Case 1]

 3. The Server Role *may* provide an API to interrogate additional
useful information about the running service(s) provided by the Server
Role. The content here is up to the Server Role to define, but should
be treated as stable (e.g an update should never remove the ability to
monitor something). [Use Case 2]

 4. The Server Role *may* provide a specification of its needed
resources to the Fedora Server in a standard format. (e.g. Memory
requirements, etc.) If this is provided, the Fedora Server *may* use
this information to create isolated services such as VMs or containers
in which to run the Server Role. [Use Case 4]

 5. The Server Role *may* request operation in an isolated environment
(with or without implementing Optional Requirement 4). If it does so,
the Server Role must indicate (using a standard Fedora Server API)
what form(s) of isolation it supports. Fedora Server *must* honor
this. [Use Case 4]

 6. A Server Role *may* provide a remote graphical (which includes
web-based) configuration tool.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLLJDQACgkQeiVVYja6o6PdqQCdENVjc7wNkzxhivXHlDKZ1av/
yFkAmgKKDHDX7UVFoheBbPeJRi5In+aY
=6cgw
-----END PGP SIGNATURE-----