Release team now using gnome-build-meta repository, not JHBuild

[Tristan Van Berkom <tristan vanberkom codethink co uk>]

Hi,

The time has come, the Release Team is now maintaining the GNOME
releases in BuildStream format, which is now available at:

    https://gitlab.gnome.org/GNOME/gnome-build-meta

This repo is intended to contain the build metadata required for
building the GNOME core modules only, while many applications have been
migrated to Flatpak.

In the near future, Jürg Billeter will be landing his work[0] on
finally allowing BuildStream projects to depend on eachother, this will
allow people to create projects which depend on `gnome-build-meta`,
which will be a suitable approach for building things which are not a
part of the "core" category in GNOME.

Instructions for using the gnome-build-meta BuildStream project can be
found at:

    https://wiki.gnome.org/Newcomers/BuildSystemComponent


JHBuild
-------
For what regards the upcomming 3.28 release and further, patches should
go to the gnome-build-meta project instead of the JHBuild modulesets -
otherwise these patches would not be considered in the releases we are
building.

As agreed upon in this previous thread[1], changes in gnome-build-meta
can be backported to the JHBuild modulesets while they remain on "life
support".


Issues
------
Whenever you encounter a problem or hinderance in your workflow, please
let us know at either of the below trackers, depending on the nature of
your issue:

    GNOME Build Metadata problems:
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    https://gitlab.gnome.org/GNOME/gnome-build-meta/issues

    BuildStream problems:
    ~~~~~~~~~~~~~~~~~~~~~
    https://gitlab.com/BuildStream/buildstream/issues


At this time, I am aware of a few problems and inconveniences and we
are working hard on improving things as the project evolves and we
learn about new issues.

The hot topics I am aware of so far include:

  o Inconvenience when pulling changes from the gnome-build-meta
    repository.

    As is described in the newcomers wiki page[2], BuildStream rewrites
    the project when fetching the latest commits on any given branch,
    making it inconvenient when you want to pull new changes in the
    metadata itsef (e.g. fixes to configure flags or dependencies,
    additions of modules etc.).

    A solution for this is under way[3].

  o Testing of modules which need integration with your host.

    Some applications want to access resources which are highly
    host specific, or require access to the internet to really
    try out (e.g. epiphany). This doesnt always work out of the
    box in an isolated `bst shell` environment with a base runtime
    that may bear no resemblance to your actual host.

    For the internet, it should be enough to setup a resolv.conf,
    we should be able to bake this in pretty easily, other things
    like access to pulse audio prove more difficult to address
    without reimplementing Flatpak and portals.

    The ultimate solution for this will be generating VM images
    of what is really the "latest GNOME" (or more accurately,
    the "exact version" of GNOME you wanted to build).

    At the same time, I am considering allowing a project to create
    "shell profiles" which can make `bst shell` more useful for more
    resource intensive applications (perhaps by giving some control
    as to what the shell can inherit from the host in terms of
    environment variables and such like).

  o Integration with Builder

    Christian has raised a list of features and points[4] to ensure
    a great UX (or DX) which we will be considering and allocating
    resources to address.


Cheers,
    -Tristan


[0]: https://gitlab.com/BuildStream/buildstream/merge_requests/160
[1]: https://mail.gnome.org/archives/desktop-devel-list/2017-November/msg00036.html
[2]: https://wiki.gnome.org/Newcomers/BuildSystemComponent#Fetching_the_latest_build_metadata
[3]: https://mail.gnome.org/archives/buildstream-list/2018-January/msg00005.html
[4]: https://mail.gnome.org/archives/buildstream-list/2017-November/msg00046.html