RepoMirrors/ceph
1
0
Fork 0
mirror of https://github.com/ceph/ceph synced 2025-04-18 05:15:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #4761 from dachary/wip-doc-workflow

Browse Source 
doc: update the development workflow

Reviewed-by: Nathan Cutler <ncutler@suse.cz>
Reviewed-by: Abhishek Lekshmanan <abhishek.lekshmanan@ril.com>
Reviewed-by: Kefu Chai <kchai@redhat.com>
This commit is contained in:
Loic Dachary 2015-05-26 21:07:05 +02:00
commit e2f392efdb
1 changed files with 51 additions and 38 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

89
doc/dev/development-workflow.rst
View File

@ -3,7 +3,7 @@ Development workflows
=====================
This page explains the workflows a developer is expected to follow to
implement the goals that are part of the Ceph lifecycle. It does not
implement the goals that are part of the Ceph release cycle. It does not
go into technical details and is designed to provide a high level view
instead. Each chapter is about a given goal such as ``Merging bug
fixes or features`` or ``Publishing point releases and backporting``.
@ -16,13 +16,13 @@ interference. In practice it is not necessary for Ceph because:
* there are few people involved
* the frequency of backports is not too high
* the reviewers know a release is being published are unlikely to
merge anything that may cause issues
* the reviewers, who know a release is being published, are unlikely
to merge anything that may cause issues
This ad-hoc approach implies the workflows are changed on a regular
basis to adapt. For instance, ``quality engineers`` were not involved
in the workflow to publish dumpling point releases. The number of
commits being backported to firefly made it impractical for developers
in the workflow to publish ``dumpling`` point releases. The number of
commits being backported to ``firefly`` made it impractical for developers
tasked to write code or fix bugs to also run and verify the full suite
of integration tests. Inserting ``quality engineers`` makes it
possible for someone to participate in the workflow by analyzing test
@ -32,10 +32,10 @@ The workflows are not enforced when they impose an overhead that does
not make sense. For instance, if the release notes for a point release
were not written prior to checking all integration tests, they can be
commited to the stable branch and the result sent for publication
without going through another run of integraiton tests.
without going through another run of integration tests.
Lifecycle
=========
Release Cycle
=============
::
@ -44,7 +44,7 @@ Lifecycle
Summit | |
| |
development | |
release | v0.88 v0.89 v0.90 ... | v0.95
release | v0.88 v0.89 v0.90 ... | v9.0.0
--v--^----^--v---^------^--v- ---v----^----^--- 2015
| | | |
stable giant | | hammer
@ -57,12 +57,11 @@ Lifecycle
Four times a year, the development roadmap is discussed online during
the `Ceph Developer Summit <http://wiki.ceph.com/Planning/CDS/>`_. A
new stable release (argonaut, cuttlefish, dumpling, emperor, firefly,
giant, hammer ...) is published at the same frequency. Every other
release is a long time support (dumpling, firefly, hammer, ...) which
means point releases are published more often. In 2014 point releases
(i.e. dumpling 0.67.11, dumpling 0.67.12 ...) are published up to
eighteen months after the publication of a stable release. Once or
twice a month, a development release is published.
giant, hammer, infernalis ...) is published at the same frequency.
Every other release (dumpling, firefly, hammer, ...) is a `Long Term Stable (LTS) <../../releases>`_.
See `Understanding the release cycle
<../../releases#understanding-the-release-cycle>`_ for more
information.
Merging bug fixes or features
=============================
@ -75,7 +74,7 @@ developers can be summarized as follows:
* A reviewer is assigned the pull request
* When the pull request looks good to the reviewer, it is merged into
an integration branch by the tester
* After a successfull run of integration tests, the pull request is
* After a successful run of integration tests, the pull request is
merged by the tester
The ``developer`` is the author of a series of commits. The
@ -84,8 +83,8 @@ a regular basis and the developer is invited to ping the reviewer if
nothing happened after a week. After the ``reviewer`` is satisfied
with the pull request, (s)he passes it to the ``tester``. The
``tester`` is responsible for running teuthology integration tests on
the pull request. If nothing happens within a month the reviewer is
invited to ping the tester.
the pull request. If nothing happens within a month the ``reviewer`` is
invited to ping the ``tester``.
Resolving bug reports and implementing features
===============================================
@ -116,19 +115,27 @@ status of an open issue can be:
* ``Pending Backport``: the fix needs to be backported to the stable
releases listed in the backport field
For each ``Pending Backport`` issue, there exists at least one issue
in the ``Backport`` tracker to record the work done to cherry pick the
necessary commits from the master branch to the target stable branch.
See `the backporter manual
<http://tracker.ceph.com/projects/ceph-releases/wiki/HOWTO>`_ for more
information.
Running and interpreting teuthology integration tests
=====================================================
The :doc:`/dev/sepia` runs `teuthology
<https://github.com/ceph/teuthology/>`_ integration tests and the
<https://github.com/ceph/teuthology/>`_ integration tests `on a regular basis <http://tracker.ceph.com/projects/ceph-releases/wiki/HOWTO_monitor_the_automated_tests_AKA_nightlies#Automated-tests-AKA-nightlies>`_ and the
results are posted on `pulpito <http://pulpito.ceph.com/>`_ and the
`ceph-qa mailing list <http://ceph.com/resources/mailing-list-irc/>`_.
* The quality engineer analyzes the integration job failure
* The job failures are `analyzed by quality engineers and developers
<http://tracker.ceph.com/projects/ceph-releases/wiki/HOWTO_monitor_the_automated_tests_AKA_nightlies#List-of-suites-and-watchers>`_
* If the cause is environmental (e.g. network connectivity), an issue
is created in the `sepia lab project
<http://tracker.ceph.com/projects/lab/issues/new>`_
* If the bug is known a pulpito URL to failed job is added to the issue
* If the bug is known, a pulpito URL to the failed job is added to the issue
* If the bug is new, an issue is created
The ``quality engineer`` is either a developer or a member of the QE
@ -162,15 +169,15 @@ following differences:
* The pull requests must target the stable branch or next instead of
master
* The reviewer rejects pull requests that are not bug fixes
* The issues matching a teuthology integration test failure is set
with severity ``Critical`` if it must be fixed before the release
* The ``Backport`` issues matching a teuthology test failure and set
with priority ``Urgent`` must be fixed before the release
Cutting a new stable release
============================
A new stable release can be cut when:
* all bugs with severity ``Critical`` are fixed
* all ``Backport`` issues with priority ``Urgent`` are fixed
* integration and upgrade tests run successfully
Publishing a new stable release implies a risk of regression or
@ -181,16 +188,16 @@ minor bugs. For instance if only one commit has been backported to a
stable release that is not a LTS, it is better to wait until there are
more.
When a stable release reaches its end of life, it may be safer to
recommend an upgrade to the next long term support release instead of
When a stable release is to be retired, it may be safer to
recommend an upgrade to the next LTS release instead of
proposing a new point release to fix a problem. For instance, the
Dumpling v0.67.11 release has bugs related to backfilling which have
been fixed in Firefly v0.80.x. A backport fixing these backfilling
bugs has been tested in the draft point release Dumpling v0.67.12 but
they are large enough to introduce a risk of regression. As Dumpling
is approaching its end of life, users suffering from this bug can
upgrade to Firefly to fix it. Unless users manifest themselves and ask
for Dumpling v0.67.12, this draft release may never be published.
``dumpling`` v0.67.11 release has bugs related to backfilling which have
been fixed in ``firefly`` v0.80.x. A backport fixing these backfilling
bugs has been tested in the draft point release ``dumpling`` v0.67.12 but
they are large enough to introduce a risk of regression. As ``dumpling``
is to be retired, users suffering from this bug can
upgrade to ``firefly`` to fix it. Unless users manifest themselves and ask
for ``dumpling`` v0.67.12, this draft release may never be published.
* The ``Ceph lead`` decides a new stable release must be published
* The ``release master`` gets approval from all leads
@ -198,9 +205,9 @@ for Dumpling v0.67.12, this draft release may never be published.
* The ``release master`` informs the ``quality engineer`` that the
branch is ready for testing
* The ``quality engineer`` runs additional integration tests
* If the ``quality engineer`` discovers new bugs with severity
``Critical``, the release goes back to being prepared, it was not
ready after all
* If the ``quality engineer`` discovers new bugs that require an
``Urgent Backport``, the release goes back to being prepared, it
was not ready after all
* The ``quality engineer`` informs the ``publisher`` that the branch
is ready for release
* The ``publisher`` `creates the packages and sets the release tag
@ -210,9 +217,9 @@ The person responsible for each role is:
* Sage Weil is the ``Ceph lead``
* Sage Weil is the ``release master`` for major stable releases
(Firefly 0.80, Giant 0.87 etc.)
(``firefly`` 0.80, ``hammer`` 0.94 etc.)
* Loic Dachary is the ``release master`` for stable point releases
(Dumpling 0.68.12, Giant 0.87.1 etc.)
(``firefly`` 0.80.10, ``hammer`` 0.94.1 etc.)
* Yuri Weinstein is the ``quality engineer``
* Alfredo Deza is the ``publisher``
@ -238,5 +245,11 @@ differences:
* The ``backport`` field of each issue contains the code name of the
stable release
* There is exactly one issue in the ``Backport`` tracker for each
stable release to which the issue is backported
* All commits are cherry-picked with ``git cherry-pick -x`` to
reference the original commit
See `the backporter manual
<http://tracker.ceph.com/projects/ceph-releases/wiki/HOWTO>`_ for more
information.