Differential D89 Diff 198 source/contributor-guide/bug-reporting-structured.rst

Changeset View

Standalone View

source/contributor-guide/bug-reporting-structured.rst

This file was added.

				.. _contributor-guide-structured-contributions-reporting-bugs:

				===========================================================
				Reporting Bugs Against (Long-Term) Supported Kolab Versions
				===========================================================

				Long-term support versions of Kolab maintain larger sets of different versions
				of software, and it becomes important to ensure that the fix for an issue in
				`foo-1.0` does not require a properly entitled customer to upgrade to a later
				version of Kolab, or even a later version of `foo`.

				The stability requirements imply that support be able to track issues with
				specific versions of the software, targets these issues to be resolved in
				certain newer versions of the software, and trusts the resolution of the issue
				to be verifiable against multiple versions of the software collection.

				Example
				=======

				The following table depicts the versions of the roundcubemail package, and
				the roundcubemail-plugins-kolab package, as distributed for each product
				stream.

				.. table:: Version table for Roundcubemail and Kolab Plugins

				+-------------------------------+---------------+-----------------------------+
				\| \| roundcubemail \| roundcubemail-plugins-kolab \|
				+===============================+===============+=============================+
				\| :orange:`Kolab Enterprise 13` \| `1.0.4` \| `3.1.16` \|
				+-------------------------------+---------------+-----------------------------+
				\| :orange:`Kolab Enterprise 14` \| `1.1.4` \| `3.2.11` \|
				+-------------------------------+---------------+-----------------------------+
				\| :orange:`Kolab 16` \| `1.2` \| `3.3` \|
				+-------------------------------+---------------+-----------------------------+
				\| :orange:`Kolab Winterfell` \| `1.2` \| `3.3` \|
				+-------------------------------+---------------+-----------------------------+

				Stability requirements for :orange:`Kolab Enterprise 13` demand the following:

				* The version of roundcubemail shipped to the product stream is one of
				the 1.0 series of upstream releases,

				* Upstream maintains a stable 1.0 series for roundcubemail,

				* The version of roundcubemail-plugins-kolab shipped to the product
				stream is one of the 3.1 series of upstream releases,

				* Upstream maintains a stable 3.1 series for roundcubemail-plugins-kolab,

				* Future versions of roundcubemail in the 1.0 series remain backward
				compatibility for consumers of its API (such as
				roundcubemail-plugins-kolab),

				* Added functionality in roundcubemail-plugins-kolab, if any, does not
				require any changes in roundcubemail that would break other compatibility,

				* The aforementioned conditions all last for up to 5 years,

				* For a large number of target platforms.

				The same conditions apply to :orange:`Kolab Enterprise 14` and
				:orange:`Kolab 16` -- with different version series, different timelines and
				sometimes different stacks.

				Further down the dependency stack, this includes maintenance for
				libkolabxml, libkolab and libcalendaring.

				In the future, this will extend up to 6 product streams that will need to be
				maintained.

				It is therefore important that an issue logged against a version 1.0.1, with
				the current version in the 1.0 series perhaps being 1.0.10, needs to go through
				the following stages:

				#. Is the issue reproducible in the unstable development version of the
				software suite?

				a. If it is, it is a development issue; `report a bug`_ in Phabricator.

				Developer teams become responsible for testing the resolution of the
				issue first, and fixing the issue second (see
				:ref:`contributor-guide-test-driven-development`).

				For each of the product streams in between current development and
				the original issue report, create a ticket in `bugzilla`_.

				.. seealso::

				* Something about backporting with the verification included.

				b. If it is not, in what product stream can the issue still be reproduced?

				This process can be very costly lather-rinse-repeat exercise, and
				therefore needs to be covered ahead of time, through
				petersenUnsubmitted Not Done Inline Actions "..can be 'a' very costly.."? petersen: "..can be 'a' very costly.."?
				vanmeeuwenAuthorUnsubmitted Not Done Inline Actions Yup. vanmeeuwen: Yup.
				:ref:`contributor-guide-test-driven-development`.

				Create a `bugzilla`_ ticket for the appropriate

				.. seealso::

				* Something about constructive troubleshooting efforts

				#. Using the input of 1) and outcome of 1a) or 1b), describe the range of
				targets;

				* branch 1.2 for :orange:`Kolab 16`: yes or no?
				* branch 1.1 for :orange:`Kolab Enterprise 14`: yes or no?
				* etc.

				Each becomes a separate `bugzilla`_ ticket, each of them depending on the
				resolution of the more recent product stream('s software version).

				Example
				=======

				Let's assume "yay" fails on all versions of Roundcube.

				#. Issue:

				Yay fails on Roundcube 1.0.1 on :gray:`Enterprise Linux 6`

				This is an original ticket. The intended milestone for the resolution is
				`1.0-next`.

				#. Support:

				#. Does yay fail in :orange:`Kolab Winterfell` on Enterprise Linux 7?

				Yes, this is a new development issue; `Report a bug`_. Add a project
				tag for :orange:`Winterfell`

				#. Does yay fail in :orange:`Kolab 16` on Enterprise Linux 7?

				Yes, and :orange:`Kolab 16` is on the same software version series as
				:orange:`Winterfell`;

				It is thus a new development issue; `Report a bug`_ and have it
				blocked by the bug created in 2.1).

				Associate the :orange:`Kolab 16` release target with the bug.

				Also create a `bugzilla`_ ticket. The milestone here is `1.2-next`.
				Refer to the task created in Phabricator.

				#. Does yay fail in :orange:`Kolab Enterprise 14` on
				:gray:`Enterprise Linux 6` ?

				Yes, create a `bugzilla`_ ticket and block it with the ticket created
				in 2.2). The milestone here is `1.1-next`.

				#. Does yay fail in :orange:`Kolab Enterprise 13` on
				:gray:`Enterprise Linux 6` using version 1.0.4?

				Yes, block the original ticket in 1) with the ticket from 2.3).