*From:* Gabe Alford <redhatrises(a)gmail.com>
*Sent:* Tuesday, September 10, 2019 4:51 PM
*To:* SCAP Security Guide <scap-security-guide(a)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(a)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