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

Joel Sherrill joel at rtems.org
Mon Nov 23 00:11:52 UTC 2015


On Sun, Nov 22, 2015 at 4:14 PM, Chris Johns <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.

I can see that it could ease our maintenance burden to have one RSB tarball
that supports multiple release branches.
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.

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.


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

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

>
> Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20151122/33585060/attachment-0002.html>


More information about the devel mailing list