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

[Chris Johns]

On 19/2/19 12:55 am, Sebastian Huber wrote:
>> We should also see what the issue is supporting https access and resolve it one
>> way or the other. I will update the ticket adding a link to these posts.
> 
> The HTTPS clone works also with the rtems.org server, but it lacks user feedback
> and is quite slow.

Yes. It must be related to the cgit web interface we run after all it owns port
80 or what ever the https port is. After that I am not sure. I tried to find
references to git behaving this way but I could not find anything useful. I
would be happy to ask on the cgit list however I think running the latest
version would be a good first step before heading over there.

>> In relation to github, having read-only updated versions of our repos hosted
>> there is fine but github is a company and we have no insight, access or ability
>> to sway what they do and what they provide so you will have a hard time
>> convincing me we should have those repos documented in a our user manuals as the
>> primary location to get RTEMS from.
> 
> For some users the Github mirror is currently the only stable way to clone the
> RTEMS repositories.

I understand and this is important. We need to make sure we our project and its
services are first in the list and preferred.

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

Chris