HOWTO » History » Revision 46
Revision 45 (Sage Weil, 05/11/2015 11:35 PM) → Revision 46/187 (Loïc Dachary, 05/15/2015 09:23 AM)
h3. Introduction
Backporting and the maintenance of a stable release begins when a new "stable Ceph release":http://ceph.com/docs/master/releases is published. Commits from the master branch are cherry-picked to the stable branch and run through integration and upgrade tests. After a few weeks a "point release":http://ceph.com/docs/master/releases is published. This repeats until the "lifetime of the stable release":http://ceph.com/docs/master/releases comes to an end. Backporting is focused on fixing bugs and development on the master branch is expected to add new features but both share the "same workflow":http://ceph.com/docs/master/dev/development-workflow/.
h3. Overview of the backports in progress
* *hammer* "backport status":http://tracker.ceph.com/issues/11353 and "issues":http://tracker.ceph.com/projects/ceph/issues?query_id=77 and "pull requests":https://github.com/ceph/ceph/pulls?q=is%3Aopen+is%3Apr+milestone%3Ahammer
* *firefly* "backport status":http://tracker.ceph.com/issues/11090 and "issues":http://tracker.ceph.com/projects/ceph/issues?query_id=75 and "pull requests":https://github.com/ceph/ceph/pulls?q=is%3Aopen+is%3Apr+milestone%3Afirefly
h3. Leads
* Ceph : Sage Weil
* rados : Samuel Just
* radosgw / rgw : Yehuda Sadeh
* CephFS / fs : Gregory Farnum
* RBD : Josh Durgin
* Calamari : Gregory Meno
h3. HOWTO
The following describes in detail and in chronological order, the steps to follow for backporting and maintaining stable releases.
h4. Add a new stable release
* [[HOWTO start backporting a stable release]]
h4. Add a new point release
* [[HOWTO start working on a new point release]]
h4. Prepare a new point release
# [[HOWTO monitor the automated tests AKA nightlies]]
# [[HOWTO schedule an issue for backporting]]
# [[HOWTO update the inventory]]
# [[HOWTO document user visible changes]]
# [[HOWTO backport commits]]
# [[HOWTO populate the integration branch]]
# [[HOWTO run integration and upgrade tests]]
# [[HOWTO forensic analysis of integration and upgrade tests]]
# [[HOWTO describe a test result]] inline or [[HOWTO summarize test results]] in a separate issue
# [[HOWTO merge commits from the integration branch]]
# [[HOWTO synchronize pull requests from different repositories]]
# [[HOWTO resolve issues that are Pending Backport]]
# [[HOWTO get the Ceph lead to decide if it is time for a point release]]
# [[HOWTO get the leads to sign-off on a release]]
# [[HOWTO write the release notes]]
h4. Publish a stable release
* Study https://github.com/ceph/ceph-build/ and http://jenkins.ceph.com/ to figure out how it is used to update http://ceph.com/debian-hammer/ and http://ceph.com/rpm-hammer/
* The jenkins job is http://jenkins.ceph.com/job/ceph/ and requires some setup
* The "ceph-jenkins-build":https://github.com/alfredodeza/ceph-jenkins-build/tree/master/ceph ansible setup does a bunch of things like "changing version numbers, creating a tag and pushing to the Jenkins GIT repository":https://github.com/alfredodeza/ceph-jenkins-build/blob/master/ceph/tasks/setup.yml
* once that tag is created that can be used to trigger a build in the jenkins ui when the build is completed you are required to run a bunch of scripts in the jenkins server they sign and re-index the repositories and then synchronize them with ceph/(rpm|debian)-$release. Those scripts need to be edited by hand depending on the type of release and where you are pushing them to (e.g. testing vs firefly vs hammer)
* for hammer a new repository was created by hand and it is "documented as a script":https://gist.github.com/alfredodeza/b8f8b94ea795f1a7169b
h4. Retire a stable release
* [[HOWTO retire a stable release]]
h4. Organize the stable releases and backports team
* [[HOWTO become a new team member]]
* [[HOWTO retire from the team]]