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.hu...@embedded-brains.de <mailto:sebastian.hu...@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.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
