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

[Sebastian Huber]

On 12/02/2019 22:21, Chris Johns wrote:
> 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.

The HTTPS clone works also with the rtems.org server, but it lacks user 
feedback and is quite slow.

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

>
> 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. 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?

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