Project

General

Profile

Release Management » History » Version 13

Sam Kottler, 12/14/2012 10:16 AM

1 1 Sam Kottler
h1. Release Management
2 4 Sam Kottler
3 5 Sam Kottler
For each major (x.0) and minor release there is a release nanny who is responsible for managing communication around releases. This person is responsible for handling the generation of release notes, sending emails and IRC notifications about release candidates and final releases, as well as generally tracking blockers, etc.
4 1 Sam Kottler
5 2 Sam Kottler
h2. Release notes
6 3 Sam Kottler
7 13 Sam Kottler
The release notes are all stored on the [[ReleaseNotes]] page. One of the most helpful tools to generate the release notes is using the target version in Redmine, which is available by going to http://theforeman.org/projects/foreman/roadmap. All the bugs, features, and support requests for the specific version you are working on will be available on that page. It's also helpful to compare the git log to that page since sometimes there are important commits that are not included redmine for whatever reason.
8
9 1 Sam Kottler
h4. Template
10
11 2 Sam Kottler
h2. Communication
12 3 Sam Kottler
13 1 Sam Kottler
h4. Email
14 13 Sam Kottler
15
h2. Schedule
16
17
The first email to go out to the user list will usually be an announcement about packages being available. The next email after that usually has a link to the release notes and can give a quick overview of what changes are made in the release. Be sure to include links to the previous email about RPM and Debian package availability so users who may have missed those emails and would like to try the RC.
18 1 Sam Kottler
19
h4. IRC
20
21 11 Sam Kottler
Many users rely primarily on IRC for asking questions about the release process, location of the packages, and new features that are included in the 
22
23 2 Sam Kottler
h2. Packaging
24 3 Sam Kottler
25 1 Sam Kottler
h4. RHEL derivatives
26 11 Sam Kottler
27
There are currently scripts in the "rpmbuild" branch of the foreman-rpms repository that will build the appropriate SRPM's and then use mock to create the RPM's for each distribution and architecture. 
28
29
The best way to get started with creating the RC repositories (which will ultimately become the final repo for the new release) is to rsync the nightly repository from shell.theforeman.org. This repo will contain the most recent dependencies, Requires and BuildRequires for the core foreman and foreman-proxy specs.
30
31
Development dependencies for the nightly packages, which are generally needed for package RC's and ultimately the final release, are stored in foreman.spec-devel.patch, which is included in the SOURCES directory for each distro. Some packages will then need to get rebuilt and copied into the RPM repository. To build a package for a dependency (RubyGem) run the following:
32
33
* Download the .gem from rubygems.org into your cwd.
34 12 Sam Kottler
* If the gem doesn't have native extensions run: 'rpmbuild -bs --nodeps --define "_sourcedir ." --define "_srcrpmdir ." rpms/epel-6/SPECS/rubygem-<gem name>.spec'
35 11 Sam Kottler
* Run mock for each distribution and architecture that's supported: mock --verbose -r <distro>-<arch> <srpm in cwd>.src.rpm (i.e. mock --verbose -r epel-6-x86_64 rubygem-rbovirt-0.0.15-1.el6.src.rpm). Mock sure you have the mock configurations from the foreman-rpms repository in /etc/mock; these will add the Foreman repo so that build dependencies can be met.
36
* The resulting RPM will be in /var/lib/mock/<distro>-<arch>/result.
37
38
This process should be completely scripted, but right now it's done via a set of one-off scripts.
39
40
After all the dependencies are built and reflected in foreman.spec and foreman-proxy.spec, run a rpmbuild and subsequent mock command for each distro and arch. Replace the packages in the nightly repo that your rsync'ed earlier that have never versions that just got built. Then run "createrepo ." for each distribution and architecture. Yet another process that is automated with a one-off script that needs a more permanent solution.
41 1 Sam Kottler
42
h4. Debian
43 8 Greg Sutcliffe
44 9 Greg Sutcliffe
Tasks for each RC release
45 8 Greg Sutcliffe
46
* Update foreman-rpms/deb/<distro>/rc/<package>
47 10 Greg Sutcliffe
** As a minimum, update the changelog file, since the package version comes from that
48
** Update build.sh with the SHAsum of the RC tag
49 8 Greg Sutcliffe
* Get jenkins to rebuild the packages for the rc repo
50
51
Stuff to do at release:
52
53 1 Sam Kottler
* Update foreman-rpms/deb/<distro>/stable/<package>
54 10 Greg Sutcliffe
** copy from the appropriate RC packaging files
55
** don't copy the rc changelog directly, craft a new one with appropriate release notes
56
** update build.sh with the SHAsum of the release tag
57 6 Sam Kottler
* Clean out the rc repo on server09 by hand
58 10 Greg Sutcliffe
** reprepro -b ~/foreman-reprepro -C rc remove squeeze foreman-proxy
59
** reprepro -b ~/foreman-reprepro -C rc remove squeeze foreman
60
** reprepro -b ~/foreman-reprepro -C rc remove squeeze foreman-sqlite3
61
** ... all the other foreman-* packages ...
62 8 Greg Sutcliffe
* Get jenkins to build the packages for the stable repo