[prev in list] [next in list] [prev in thread] [next in thread]
List: scap-security-guide
Subject: Re: Short lived branches for stabilization before release
From: Gabe Alford <redhatrises () gmail ! com>
Date: 2019-09-10 20:50:56
Message-ID: CAGLxfGz+j36-9HLi=9+ugnsVo07i=N+9rVcVZQKWLh_Ru_82Ow () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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.
> 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.
On Wed, Sep 4, 2019 at 10:11 AM Trey Henefield <trey.henefield@ultra-ats.com>
wrote:
>
>
> 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 <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
> <scap-security-guide@lists.fedorahosted.org> * and others authorized to
> receive it. If you are not * scap-security-guide@lists.fedorahosted.org
> <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.
>
> _______________________________________________
> scap-security-guide mailing list --
> scap-security-guide@lists.fedorahosted.org
> To unsubscribe send an email to
> scap-security-guide-leave@lists.fedorahosted.org
> 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/scap-security-guide@lists.fedorahosted.org
>
[Attachment #5 (text/html)]
<div dir="ltr"><div>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.</div><div>Not sure what has changed since security is \
always changing and evolving.</div><div><br></div><div><span style="color:black">> \
I have so many commits I have yet to get commited because I am constantly playing \
catchup with the new releases.</span></div><div><span \
style="color:black"><br></span></div><div><span style="color:black">I would recommend \
to any and all contributors to submit commits regardless of where in the release \
cycle things are.</span></div><div><span style="color:black">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.</span></div><div><span \
style="color:black"><br></span></div></div><br><div class="gmail_quote"><div \
dir="ltr" class="gmail_attr">On Wed, Sep 4, 2019 at 10:11 AM Trey Henefield <<a \
href="mailto:trey.henefield@ultra-ats.com">trey.henefield@ultra-ats.com</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang="EN-US">
<br>
<br>
<div class="gmail-m_-5463688327180517663WordSection1">
<p class="MsoNormal">I second that idea. Along with a release \
schedule.<u></u><u></u></p> <p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><span style="color:black">I have so many commits I have yet to \
get commited because I am constantly playing catchup with the new \
releases.<u></u><u></u></span></p> <p class="MsoNormal"><span \
style="color:black"><u></u> <u></u></span></p> <p class="MsoNormal"><span \
style="color:black">Best regards,<br> <br>
<br>
Trey Henefield, CISSP<br>
Senior IAVA Engineer<br>
<br>
Ultra Electronics<br>
Advanced Tactical Systems, Inc.<br>
4101 Smith School Road<br>
Building IV, Suite 100<br>
Austin, TX 78744 USA<br>
<br>
<a href="mailto:Trey.Henefield@ultra-ats.com" target="_blank"><span \
style="color:rgb(5,99,193)">Trey.Henefield@ultra-ats.com</span></a><br>
Tel: +1 512 327 6795 ext. 647<br>
Fax: +1 512 327 8043<br>
Mobile: +1 512 541 6450</span><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><b>From:</b> Watson Sato <<a href="mailto:wsato@redhat.com" \
target="_blank">wsato@redhat.com</a>> <br> <b>Sent:</b> Wednesday, September 4, \
2019 10:53 AM<br> <b>To:</b> SCAP Security Guide <<a \
href="mailto:scap-security-guide@lists.fedorahosted.org" \
target="_blank">scap-security-guide@lists.fedorahosted.org</a>><br> \
<b>Subject:</b> Short lived branches for stabilization before \
release<u></u><u></u></p> <p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">Hello,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I'd like to prose and ask for feedback on $subject \
idea.<u></u><u></u></p> </div>
<div>
<p class="MsoNormal">The main objective is to have a place and period of time to fix \
bugs before a release happens.<u></u><u></u></p> </div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p> </div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">How would this work?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Around two weeks before the release date, a branch is created \
for the next version and only fixes can be merged to this branch.<u></u><u></u></p> \
</div> <div>
<p class="MsoNormal">When release date comes, release happens from the branch. And \
then it is merged back into master, so that fixes are there too.<u></u><u></u></p> \
</div> <div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal">-- <u></u><u></u></p>
<div>
<div>
<p class="MsoNormal">Watson Sato<br>
Security Technologies | Red Hat, Inc<u></u><u></u></p>
</div>
</div>
</div>
</div>
<br>
<br>
<p><font size="1"><b><font face="Verdana, Arial, Helvetica, sans-serif" \
color="#666666">Disclaimer</font></b><font face="Verdana, Arial, Helvetica, \
sans-serif" color="#666666"><br>
The information contained in this communication from </font></font><font \
size="1" face="Verdana, Arial, Helvetica, sans-serif" \
color="#666666"><b>
<a href="mailto:trey.henefield@ultra-ats.com" \
target="_blank">trey.henefield@ultra-ats.com</a> </b> 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 <b>
<a href="mailto:scap-security-guide@lists.fedorahosted.org" \
target="_blank">scap-security-guide@lists.fedorahosted.org</a> </b> and others
authorized to receive it. If you are not <b>
<a href="mailto:scap-security-guide@lists.fedorahosted.org" \
target="_blank">scap-security-guide@lists.fedorahosted.org</a>
</b> 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.</font><br>
<br>
</p></div>
_______________________________________________<br>
scap-security-guide mailing list -- <a \
href="mailto:scap-security-guide@lists.fedorahosted.org" \
target="_blank">scap-security-guide@lists.fedorahosted.org</a><br> To unsubscribe \
send an email to <a href="mailto:scap-security-guide-leave@lists.fedorahosted.org" \
target="_blank">scap-security-guide-leave@lists.fedorahosted.org</a><br> Fedora Code \
of Conduct: <a href="https://docs.fedoraproject.org/en-US/project/code-of-conduct/" \
rel="noreferrer" target="_blank">https://docs.fedoraproject.org/en-US/project/code-of-conduct/</a><br>
List Guidelines: <a href="https://fedoraproject.org/wiki/Mailing_list_guidelines" \
rel="noreferrer" target="_blank">https://fedoraproject.org/wiki/Mailing_list_guidelines</a><br>
List Archives: <a href="https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedorahosted.org" \
rel="noreferrer" target="_blank">https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedorahosted.org</a><br>
</blockquote></div>
[Attachment #6 (text/plain)]
_______________________________________________
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org
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/scap-security-guide@lists.fedorahosted.org
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic