<div dir="ltr"><div>It would also be nice to organize tickets based off of the timed release. So if doing a monthly time release, have a ticket queue for the month with the tickets (if any) that would be closed for that month. For any tickets that don&#39;t get closed in that month, role them into the next month&#39;s release. This way users and developers would be able to know what to expect for that particular month. Also, assigning tickets to the user &#39;someone&#39; for any ticket that is not being actively worked so that any new contributor can take it upon themselves to work those inactively worked tickets.<br>
<br></div>Just another 0.02.<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jun 27, 2014 at 7:10 AM, Kayse, Josh <span dir="ltr">&lt;<a href="mailto:Joshua.Kayse@gtri.gatech.edu" target="_blank">Joshua.Kayse@gtri.gatech.edu</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
On Jun 24, 2014, at 10:16 AM, Jan Lieskovsky &lt;<a href="mailto:jlieskov@redhat.com">jlieskov@redhat.com</a>&gt; wrote:<br>
<br>
&gt; ----- Original Message -----<br>
&gt;&gt; From: &quot;Steve Grubb&quot; &lt;<a href="mailto:sgrubb@redhat.com">sgrubb@redhat.com</a>&gt;<br>
&gt;&gt; To: <a href="mailto:scap-security-guide@lists.fedorahosted.org">scap-security-guide@lists.fedorahosted.org</a><br>
&gt;&gt; Cc: &quot;Jan Lieskovsky&quot; &lt;<a href="mailto:jlieskov@redhat.com">jlieskov@redhat.com</a>&gt;<br>
&gt;&gt; Sent: Tuesday, June 24, 2014 2:32:43 PM<br>
&gt;&gt; Subject: Re: Formalizing the release process / schedule<br>
&gt;&gt;<br>
&gt;&gt; On Tuesday, June 24, 2014 04:55:33 AM Jan Lieskovsky wrote:<br>
&gt;&gt;&gt; Hello folks,<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;  since the request to give more formalized shape to SSG release process /<br>
&gt;&gt;&gt; schedule appeared couple of times in the past already (to mention some<br>
&gt;&gt;&gt; example:<br>
&gt;&gt;&gt; <a href="https://lists.fedorahosted.org/pipermail/scap-security-guide/2014-May/00541" target="_blank">https://lists.fedorahosted.org/pipermail/scap-security-guide/2014-May/00541</a><br>
&gt;&gt;&gt; 6.html)<br>
&gt;&gt;<br>
&gt;&gt; I think a faster release cadence is a good idea in general. But beside<br>
&gt;&gt; speeding it up, some more formalities need to be considered. The biggest one<br>
&gt;&gt; is what is the meaning of major, minor, and patch in the project versioning?<br>
&gt;&gt; When would there be a stable branch?<br>
&gt;<br>
&gt; Thank you, Steve. These are great questions. To be honest I am not able to answer<br>
&gt; them, but will try (Shawn, Jeff please correct me where appropriate):<br>
&gt; * patch version - no new features, just bug fixes for existing checks<br>
&gt; * minor version - adding new XCCDF rules / OVAL checks<br>
&gt; * major version - adding support for new product?<br>
&gt;<br>
&gt; In the current scenario we don&#39;t differentiate these from each other (test case<br>
&gt; fix might go into release with new rule definition / new product support). After<br>
&gt; some time (when master diverged &quot;sufficiently enough&quot; from existing released version)<br>
&gt; a new tarball is released. The current approach results into situation we are not<br>
&gt; able (at least I) to tell how is e.g. 0.1.18 version better than 0.1.17 one was.<br>
&gt; So at least from this point of view having the versioning rules more strictly defined<br>
&gt; it might be easier for the consumers to know what got improved from the last version.<br>
&gt;<br>
&gt; Regarding the stable branch - from the nowadays experience &quot;it seems&quot; the patches<br>
&gt; are merged to stable branch in the moment they have shown not to break things.<br>
&gt; What I personally miss from the version scheme being some way of expression about<br>
&gt; the percentage, how much of the system is covered by the rules and to how much level<br>
&gt; of testing those rules have been actually tested. In other words so the consumer<br>
&gt; would be able to say e.g. v0.1.17 has had the RHEL-6 product covered to 75% percentage,<br>
&gt; with 57% of rules being covered with test_attestation. v0.1.18 should then improve<br>
&gt; these statistics (at least I hope so) - not just for RHEL-6, but also for other products.<br>
&gt;<br>
&gt; Having this applied I think it would be easier to identify the state, when we have reached<br>
&gt; the &quot;stable status&quot; for some product. We could define the percentage level (for both cases)<br>
&gt; -- border of percentage that once reached the particular product content should be<br>
&gt; declared as stable. Then there are tricky things like how to express particular benchmark&#39;s<br>
&gt; section is complete? Should various sections have various contribution to the final result /<br>
&gt; stamp for content for particular product?<br>
&gt;<br>
&gt; Maybe they are other ways how to measure stability of a content for particular product<br>
&gt; (if you have proposals for other different metrics feel free to share them).<br>
&gt;<br>
&gt; To implement these metrics it might take some additional time / effort, but at the end it<br>
&gt; could allow us to support expressions about stability of the product with scientific methods.<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; Then, based on having a versioning policy, its desirable to overlay that with<br>
&gt;&gt; goals. What are the goals for 0.2? 0.3? 1.0?<br>
&gt;<br>
&gt; Here again. These are white places on the map for now. Not able to tell how would<br>
&gt; v0.3 be different from v0.2 -- is it just v0.3 would have more rules implemented, more<br>
&gt; tests equipped with attestations, more products supported? Or would we want to differentiate<br>
&gt; also based on the features? If so, what features would be the key ones the presence of them<br>
&gt; by themselves to be sufficient enough for claiming new major version?<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; As the project grows in importance, these need to be documented so that<br>
&gt;&gt; consumers know what to expect.<br>
&gt;<br>
&gt; Agree on the need of these to be explicitly expressed (if not now yet, they<br>
&gt; will definitely be needed with more urgency in the future).<br>
&gt;<br>
&gt; Thank you &amp;&amp; Regards, Jan.<br>
&gt; --<br>
&gt; Jan iankko Lieskovsky / Red Hat Security Technologies Team<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; -Steve<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;&gt; and since we are hitting the doubt if already make / not to make yet a new<br>
&gt;&gt;&gt; release each time (each couple of weeks), we have decided to share the idea<br>
&gt;&gt;&gt; about SSG release process proposal.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;  The proposal is to have release of new tarballs to happen at regular time<br>
&gt;&gt;&gt; (each 4 up to 6 weeks), and have a dedicated wiki page listing when the<br>
&gt;&gt;&gt; couple of upcoming releases will happen [1]. Something like Mozilla is<br>
&gt;&gt;&gt; doing for their products: <a href="https://wiki.mozilla.org/Releases" target="_blank">https://wiki.mozilla.org/Releases</a><br>
&gt;&gt;&gt;  <a href="https://wiki.mozilla.org/Releases#Upcoming_Releases" target="_blank">https://wiki.mozilla.org/Releases#Upcoming_Releases</a><br>
&gt;&gt;&gt;  <a href="https://wiki.mozilla.org/RapidRelease/Calendar" target="_blank">https://wiki.mozilla.org/RapidRelease/Calendar</a><br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;  From the observation period of 6 weeks is enough to have &quot;sufficient<br>
&gt;&gt;&gt;  count<br>
&gt;&gt;&gt; of new bug fixes / features requests&quot; (aka the evolution step) these<br>
&gt;&gt;&gt; changes by themselves to form a need of a new release. But since it&#39;s<br>
&gt;&gt;&gt; difficult to decide if some patchset deserves new release (what&#39;s very<br>
&gt;&gt;&gt; valuable for someone, might not be that exciting / urgent for someone else<br>
&gt;&gt;&gt; etc.) to be fair we decided regular release period might be the best option<br>
&gt;&gt;&gt; how to balance out the various requests that might come out.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;  Therefore starting from the next release we would like the release to<br>
&gt;&gt;&gt; happen regularly (each 4 up to 6 weeks - this to be decided yet. Feel free<br>
&gt;&gt;&gt; to vote for your preferences) at a date listed on the wiki page [2]. This<br>
&gt;&gt;&gt; could allow us establish automated functionality which could in<br>
&gt;&gt;&gt; sufficiently ahead period of time (for example week ago) notify the list<br>
&gt;&gt;&gt; the new release is coming and if someone is planning from their point of<br>
&gt;&gt;&gt; view critical patches to be included yet, those should be proposed /<br>
&gt;&gt;&gt; reviewed as soon as possible.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;  To express personal opinion I would prefer the releases to happen on per<br>
&gt;&gt;&gt;  4<br>
&gt;&gt;&gt; week scenario (while 6 weeks window might produce more changes in the<br>
&gt;&gt;&gt; tarball &amp; less releases during the year at the end it also introduces some<br>
&gt;&gt;&gt; related inconsistency - one time the release would happen at start of the<br>
&gt;&gt;&gt; month, next time in the middle etc.) since it has the advantage the release<br>
&gt;&gt;&gt; will happen each time at regular (same) period, so users can update their<br>
&gt;&gt;&gt; functionality to better align upgrades with the schedule.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;  Yet, since majority of us works on various / multiple projects, it might<br>
&gt;&gt;&gt; happen start of the week might not be the right time for new release<br>
&gt;&gt;&gt; (urgent action required somewhere else resulting into delay of a release<br>
&gt;&gt;&gt; etc.). Therefore I would propose the release to happen each first Friday in<br>
&gt;&gt;&gt; the month (the users could use the upcoming weekend to install the updates<br>
&gt;&gt;&gt; if / where appropriate).<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Feedback, comments, votes, proposals welcome.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Thank you &amp;&amp; Regards, Jan.<br>
&gt;&gt;&gt; --<br>
&gt;&gt;&gt; Jan iankko Lieskovsky / Red Hat Security Technologies Team (on behalf of<br>
&gt;&gt;&gt; SSG<br>
&gt;&gt;&gt; upstream)<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; [1] For now the wiki would contain just dates of past releases &amp; dates of<br>
&gt;&gt;&gt; the upcoming ones (possibly also describing the release scheme). In the<br>
&gt;&gt;&gt; future it could provide further information what functionality each of the<br>
&gt;&gt;&gt; releases introduced (and taking it to the very advanced level hopefully too<br>
&gt;&gt;&gt; which functionality the new releases will contain in the future).<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; [2] Once the scheme is clear (the proposal is approved), I will create that<br>
&gt;&gt;&gt; wiki page. _______________________________________________<br>
&gt;&gt;&gt; scap-security-guide mailing list<br>
&gt;&gt;&gt; <a href="mailto:scap-security-guide@lists.fedorahosted.org">scap-security-guide@lists.fedorahosted.org</a><br>
&gt;&gt;&gt; <a href="https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide" target="_blank">https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide</a><br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt; _______________________________________________<br>
&gt; scap-security-guide mailing list<br>
&gt; <a href="mailto:scap-security-guide@lists.fedorahosted.org">scap-security-guide@lists.fedorahosted.org</a><br>
&gt; <a href="https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide" target="_blank">https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide</a><br>
<br>
</div></div>I agree that a time based release makes the most sense.  I additionally think that a monthly release, either the first Friday or last Friday makes a lot of sense.  Presumably a release on a Friday would mean a new package by the following Friday.  2 weeks in testing for EPEL (until shipped with RHEL) would mean the package would be ready for general consumption 3-4 weeks later.  Bleeding edge consumers could help test the package and more risk adverse consumers could continue testing and just remain a month or more behind in releases.<br>

<br>
As far as versioning is concerned, I believe there should be more discussion around it and what the different versions mean.  I don’t think this should interfere with the decision on a time-based release schedule.<br>
<br>
Just my 0.02.<br>
<span class="HOEnZb"><font color="#888888"><br>
-josh<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
scap-security-guide mailing list<br>
<a href="mailto:scap-security-guide@lists.fedorahosted.org">scap-security-guide@lists.fedorahosted.org</a><br>
<a href="https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide" target="_blank">https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide</a><br>
</div></div></blockquote></div><br></div>