[PATCH v2 04/10] user: Add "Obtain the Sources" section

[Sebastian Huber]

On 19/02/2019 02:20, Chris Johns wrote:
> On 19/2/19 12:55 am, Sebastian Huber wrote:
> [...]
>>> This also rolls into the issue of releases and I feel the the user manual should
>>> focus on the tar files for releases and git access as a means of accessing
>>> releases should be moved to an advanced topic. I am happy to leave what is in
>>> the patch about this until we have our house in order and a release candidate
>>> has been created. It is only tar balls that have a proper RTEMS version string,
>>> git builds from the release branch or a tag will not. I will step hard on anyone
>>> deploying and creating a release where the version string matches an existing or
>>> future RTEMS version string.
>> Even with frequent releases, I would recommend to clone the Git repositories.
> There are different views and some orgs and users will prefer a tarball that is
> a specific version. There is a simplified trust framework that results from
> using a release.
>
>> I
>> thought that a release is just a certain Git commit (the only one with the
>> release version) with a bootstrap packed as an archive?
> A release is more, it is a complete collection of pieces we say will work
> together. Yes, the rtems-<ver>.tar.xz is as you state, plus it has a change to
> set the version string
> (https://git.rtems.org/rtems-release/tree/rtems-release-kernel#n85). A release
> also contains ready to use documentation as HTML and PDF, doxygen, examples,
> packages, and every piece of source. A build of a release fetches all source
> from RTEMS's servers which means the release is not effected by changes
> referenced projects make in their sites over time.
>
> A release as provided on our ftp host server is complete. A download of that
> directory of files should be all you need. A user does not need to learn all the
> relationships and details across all our parts, packages, configuration etc to
> use RTEMS. They can trust the release as a black box packages without needing to
> look inside at how it was arrived at.
>
> I am not discounting the value a git based process can have, however across all
> of RTEMS's life formal releases are tarballs and we should document and promote
> this before alternatives. I feel any change to this policy should be discussed
> away from a documentation change. We need to reflect what we have and that is
> all I am saying here. :)

Ok, I think we should add this content somewhere to the user manual as 
background information Git clones vs. release archives.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.