On 2/26/19 11:07 AM, Matěj Týč wrote:
the possibility to build the ComplianceAsCode/content project on RHEL6
using python2.6 and other dated utilities is becoming a luxury. It
prevents contributors to use elegant constructs available in
python2.7, and sometimes passing the CI for RHEL6 requires some weird
workarounds that take time to design and implement and those
workarounds just complicate the code, they don't bring benefits.
As RHEL6 won't get any significant updates and one can build RHEL6
content on other OSs (or in a container), the RHEL6 CI setup seems to
gain negative value. Do you, our precious community around the
project, have arguments why the RHEL6 should be part of the CI?
Answer similar to the conversation about OpenSCAP CI:
The end of RHEL 6's maintenance support 2 phase isn't until 30-NOV-2020
. Until then we should be prepared to release security advisories
(RHSAs) and urgent bug fixes (RHBAs) for downstream scap-security-guide
Developers judgement call whether downstream RHSAs and RHBAs can be
released in a timely, high-quality manner, without an upstream CI.
Unlike the OpenSCAP conversation about RHSAs or RHBAs.... any bugs to
security content may automatically be considered high priority RHBA
since it deals with potential false positives/negatives.
In reality there may have been little to no RHSAs or RHBAs for
downstream scap-security-guide. However it's the Red Hat brand promise
that if there ever are, we'll be ready.
If there are no agreed-upon reasons, we are leaning towards switching
the RHEL6 CI off within two weeks, i.e. in the first half of March.
On behalf of the Brno Security Compliance team,
this chanced to Security Automation team?