On Mon, Nov 19, 2018 at 1:31 PM Julen Landa Alustiza <julen@xxxxxxxxxxxxxx> wrote:
We found a bug[0] on cron + selinux-policy that broke /etc/cron.d readability for cron, resulting in a non working /etc/cron.d directory and was proposed as blocker bug.During the blocker-review meeting, there was a majority of attendes in favour of blocking due to this bug but we didn't have a clearly violated criteria [1], so I'd like to discuss about a new server criteria to fix this situation.Let start with something short:"Cron service must work on server for root's jobs, other users' jobs and jobs from cron job directories inside /etc".Actually is quite difficult to fully test cron funcionality (openqa worker can't wait for 3 months to see if cron is working properly for a trimestral cron line), so I think that we should be more specific about "must work".
I think we should have blocked on that specific bug, yes. But Server SIG people iirc didn't consider it that important during the meeting, and that's why we didn't push it further.
Regarding release criteria, I'd fine with having such a criterion, but I'm worried about criteria becoming a jungle of various tool specifications, if we continue this way. We certainly don't want to explicitly state that cp must work, find must work, man must work, .... In desktop, we say that all preinstalled apps must work at least in their basic functionality. I wonder if we can do the same with server/command line environment. Something like "all command line tools that are installed by default and are considered 'basic', i.e. most power users know them and use them, must work at least in their basic functionality". It's *very* vague, but I wonder if it's still a better approach than specification of each such tool and exactly what it must do. If it's unclear whether tool X falls into this, we can discuss it and then add it to this criterion ("this explicitly includes: tool X, tool Y") so that we don't forget about it in the future.
If we decide to go with a dedicated cron criterion, I'd like to see Server SIG backing it, this is mostly their area.
_______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx
