<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix"><br>
      FWIW <br>
      <ul style="color: rgb(0, 0, 0); font-family: 'Times New Roman';
        font-size: medium; font-style: normal; font-variant: normal;
        font-weight: normal; letter-spacing: normal; line-height:
        normal; orphans: auto; text-align: start; text-indent: 0px;
        text-transform: none; white-space: normal; widows: auto;
        word-spacing: 0px; -webkit-text-stroke-width: 0px;">
        <li>2012-12-20:<span class="Apple-converted-space"> </span><a
            href="ftp://sourceware.org/pub/newlib/newlib-2.0.0.tar.gz">newlib-2.0.0.tar.gz</a><span
            class="Apple-converted-space"> </span>(15MB)</li>
        <li>2011-12-19:<span class="Apple-converted-space"> </span><a
            href="ftp://sourceware.org/pub/newlib/newlib-1.20.0.tar.gz">newlib-1.20.0.tar.gz</a><span
            class="Apple-converted-space"> </span>(14.5MB)</li>
        <li>2010-12-16:<span class="Apple-converted-space"> </span><a
            href="ftp://sourceware.org/pub/newlib/newlib-1.19.0.tar.gz">newlib-1.19.0.tar.gz</a><span
            class="Apple-converted-space"> </span>(14.3MB)</li>
      </ul>
      newlib 1.20.0 was released almost 20 months ago. <br>
      newlib 2.0.0 was released about 8 months ago.<br>
      <br>
      The diff in git is dated March 2013. Newlib has been<br>
      very active. Everything from the RTEMS Community <br>
      SHOULD have been submitted.   <br>
      <br>
      FWIW I hacked on diff. Started at 70K. Being brutal...<br>
      I threw away generated files, ChangeLog changes,<br>
      license text changes, new ports (some RTEMS doesn't<br>
      even support), and libgloss changes and got it down<br>
      to 20.8K lines.<br>
      <br>
      If there is anything in this patch worth using, the author<br>
      of the patch should speak up. Otherwise, I personally<br>
      am writing if off as a cvs diff on an arbitrary date and<br>
      ignoring it.<br>
      <br>
      On 7/16/2013 2:51 PM, Rempel, Cynthia wrote:<br>
    </div>
    <blockquote
cite="mid:ba143a9869b94fe6baa8100ed4ba0865@BY2PR04MB189.namprd04.prod.outlook.com"
      type="cite">
      <blockquote type="cite">
        <pre wrap="">________________________________________
From: <a class="moz-txt-link-abbreviated" href="mailto:gedare@gwmail.gwu.edu">gedare@gwmail.gwu.edu</a> [<a class="moz-txt-link-abbreviated" href="mailto:gedare@gwmail.gwu.edu">gedare@gwmail.gwu.edu</a>] on behalf of Gedare Bloom [<a class="moz-txt-link-abbreviated" href="mailto:gedare@rtems.org">gedare@rtems.org</a>]
Sent: Tuesday, July 16, 2013 8:46 AM
To: Rempel, Cynthia
Cc: Sebastian Huber; RTEMS
Subject: Re: Tool chain for RTEMS 4.11

Sebastian, are you proposing to submit the tool patches to the
rtems-devel list, or are you expecting/hoping that someone else will?
</pre>
      </blockquote>
      <pre wrap="">FWIW, I think we'd need a strategy for breaking up the gigantic newlib patch (if we want to try to upstream it)... 
probably need to use scripts... 
some steps for dealing with the patch that come to mind are:
1. split the patch up by the files being patched
2. throw out patches that apply to files that are autogenerated (such as configure)
3. throw out all diffs that were already applied
4. estimate the number of patches left to consider
It may turn out not to be that many lines of code to review...

</pre>
      <blockquote type="cite">
        <pre wrap="">Cindy (and others): A feature freeze is fine to talk about, but I
don't think we need an actual freeze. We can just cut a 4.11 branch
and treat it as a (pre)release branch with release branch rules---bug
fixes only. Then the git master branch can continue development under
the next version cycle.
</pre>
      </blockquote>
      <pre wrap="">Not slowing down development sounds great :) Yeah! We could do the branching at any time then...
Although before we do, we may want to think about if we want to wait a little longer for a lull in the development cycle (i.e. after the Summer of Code)... 
We could also consider putting the release procedures in asciidoc (or some other standard) format in rtems.git and rtems-tools.git...
</pre>
      <blockquote type="cite">
        <pre wrap="">-Gedare
</pre>
      </blockquote>
      <pre wrap="">

_______________________________________________
rtems-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rtems-devel@rtems.org">rtems-devel@rtems.org</a>
<a class="moz-txt-link-freetext" href="http://www.rtems.org/mailman/listinfo/rtems-devel">http://www.rtems.org/mailman/listinfo/rtems-devel</a>
</pre>
    </blockquote>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Joel Sherrill, Ph.D.             Director of Research & Development 
<a class="moz-txt-link-abbreviated" href="mailto:joel.sherrill@OARcorp.com">joel.sherrill@OARcorp.com</a>        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805 
Support Available                (256) 722-9985 </pre>
  </body>
</html>