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.


Yes, I think that it is still the case, but the point is not to have LTS branches and mainlining them.
It is about a creating a branch just focused on fixing bugs before release.
After the release, the fixes are merged to master, and the branch closed.

 

> 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.

 


I second that.


On Tue, Sep 10, 2019 at 11:03 PM Todd, Charles <CTODD@ball.com> wrote:

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.


Todd,
I'm not sure I understand your point, but ComplianceAsCode is about the content, ;)

 

Thanks,

Charlie Todd


--
Watson Sato
Security Technologies | Red Hat, Inc