-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I forgot an important one. Inline below.
On 01/06/2014 04:46 PM, Stephen Gallagher wrote:
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=36...
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]
7. If a Server Role packages multiple upstream projects together as a
suite or solution, updates to any of these projects *must* be
coordinated for concurrent release to allow testing of the complete
system.[1]
== 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.
[1] This may mean that Server Roles support "bundling" in some limited
sense; This may be as simple as packages having strict version
requirements. I am electing not to specify an implementation here.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird -
http://www.enigmail.net/
iEYEARECAAYFAlLL/ZoACgkQeiVVYja6o6OySgCffot7tCLI9w1Jh7ai/eKgoRWL
zsMAn03ftTiAlEI6xp4PWySa+kiKXWr+
=Kif0
-----END PGP SIGNATURE-----