Release repos

[Chris Johns]

On 28/05/2015 12:25 am, Joel Sherrill wrote:
> 
> 
> On 5/27/2015 9:06 AM, Gedare Bloom wrote:
>> I want to clarify what repos need to be synchronized (or eventually
>> tagged) with an RTEMS release. Currently we know (from [1]) the
>> following must:
>> rtems
>> examples-v2
>> network-demos
>> rtems-testing
>> rtems-tools
>> rtems-source-builder
>>
>> We don't know about:
>> rtems-libbsd
>> rtems-addon-packages
> 
> I would like to avoid including this. I have patches ready and it
> does build for all. But I am hoping to get the packages into RSB
> and eliminate it.
> 
>> rtems-graphics-toolkit
> 
> I haven't done any test builds on this.
> 
>> My suspicion is that libbsd should get a tag or branch for a release,
>> in case updates/new features added to it can break the release build.
>> Advice?
>>
> 
> I am also suspicious that it needs to be in sync with tool and RTEMS .h
> files.
> 

I think the policy should be a release tag in a repo means we create a
source tarball and that lives in the release directory. If the tag is
common to a number of repos, eg the RTEMS release tag, the packages
tagged need to exist along side each other.

The follow on from this is the release of a package needs correct ticket
tracking and dot releases. The side effect of adding more repos to the
list is increasing the amount of work we need to do for a release
because everything needs to line up plus it limits a fast moving package
by adding dependences across all the packages.

I feel libbsd is still a work in progress and I am not sure it is ready
to be formally managed in this way.

The second policy issue this leads to is the how we manage the 3rd party
RTEMS packages of which libbsd is one. The repo release tagging and
source tarball means the release cycle of that package is the RTEMS
kernel release cycle. The other point of view is a 3rd party package is
on a separate release cycle. This means that package needs to make a
choice on how it manages compatibility with RTEMS. It might mean a
certain number of libbsd releases run on RTEMS 4.11 then after a while
it requires a later kernel if it cannot maintain backward compatibility.

The only downside of separate release cycles for a range of packages is
the added complexity for users. I wonder if the RSB can help here where
an RSB release provides the tested versions of the 3rd party packages.

The final comment I have is the RSB is currently pulling rtems-tools and
RTEMS from git. It should use the released source however I do not have
a release to test against and so have not done anything about it. I
think I will wait for the release then update the RSB and make that
change available in a dot release.

Chris

>> It would also be good to eventually get tags for versions of the addon
>> and graphics toolkit that are "good" for a release also, to dissociate
>> any further developments. Alternately, we should avoid introducing
>> regressions to those repos that cause breakage with
>> released/maintained versions of RTEMS, i.e. 4.10 and 4.11 after this
>> release.
>>
>> Did I miss any?
>>
>> Gedare
>>
>> [1]
>> https://devel.rtems.org/wiki/Developer/Release#RTEMSReleaseRepositories
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>>
>