Tool chain for RTEMS 4.11

[Gedare Bloom]

Sebastian, are you proposing to submit the tool patches to the
rtems-devel list, or are you expecting/hoping that someone else will?

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.

-Gedare

On Tue, Jul 16, 2013 at 11:34 AM, Rempel, Cynthia
<cynt6007 at vandals.uidaho.edu> wrote:
> I agree. We need to agree on toolchain versions before rolling out with a release, and we really want as many patches as feasible upstreamed as soon as feasible (to maximize the probability they will be commited) and, where feasible, we want toolchains for the targets to be up-to-date as well.
>
> I know in the past some of the targets require special versions, so for the targets that still have problems during the feature freeze, we'll have to adjust for needing special toolchain versions.  So I would like to propose before settling on which version to use for a given target, we verify the current toolchain version works... and if not, we make a determination of the most current version that does work.
>
> Moving forward we should keep patches separated in such a way as they are easier to "upstream", this will require an update to the http://www.rtems.org/wiki/index.php/Building_Tools tutorial, but hopefully, updating the tutorial won't be too difficult.
>
> We really do want just one set of patches, as opposed to having rpms and rtems-tools (and that all pathces out for users have been submitted for upstreaming)...
>
> I also would like to propose we set a TENTATIVE feature freeze for the RTEMS kernel of Mid-October, through Mid-November -- if we integrate Summer of Code contibutions as we go, this will be enough time to integrate the features before we freeze them... then we could schedule the release to happen before contributions pick up over the holidays... with Mid-November as the TENTATIVE release date... this would also increase the probability that the tool chain patches we have now will be in the upcoming releases of the tools.  This would mean features could be added until Mid-October...
>
> Thanks,
> Cindy
>
>
> ________________________________________
> From: rtems-devel-bounces at rtems.org [rtems-devel-bounces at rtems.org] on behalf of Sebastian Huber [sebastian.huber at embedded-brains.de]
> Sent: Tuesday, July 16, 2013 5:11 AM
> To: RTEMS
> Subject: Tool chain for RTEMS 4.11
>
> Hello,
>
> before we release RTEMS 4.11 we have to agree on the tool chain versions
> (Binutils, GCC, Newlib, GDB).  Currently the RTEMS developers are a bit divided
> with respect to the tool chain in use.  We have the RTEMS source builder based
> versions and we have the RPM based ones.
>
> The RPM based ones use patches which can be found here:
>
> http://git.rtems.org/rtems-crossrpms/tree/patches
>
> The Newlib patch is quite huge and an explanation for it can be found here:
>
> http://www.rtems.org/pipermail/rtems-devel/2013-March/002686.html
>
> I propose the following actions:
>
> 1. Submit all RTEMS tool chain patches for review to the rtems-devel list.  The
> time frame for this should be two weeks.
>
> 2. After review (after two weeks without response assume that the patch is all
> right) submit the patches for upstream integration.  Patches from people
> without a FSF copyright assignment are problematic here.
>
> 3. After all patches are integrated upstream select an upstream snapshot
> version for the RTEMS tool chain release candidate.
>
> 4. Propagate the changes to the developers.
>
> 5. Adjust the RTEMS sources accordingly.
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax     : +49 89 189 47 41-09
> E-Mail  : sebastian.huber at embedded-brains.de
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel
>
>
>
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel