FWIW
* 2012-12-20:newlib-2.0.0.tar.gz
<ftp://sourceware.org/pub/newlib/newlib-2.0.0.tar.gz>(15MB)
* 2011-12-19:newlib-1.20.0.tar.gz
<ftp://sourceware.org/pub/newlib/newlib-1.20.0.tar.gz>(14.5MB)
* 2010-12-16:newlib-1.19.0.tar.gz
<ftp://sourceware.org/pub/newlib/newlib-1.19.0.tar.gz>(14.3MB)
newlib 1.20.0 was released almost 20 months ago.
newlib 2.0.0 was released about 8 months ago.
The diff in git is dated March 2013. Newlib has been
very active. Everything from the RTEMS Community
SHOULD have been submitted.
FWIW I hacked on diff. Started at 70K. Being brutal...
I threw away generated files, ChangeLog changes,
license text changes, new ports (some RTEMS doesn't
even support), and libgloss changes and got it down
to 20.8K lines.
If there is anything in this patch worth using, the author
of the patch should speak up. Otherwise, I personally
am writing if off as a cvs diff on an arbitrary date and
ignoring it.
On 7/16/2013 2:51 PM, Rempel, Cynthia wrote:
________________________________________
From: ged...@gwmail.gwu.edu [ged...@gwmail.gwu.edu] on behalf of Gedare Bloom
[ged...@rtems.org]
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?
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...
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.
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...
-Gedare
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
