Gabe,

What changes more, the scanning engine or the rule content?  If the engine is moderately stable, then splitting the rule content off would only need to maintain support for previous release engines, but distributions could stabilize on a distro-validated engine while the content can then update more frequently.  Folks within a distro might find it easier to submit patches to older engines as well.

 

Disclosure: I’ve never edited the ComplianceAsCode code base either to build or modify, so, not an expert.

 

Thanks,

Charlie Todd

 

From: Gabe Alford <redhatrises@gmail.com>
Sent: Tuesday, September 10, 2019 4:51 PM
To: SCAP Security Guide <scap-security-guide@lists.fedorahosted.org>
Subject: [EXTERNAL] Re: Short lived branches for stabilization before release

 

The project discussed this several years ago as well as adding LTS brances but ultimately decided against it due to the maintenance costs and burdens placed on owners.

Not sure what has changed since security is always changing and evolving.

 

> I have so many commits I have yet to get commited because I am constantly playing catchup with the new releases.

 

I would recommend to any and all contributors to submit commits regardless of where in the release cycle things are.

Breaking commits up into small manageable PRs means that over time there won't be a need to catchup. Otherwise, the time between catching up and release will ultimately become unmanageable.

 

 

On Wed, Sep 4, 2019 at 10:11 AM Trey Henefield <trey.henefield@ultra-ats.com> wrote:

 

I second that idea. Along with a release schedule.

 

I have so many commits I have yet to get commited because I am constantly playing catchup with the new releases.

 

Best regards,


Trey Henefield, CISSP
Senior IAVA Engineer

Ultra Electronics
Advanced Tactical Systems, Inc.
4101 Smith School Road
Building IV, Suite 100
Austin, TX 78744 USA

Trey.Henefield@ultra-ats.com
Tel: +1 512 327 6795 ext. 647
Fax: +1 512 327 8043
Mobile: +1 512 541 6450

 

From: Watson Sato <wsato@redhat.com>
Sent: Wednesday, September 4, 2019 10:53 AM
To: SCAP Security Guide <scap-security-guide@lists.fedorahosted.org>
Subject: Short lived branches for stabilization before release

 

Hello,

 

I'd like to prose and ask for feedback on $subject idea.

The main objective is to have a place and period of time to fix bugs before a release happens.

This would give interested parties space and time to work on fixes, and it would be more transparent and evident that a release is around the corner.

 

How would this work?

Around two weeks before the release date, a branch is created for the next version and only fixes can be merged to this branch.

When release date comes, release happens from the branch. And then it is merged back into master, so that fixes are there too.

 

--

Watson Sato
Security Technologies | Red Hat, Inc

 

Disclaimer
The information contained in this communication from trey.henefield@ultra-ats.com sent at 2019-09-04 12:10:35 is private and may be legally privileged or export controlled. It is intended solely for use by scap-security-guide@lists.fedorahosted.org and others authorized to receive it. If you are not scap-security-guide@lists.fedorahosted.org you are hereby notified that any disclosure, copying, distribution or taking action in reliance of the contents of this information is strictly prohibited and may be unlawful.

_______________________________________________
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedorahosted.org

This message and any enclosures are intended only for the addressee. Please
notify the sender by email if you are not the intended recipient. If you are
not the intended recipient, you may not use, copy, disclose, or distribute this
message or its contents or enclosures to any other person and any such actions
may be unlawful. Ball reserves the right to monitor and review all messages
and enclosures sent to or from this email address.