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

[Chris Johns]

On 13/2/19 7:41 am, Joel Sherrill wrote:
> 
> 
> On Tue, Feb 12, 2019 at 12:18 AM Sebastian Huber
> <sebastian.huber at embedded-brains.de <mailto:sebastian.huber at embedded-brains.de>>
> wrote:
> 
>     On 12/02/2019 03:48, Chris Johns wrote:
>     >> We chose
>     >> +:file:`$HOME/quick-start/rtems/5` as the installation prefix.
>     >> +
>     >> +You need at least two source archives or Git repositories to work with
>     RTEMS.
>     >> +You can download the source archives for a released RTEMS version or you can
>     >> +clone Git repositories to get all versions of RTEMS including the
>     development
>     >> +head.
>     >> +
>     >> +We will clone the Git repositories into :file:`$HOME/quick-start/src`.
>     >> +
>     >> +.. code-block:: none
>     >> +
>     >> +    mkdir -p $HOME/quick-start/src
>     >> +    cd $HOME/quick-start/src
>     >> +    git clonehttps://git.rtems.git/rtems-source-builder  rsb
>     >> +    git clonehttps://git.rtems.git/rtems
>     > I feel we need the https access to git fixed for this to be in the doco. I
>     have
>     > no idea how to sort this out. We have and are supporting git:// so may be this
>     > should be documented and the alternative added as helper for those who
>     cannot to
>     > git via the git protocol?
> 
>     We should fix our HTTPS clone support or use Github as the default
>     source for read-only clones.
> 
> 
> Is there a ticket for supporting https clones?

Yes it is https://devel.rtems.org/ticket/3683

>  
> 
>     From my point of view offering the Git
>     protocol is user unfriendly. The clone via HTTPS works everywhere, even
>     behind firewalls and proxies.
> 
> 
> Perhaps a word is missing in your response. 
> 
> Some have to use https and we should support it. I wouldn't recommend it
> as a first choice. If someone doesn't have to use it, then they should use the
> native git protocol.

I have considered this over night and realised we currently fully support the
git protocol from our servers. Until we have a fully working https access to our
repos on our servers I feel we need to document what we have which is the git
protocol. A note or sidebar about https is something we should have, it is
important for some users.

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.

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.

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.

Finally if our servers are not doing what users want then please ask how you can
help or help by funding work to get things done on them. Yes https access for
git is an issue but I consider having IRC logs or automatically updating doxygen
reports online as more important tasks.

Chris