Initial set of proposed release criteria for Server product

[Adam Williamson]

Hi, folks. Here's my initial dump of proposed release criteria specific
to Server. This is primarily a Server WG responsibility (per the draft
test plan -
https://fedoraproject.org/wiki/User:Adamwill/Draft_Fedora_21_test_plan -
and the discussion of same), but CCing test@ as I know some folks there
will be interested. Please ensure follow-ups *at least* go to server@
(no follow-ups only to test at .)

* It must be possible to forward system logs from one system running the
release to another using rsyslog.

* After system installation, the system firewall must be active, and the
only ports which may be open are port 22 and any ports associated with
server Roles selected during installation. [pace explicit kickstart
configuration]

* After system installation, SELinux must be enabled and in enforcing
mode. [if user does not explicitly request otherwise via cmdline or
kickstart]

* It must be possible to join the system to a FreeIPA or Active
Directory domain, and the system must respect the identity,
authentication and access control configuration provided by the domain.
[details as subnotes]

The bits in square brackets are rough notes; they indicate things that
would be expanded on via the 'expandable sub-notes' mechanism used on
the release criteria pages at present (see any of the release criteria
pages, e.g.
https://fedoraproject.org/wiki/Fedora_21_Alpha_Release_Criteria ). The
text given above would be the 'main text' for each criterion. We haven't
yet really settled the question of how exactly the presentation of the
criteria needs to be done in a Product world, but we can consider the
actual additional criteria that are required more or less independently
of how they should be presented, I think.

This set of criteria are the ones I think need to be added to 'back' the
tech spec,
https://fedoraproject.org/wiki/Server/Technical_Specification ,
*excluding* Role functionality - I expect we'll need a whole subset of
criteria for Role functionality, so I figured I can write that up as a
separate batch to keep each chunk a manageable size.

There are two areas which probably need to be captured with a criterion,
but which I couldn't really write one for yet because of vagueness in
the spec. One is problem reporting mechanisms - see my separate mail on
that topic. The other is remote system management. The spec says:

"Software updates on the Fedora Server must be possible to perform
either locally using command-line tools (e.g. yum/dnf)..."

(okay, we already cover that in current criteria)

"...or centrally by common management systems (e.g. Puppet, Chef,
Satellite, Spacewalk, OpenLMI)."

well, that's extremely broad. Do we really want to have the criteria say
"it must be possible to update a Fedora Server system via Puppet, Chef,
Satellite, Spacewalk or OpenLMI", write a test case for each, and block
releases unless all of those mechanisms work? Or do we want to focus
down a bit?

Thoughts on the proposed criteria, the remote update issue, or any other
criteria we might need beyond the existing 'core' criteria and the ones
for Role functionality would be great! Thanks folks.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net