Release planning

[Jo-Philipp Wich]

Hi guys,

I spent the last few weeks working on automating the release procedure
as much as possible and am now mostly satisfied with the result.

Currently, I am reusing most parts of the existing build bot logic and
developed some scripts to automate the setup of release build bots and
to homogenize repository specific tasks like branching and tagging.

I think that the tree is in an acceptable overall state at the moment
and that it is now time to make it available to a wider audience by
providing an alternative to untested snapshot builds.

Below you'll find some thoughts on the upcoming release which I'd like
the contributors to comment on.

The text below will refer to "yy.mm" which is a placeholder for the
final agreed date. It might be LEDE 16.12, LEDE 17.01 or even LEDE
17.02, depending on what is decided.

The first final version will be yy.mm.0 (e.g. 17.01.0), the first
maintenance release will be yy.mm.1 (e.g. 17.01.1).


# Release scope and goals

The initial LEDE release will define the future process for releasing
LEDE and serve as an extensive test run to assess the state of the tree
in general and the build and support infrastructure in particular.

It does not aim to be 100% bug free, but shall serve as a starting point
for a fixed, stable series of versions with maintenance guarantees until
the next major release is made.

I expect several minor releases to happen within the upcoming LEDE mm.yy
release series, made roughly every 4 to 8 weeks, mainly to back port
support for new devices and to address important bugs found within the
life time of the first major release.

Commits done to the release branches of the package feeds will be
available in the repository within one to two days, commits done to the
core will be made available within 4 to 8 weeks as part of the next
minor maintenance release, unless security considerations force the
project to release out of band.


# Timeline

A rough timeline for an upcoming release could look like below:

 day 0  - announce LEDE yy.mm release plan, ask feeds to create
          "lede-yy.mm" branches which will be used for the release

 day 3  - create "lede-yy.mm" release branch
        - set up build farm observing the release branches

 day 5  - phase1 (images + core package) builds done
        - distribute early, volatile yy.mm-SNAPSHOT builds to
          interested parties for smoke testing

 day 10 - phase2 (package universe done) builds done
        - create yy.mm-RC1 tag
        - trigger yy.mm-RC1 builds

 day 11 - publish & announce fixed yy.mm-RC1 builds, ask for testing
        - declare "lede-yy.mm" branch feature complete and in bugfix
          only mode
        - set grace period of 5 days to identify and fix blockers

 If no blockers identified:

  day 16 - tag yy.mm.0 and issue final rebuilds

  day 17 - publish & announce yy.mm.0 builds

 If blockers are found:

  day 16 - extend grace period by 5 days until blockers are resolved

  day 21 - create yy.mm-RC2 tag
         - trigger yy.mm-RC2 builds

  day 22 - publish & announce fixed yy.mm-RC2 builds, ask for testing
         - continue with day 11


# Branching

Prior to building any release artifact, a branch called "lede-yy.mm"
will be created in the main source.git repository, with the necessary
defaults adjusted to produce versions distinguishable from master branch
builds and with feeds.conf.default pointing to the "lede-yy.mm" branches
within the respective package feeds.

Package feed maintainers are asked to provide a "lede-yy.mm" branch
which is used by LEDE throughout the entire lifetime of the yy.mm
release series.

Attached is a script, "makebranch.sh" which is used to create a release
branch.


# Tagging

Annotated Git tags are created prior to building a fixed release and
release images are produced from source trees having the Git tag checked
out, without further build-specific overrides to ensure the
reproducibility of releases.

Release Git tags will be attached to a single commit which contains
necessary adjustments to the configuration defaults to match version
numbers and revisions needed for building proper release images.

The feeds.conf.default file will be rewritten to point to the exact Git
revision of each feed used at the time the tag was made.

An example tag can be found in my staging tree:
http://git.lede-project.org/3cd5326

Tags will follow the format "vYY.MM.N[-RC#]" with YY.MM being the base
release version, N being the number of the minor release and an optional
-RC# designating release candidate numbers.

It remains to be decided whether we want to retain RC git tags and
binaries or whether we want to delete them after final release and/or
whether we do not want to produce RC releases at all.

Refer to the attached "maketag.sh" script to see how the build
infrastructure currently creates the git tags.


# Signing

A new GPG signing key is generated and used to sign binaries of the
upcoming release series. This key shall be cross signed by one or more
developers GPG keys and its public part will be added to the
keyring.git repository.

Git tags will be signed by this release key as well.


# Open questions

- Are there any outstanding changes?

  Is there important changes we should wait for before branching the
  release? Is there pending stuff in the staging trees which should
  absolutely go into the first release?

- When do we want to branch?

  Personally I'd like to branch before Christmas so that we can use the
  free time for building images (it takes about 8 days and ~2TB of space
  to build all targets and all packages).

- How do we want to code name the release?

  Imho we should avoid naming it the same as master ("Reboot") to
  prevent future confusion. Maybe we could simply name it "Zero" or
  "Debut" to underline the fact that it is the first release.

- Release branches in feed repos?

  What do we do if an external feed does not want to maintain a LEDE
  specific release branch - shall we fork it instead and host the fork
  our self?

- Who is willing to support the release branch?

  We will need one to two people to keep an closer eye on the release
  branch and to fulfill back port requests, who is volunteering here
  to serving as part of a maintainer group and as contact for release
  specific issues?


Please provide feedback so that we can agree on a definitive road map
for branching and for starting the preparations.

Regards,
Jo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: maketag.sh
Type: application/x-shellscript
Size: 4242 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/lede-adm/attachments/20161221/33de4dd1/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: makebranch.sh
Type: application/x-shellscript
Size: 3425 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/lede-adm/attachments/20161221/33de4dd1/attachment-0001.bin>