Some helpful info about using these scripts....

There are a few categories of scripts:

- release scripts
  * release.py
  * uninative.py
  * unihash.py (used along with uninative.py for a uninative release)

- release notes generation scripts
  * relnotes.py 

- utils/reused code
  * utils.py 

- useful things
  * get_cves.py  Takes a revision range and spits out the CVES in the git
    log between the revisions. Works for poky. Not intended to necessarily work
    elsewhere. This is handy if you have a release that does not include some CVE
    fixes, but you want to list them in the Known Issues in RELEASENOTES for that
    release. The 2.6 Thud release is an example. This script was used to generate
    the list included in the Known Issues for the Thud release. 
  * get_hashes.py This looks in the RC
    directory and snags the hashes for the various tarballs we release. This
    info is passed to Michael Halstead who uses it for tagging repos. Also just
    generally useful. 
  * rel_type.py This lives in utils.py (definitive version), but is kind of handy by itself
    from time to time. 
  * where_am_i.py This snippet looks at the hostname and make a guess as to what
    path the autobuilder output will be found. The legacy path was
    /srv/www/vhosts. On newer AB clusters, this is now generally /srv/autobuilder.
   There is at least one case where this still applies. This wagers a guess as to
   which one to use based on which cluster we are on. Also lives in utils.py
   (definitive version), but is occasionally useful standalone.

Since usage help is available in each script, it is not included here.

Yocto Release Process
=====================

This section deals with the Yocto release process as it pertains to the tools in
this repo. There are other release activities that happen which outside the
scope of this document. For more information on Yocto releases, please see:
https://wiki.yoctoproject.org/wiki/Yocto_Release_Engineering

Preparing the Release
---------------------

The scripts in this repo do two primary things: prepare the release directory
containing all the release artifacts, and generate the errata and release notes
as needed releases for each type of release (Major, Point or "Dot", and
Milestone). 

Preparing, or "staging," the release entails the following:

 1) Rsync the rc candidate to a staging dir where all work happens. We NEVER
touch the actual RC directory, for safety, in case something goes wrong.
  
2) Convert the symlinks in build-appliance dir. The build creates symlinks in
some places, and we don't want to release those. This is one such occurance, so
we convert that link to a real file.

3) Convert the symlinks in the machines subdirectory and clean up any files that
we don't wish to publish, such as .iso and .tgz files.

4) Rename the release tarballs with the release naming conventions. They start
out with just the commit hash in the filename. We "clean" that up and replace it
with the release codename (i.e. rocko, sumo, thud) and the Poky version (i.e.
18.0.0, 19.0.1, 20.0.0, etc). We then create a symlink with the original
filename with the hash to the new tarball. Not done for milestone releases.
   
5) We copy the Eclipse artifacts to a staging directory where they are made
available externally. To do this, we copy the Eclipse plugin archive file over
to the correct location, and explode it. This is not done for milestone
releases.

6) Make the BSP tarballs. For each machine in the machines subdirectory, we
repackage the :wq

        print "Generating the BSP tarballs."
        logging.info('Generating BSP tarballs.')
        make_bsps(BSP_LIST, BSP_DIR)
        logging.info('Successful.')

        # 7) Generate the master sha256sum file for the release (for all releases, except milestones)
        print "Generating the master sha256sum table."
        logging.info('Generating the master sha256sum table.')
        gen_rel_sha(RELEASE_DIR, REL_SHA_FILE)
        logging.info('Successful.')


Contributing
============

This module is owned by Lee Chee Yang <chee.yang.lee@intel.com>.

Patches should be sent via git-send-email to the yocto@yoctoproject.org mailing list with
[release-tools] in the subject, CC'd to Chee Yang.

The following commands will configure this if ran inside a clone of release-tools:

$ git config  --local --add format.subjectprefix 'PATCH release-tools'
$ git config  --local --add sendemail.to yocto@yoctoproject.org
$ git config  --local --add sendemail.cc chee.yang.lee@intel.com

Then sending a patch is as simple as:

$ git send-email origin/master