Requirements to promote to featured Server Role

[Stephen Gallagher]

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