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