RTEMS Release Snapshots

[Chris Johns]

On 2/11/19 10:01 am, Joel Sherrill wrote:
> 
> 
> On Fri, Nov 1, 2019 at 12:53 PM Gedare Bloom <gedare at rtems.org
> <mailto:gedare at rtems.org>> wrote:
> 
>     Hi Chris et al.,
> 
>     On Thu, Oct 31, 2019 at 12:50 AM Chris Johns <chrisj at rtems.org
>     <mailto:chrisj at rtems.org>> wrote:
>     >
>     > Hello,
>     >
>     > I would like to announce the start of release snapshots from the master
>     branch.
>     > A release snapshot will be created on the first day of each month. These are
>     > development snapshots so they can be unstable.
>     >
>     Thank you for taking this initiative, and I hope these are of only
>     incremental cost for you to produce.

The release scripts seem OK now, it is the next step testing all the hosts and
BSPs and resolving what that finds that is the slow part. This approach is an
attempt to share this part. A broken host or BSP in a release is now a community
issue and not something I have to specifically take care of. We had a catch-22,
the community needs a release to test but we could not create a release without
it being tested.

>     When you say unstable, you mean they are not recommended for use in
>     baselining production for user projects, right?
> 
> We would always prefer users to use "real releases" for products but we
> haven't had enough in recent years. This has effectively forced users to 
> baseline from the git master. So yes, we would prefer and recommend
> that users avoid using non-release versions in production.

This has been docuemnted by Sebastian in the user manual ..

https://docs.rtems.org/branches/master/user/installation/developer.html

The snapshot releases fall under this section as well.

> The purpose of the snapshots are at least to 
> 
> (1) ensure that mechanics of the release process work. For example, 
> Sebastian noticed that the rtems-libbsd for this snapshot is cut from 
> master, not the correct branch. There may also be bugs in inserting 
> the correct version number, collecting all the files etc.
> 
> (2) Give users something to test on their hardware and report back.
> We need this feedback.
> 
> Chris and I hope that based on testing of the snapshots and git master,
> we will reduce the issues to the point where we reach a point that we
> say "snapshot X looks great, let's have a formal release" and that's largely it. 
> 
> This is part of a holistic effort to improve our processes and feedback.
> 
> Hopefully users see value in it and help by testing, volunteering to
> help implement, and contributing funding for needed infrastructure
> and core developers to work on these RTEMS process issues.
> 
>     What about their availability? How long will each release snapshot
>     remain hosted by RTEMS Project for public consumption?
> 
> Chris and I haven't discussed that. He may have thoughts.

The 5.0.0-m1911 is 500M so it is not a lot of space.

> As reference, GCC snapshots appear to be available for about a year with 
> all removed and replaced by one final snapshot as a branch closes (at least 
> that's what it looks like).
> 
> I don't want to keep them available **publicly** forever. There is a tendency
> for people 
> to mirror an entire ftp tree and this just puts load on our server
> infrastructure for
> near zero value.

I am not sure we want to have these snapshots around for ever but it is not yet
clear to me how long we keep them for. We may only hold 12 snapshots across all
versions.

I am OK with mirroring and I think that sort of load compared to the web
crawlers is not too bad. We have a fast connection.

Chris