On Fri, 06 Jun 2014 15:38:25 -0700
Adam Williamson <awilliam(a)redhat.com> wrote:
I'm currently drafting some rough proposed release criteria for
Server, heavily based on the tech spec. I notice the "Problem
reporting" section of the spec is somewhat loose. It reads:
"Problem reporting
Problems and error conditions (e.g. kernel oopses, Selinux AVCs,
application crashes, OOM, disk errors) should all be reported in the
systemd journal.
Support for sending this information to a central place (like abrt
does for crashes today) is mandatory."
the word "must" appears multiple other times in the page, so we have
the old chestnut of whether we're using "must" and "should" with
strict definitions, or as synonyms, or what.
I think we MUST clean the MUST and SHOULD's up there.
And then the second
paragraph throws in another candidate: "Support...is mandatory". What
exactly is "is mandatory" supposed to mean in this context? Such
"support" must be *available* in Server? It must be *installed* (and
enabled?) for the system to count as a "Fedora Server system"? Both
of these are possible interpretations. What do we mean by "a central
place"? Does a log server qualify, or do we mean a *public*, *shared*
repository, for communal troubleshooting?
The definition of "problems and error conditions" is also both vague
and apparently wide. There is no precise definition - "e.g." means
"for example", i.e. it is not comprehensive. But just the things
listed in the "e.g." clause are quite broad:
"kernel oopses, Selinux AVCs, application crashes, OOM, disk errors"
abrt handles kernel oopses and crashes. setroubleshoot handles AVCs.
We do not to my knowledge have anything that submits OOM conditions or
"disk errors" to "a central place" in the style of abrt or
setroubleshoot. I'm not even sure that it makes any sense to send them
to some kind of public issue concentrator, given that these are as
likely to indicate local configuration issues or hardware problems as
they are to indicate bugs in Fedora Server.
So...do we feel this needs cleaning up / clarifying? Anyone who was
involved in drafting this bit remember what the intent was?
I don't, but I think we should clean it up to be consistent on
must/should use. Also, I agree we don't need a central place for "e.g"
stuff.
kevin