"Problem reporting" section of tech spec rather loose

[Kevin Fenzi]

On Fri, 06 Jun 2014 15:38:25 -0700
Adam Williamson <awilliam at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140609/63b440ca/attachment.sig>