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 |