Dear community,
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?
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, Matěj Týč
On 2/26/19 11:07 AM, Matěj Týč wrote:
Dear community,
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 [0]. Until then we should be prepared to release security advisories (RHSAs) and urgent bug fixes (RHBAs) for downstream scap-security-guide RPMs.
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.
[0] https://access.redhat.com/support/policy/updates/errata
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,
Wasn't this chanced to Security Automation team?
My project rolls the latest updates to the stack on EL6 to ensure that we can discover any drift or bugs in the OpenSCAP stack prior to release.
It would be great to be able to continue to do this on all supported OSs without needing to spin up additional hosts for the building process.
We also do this to allow users that have created in-house additions and/or modifications to the Guide to evaluate their systems easily.
Since, as far as I know, you have to modify the Guide to do this I'm not sure what options this leaves folks that are required to remain on EL6 until end of Phase 2 support.
Thanks,
Trevor
On Tue, Feb 26, 2019 at 11:08 AM Matěj Týč matyc@redhat.com wrote:
Dear community,
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?
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, Matěj Týč _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...
scap-security-guide@lists.fedorahosted.org
-
Matěj Týč -
Shawn Wells -
Trevor Vaughan