On 23/11/2015 11:11 AM, Joel Sherrill wrote: > > On Sun, Nov 22, 2015 at 4:14 PM, Chris Johns <chr...@rtems.org > <mailto:chr...@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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
