> *From:* Gabe Alford <[email protected]> > *Sent:* Tuesday, September 10, 2019 4:51 PM > *To:* SCAP Security Guide <[email protected]> > *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 <[email protected]> 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
_______________________________________________ scap-security-guide mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]
