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

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




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

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.