Fwd: [rtems-source-builder] Various bugfixes for building rtems 4.9,4.10,4.11 and 4.12 (#5)

[Chris Johns]

On 23/11/2015 11:11 AM, Joel Sherrill wrote:
> 
> On Sun, Nov 22, 2015 at 4:14 PM, Chris Johns <chrisj at rtems.org
> <mailto:chrisj at rtems.org>> wrote:
> 
>     On 21/11/2015 1:40 AM, Joel Sherrill wrote:
>     > I got this pull request from github and wanted to pass it along.
> 
>     This is a great patch with some small issues. I will respond in the
>     ticket (https://devel.rtems.org/ticket/2475).
> 
>     The patch means 4.9, 4.10, 4.11 and 4.12 can be built with a single RSB
>     version which is nice. Do we want to strip the 4.9, 4.10, and 4.11
>     versions out to make this a single version for 4.12 or do we maintain
>     the original intent of using files with in the RSB to manage this?
> 
> Short term, I think we maintain the current way of doing it. This may or
> may not be a burden going forward.

The branch has been created for 4.11 so the process has already started.

> I can see that it could ease our maintenance burden to have one RSB
> tarball that supports multiple release branches.

This opens up release cross talk which can be more of an issue over
time. I am not sure.

> On the other hand, we have some testing obligation if scripting
> infrastructure changes. Would we always apply the best scripting
> infrastructure to the other branches? If so, then the current case is
> easiest.

Release branches means we only need to test 4.9 specific changes on the
4.9 release branch. I think this will help.

> I can see wanting to fix bugs on some hosts, add your license tags, etc.
> and those
> would have to be propagated to all branches. 

Yes getting the license tags in first is a good idea.

>  
> 
>     I am still in favour of stripping the versions but it means we should
>     release 4.9, 4.10 and 4.11 as tarballs with release branches in git. The
>     4.9 and 4.10 would start at the same point as 4.11 and retain all the
>     versions. I see no need to strip them.
> 
> 
> In practical terms, I don't see any reason to worry about separate branches.

How do we create a tarball for a release? If we do this does it have a
tag and so a release branch? I feel we will end up with release branches
and if we have them do we need to force the maintenance of all releases
across all release branches? I doubt we will.

> We probably always want the best infrastructure. And it we want to keep
> hosts
> moving forward, we will end up wanting to back port patches frequently.

Would we be moving 4.11 to gcc-6? I just do not know but the
gcc-common.cfg could result in cross-talk.

> 
> I guess we just need to make sure we address the testing properly. 
> 

Yes.

Chris