<div dir="ltr"><div><div>Hi guys,<br><br></div>Better a bit later and stable than doing all the work double again :-) You all do good work though trying to get a nice outcome :-) Do not get yourself a burnout just to be the fastest, rather go for quality :-)<br>
<br></div>Best regards,<br>Hans<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/12/19 Kris Moore <span dir="ltr"><<a href="mailto:kris@pcbsd.org" target="_blank">kris@pcbsd.org</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><div><div class="h5">
    <div>On 12/18/2013 12:33, Joe Maloney wrote:<br>
    </div>
    <blockquote type="cite">
      
      
      On Wed, 2013-12-18 at 11:07 -0500, Kris Moore wrote:
      <blockquote type="CITE">
        <pre>On 12/18/2013 07:44, Claudio L. wrote:
<font color="#737373">></font>
<font color="#737373">> On 12/17/2013 14:55, Joe Maloney wrote:</font>
<font color="#737373">>> This also seems like a good idea to me if it doesn't cause too much</font>
<font color="#737373">>> overhead or slow the project down a bunch I suppose. </font>
<font color="#737373">></font>
<font color="#737373">> Good point, we don't want to increase overhead. But if it's done in an</font>
<font color="#737373">> organized way it can actually be done without putting too much extra</font>
<font color="#737373">> work.</font>
<font color="#737373">></font>
<font color="#737373">> For example:</font>
<font color="#737373">> * Let's say the 1st of each month they do a "package freeze", where</font>
<font color="#737373">> they select the packages that will be pushed in the next cycle.</font>
<font color="#737373">> * The 15th of the month they finish preparing the set of packages and</font>
<font color="#737373">> it gets pushed out to one branch.</font>
<font color="#737373">> * There's 1 and a half months to fix any problems with this set of</font>
<font color="#737373">> packages. And if a package can't be fixed within this time, it is</font>
<font color="#737373">> removed from the set.</font>
<font color="#737373">> * The last day of the second month, they push the package set out to</font>
<font color="#737373">> the more stable branch.</font>
<font color="#737373">> * ... and it loops ad infinitum...</font>
<font color="#737373">></font>
<font color="#737373">> So they reduce the frequency of packages to a 2-month cycle, that</font>
<font color="#737373">> should help Kris et al. to pace themselves (vs. the frenzy they have</font>
<font color="#737373">> today with a monthly cycle or even faster), and we get a second branch</font>
<font color="#737373">> with relatively low effort and a more polished set of packages.</font>
<font color="#737373">> The 2-month cycle would introduce a delay of up to 2 months for the</font>
<font color="#737373">> bleeding edge packages and up to 4 months for the stable one (this is</font>
<font color="#737373">> a worst case scenario, for a package that comes out the day after they</font>
<font color="#737373">> do the package freeze). I think it's reasonable.</font>
<font color="#737373">></font>
<font color="#737373">></font>
<font color="#737373">>> That's why I was suggesting security and critical updates for RELEASE</font>
<font color="#737373">>> only.</font>
<font color="#737373">></font>
<font color="#737373">> But that would essentially freeze that branch for its life cycle,</font>
<font color="#737373">> which goes against the idea of a rolling release. In my opinion it</font>
<font color="#737373">> should lag behind the other one, but still roll. The static nature of</font>
<font color="#737373">> FreeBSD gets a lot of criticism and it's one of the differentiating</font>
<font color="#737373">> reasons to use PCBSD (or TrueOS) versus plain FreeBSD.</font>
<font color="#737373">></font>
<font color="#737373">></font>
<font color="#737373">>> That way things like VirtualBox don't get borked when that package</font>
<font color="#737373">>> get's updated. Like it is now. :( I know what you mean about spending</font>
<font color="#737373">>> extra time fixing little things on what should be a production</font>
<font color="#737373">>> system. Perhaps this every 2 months idea could work. I'd still say</font>
<font color="#737373">>> apply the idea you just mentioned about the every 2 months to STABLE,</font>
<font color="#737373">>> and roll a CURRENT release with the more current packages instead</font>
<font color="#737373">>> that can trickle down into STABLE after they have recieved testing.</font>
<font color="#737373">></font>
<font color="#737373">> That's slightly different from what I proposed above, it could work as</font>
<font color="#737373">> well.</font>
<font color="#737373">></font>
<font color="#737373">> Well, the ideas are now out there. I think we did our part, now it's</font>
<font color="#737373">> up to the team to decide if and how they want to implement any of</font>
<font color="#737373">> this. I'm positive that in 2014 we'll get back the stability we need.</font>
<font color="#737373">></font>
<font color="#737373">> Claudio</font>
<font color="#737373">></font>

I think these ideas are great. I also agree 100% with the renaming,
since RELEASE/STABLE is confusing, and I think those terms are best left
to the FreeBSD world/kernel portions. So here's what I think we will do:

1. As mentioned, create new PRODUCTION / EDGE set of packages.
  - Update EDGE every 2~ weeks, depending upon breakage of ports upstream.

  - Update PRODUCTION every quarter
    * One month before release, freeze the most recent EDGE set of ports
    * Begin testing / fixing major ports  - Desktops/VirtualBox, etc
    * Once testing is finished, push out new PRODUCTION set and unfreeze
EDGE again
   
  - Add selection mechanism to system manager GUI, letting you switch
between these sets
 

Does this sound like a reasonable timeframe for us to work on?

</pre>
      </blockquote>
      Sounds good to me.  Will you branch the ports tree on github as
      well for this?  Just curious for pc-sysmanager that I was working
      on whether or not branch detection for ports would need to be
      implemented depending on whether PRODUCTION / EDGE is being used?<br>
      <br>
      Joe Maloney<br>
      <br>
    </blockquote>
    <br></div></div>
    I will probably not branch the source tree, rather just hold off
    updating it until we get a "stable" snapshot build, then tag the
    resulting packages as "PRODUCTION" and upload. <br><div class="im">
    <br>
    <pre cols="72">-- 
Kris Moore
PC-BSD Software
iXsystems</pre>
  </div></div>

<br>_______________________________________________<br>
Testing mailing list<br>
<a href="mailto:Testing@lists.pcbsd.org">Testing@lists.pcbsd.org</a><br>
<a href="http://lists.pcbsd.org/mailman/listinfo/testing" target="_blank">http://lists.pcbsd.org/mailman/listinfo/testing</a><br>
<br></blockquote></div><br></div>