Release sources

[Joel Sherrill]

On Thu, Mar 26, 2020 at 11:04 AM Gedare Bloom <gedare at rtems.org> wrote:

> On Thu, Mar 26, 2020 at 9:40 AM Joel Sherrill <joel at rtems.org> wrote:
> >
> >
> >
> > On Thu, Mar 26, 2020 at 10:17 AM Gedare Bloom <gedare at rtems.org> wrote:
> >>
> >> On Thu, Mar 26, 2020 at 7:28 AM Joel Sherrill <joel at rtems.org> wrote:
> >> >
> >> >
> >> >
> >> > On Thu, Mar 26, 2020 at 2:26 AM Sebastian Huber <
> 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.
> >
>
> 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.

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

>
> >>
> >> (I discussed with him briefly before, and am in favor of this
> >> approach, but held my vote :))
> >>
> >> > --joel
> >> >
> >> >>
> >> >> _______________________________________________
> >> >> devel mailing list
> >> >> devel at rtems.org
> >> >> http://lists.rtems.org/mailman/listinfo/devel
> >> >
> >> > _______________________________________________
> >> > devel mailing list
> >> > devel at rtems.org
> >> > http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200326/8e759df2/attachment-0001.html>