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.