>________________________________________ >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
