Release sources

[Chris Johns]

On 2020-03-27 03:43, Joel Sherrill wrote:
> On Thu, Mar 26, 2020 at 11:04 AM Gedare Bloom <gedare at rtems.org 
> <mailto:gedare at rtems.org>> wrote:
>     On Thu, Mar 26, 2020 at 9:40 AM Joel Sherrill <joel at rtems.org
>     <mailto:joel at rtems.org>> wrote:
>      > On Thu, Mar 26, 2020 at 10:17 AM Gedare Bloom <gedare at rtems.org
>     <mailto:gedare at rtems.org>> wrote:
>      >> On Thu, Mar 26, 2020 at 7:28 AM Joel Sherrill <joel at rtems.org
>     <mailto:joel at rtems.org>> wrote:
>      >> > On Thu, Mar 26, 2020 at 2:26 AM Sebastian Huber
>     <sebastian.huber at embedded-brains.de
>     <mailto:sebastian.huber at embedded-brains.de>> wrote:
>      >> >> On 26/03/2020 07:54, Chris Johns wrote:
>      >> >> On 2020-03-20 14:57, Chris Johns wrote:
>      >> >> Only having sources in `sources` is a change from how RTEMS
>     has been released in
>      >> >> the past so I feel this needs to be discussed and approved
>     before I make any
>      >> >> changes.
>      >> >>
>      >> >>
>      >> >> I will place all source in `sources`.
>      >> >>
>      >> >> Sorry I missed this email. Placing the sources in a directory
>     is an improvement from my point of view.
>      >> >
>      >> +1
>      >>
>      >> >
>      >> > Does this mean you will end up with one source tarball with
>     every repo in it?
>      >> >
>      >> A release contains basically a snapshot of all source code that goes
>      >> into it, including tools. The 'sources' directory will contain
>     all of
>      >> those snapshots, each one a tarball of the respective source (e.g.,
>      >> automake-x.y.z, rtems-x.y, etc.).
>      >>
>      >> Look at the 4.11.3 release for an example of how it was being done:
>      >> https://ftp.rtems.org/pub/rtems/releases/4.11/4.11.3/
>      >>
>      >> See that there is a sources directory, but that we also put "our"
>      >> source in the top-level. Chris' plan is to also put the
>     rtems-*.tar.xz
>      >> underneath sources/
>      >
>      >
>      > Hmm.. Why would we mix RTEMS originated source packages with
>      > third party source and patches. This directory is already quite
>     lengthy.
>      >
>      > I must have missed the clear statement of what the advantage is.

I pushed on because no one said anything so I assumed the change was fine.

Currently the source for a release is in two places, the `sources` 
directory, and the top level directory. This means the RSB has to be 
configured with both paths in a release. If the source being fetched is 
in the top level directory it has to look into the `sources` directory 
and fail before moving to the next path in the configured list, i.e. the 
top level directory. This generates an error message and this can be 
confusing to our users.

I am looking into the detail and I will try all the source in the one 
directory.

>     The advantage is that all the source that belongs to the release is
>     consolidated. all rtems packages are prepended by rtems- so they are
>     still easily identifiable in the sources subdirectory.
> 
>     Ideally, the readme will simply direct the user to run the
>     script/command necessary to build things :) I think this is simpler,
>     and users will still be able to find specific sources as they need by
>     looking in one place.
> 
> 
> Then the readme for the release should have some basic information
> for pointing into this and finding instructions to build for a target. Not
> much more than pointing into telling them to (hopefully) untar the
> docs and start at section X in the Users Guide for host setup and
> section Y for building the RTEMS Ecosystem.

This is the current README.txt ...

https://git.rtems.org/rtems-release/tree/README.txt.in

The Release Files section will need to change and the documentation will 
also need to change. I will trial a snapshot before looking to update 
the documentation.

> Assuming the readme gets people one link down the chain into the
> Users Guide and the Users Guide is complete from there.

I am not sure what this means. Are you able to clone releases repo and 
show me how you do this?

Chris

>      >> (I discussed with him briefly before, and am in favor of this
>      >> approach, but held my vote :))
>      >>
>      >> > --joel