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. 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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
