Bugtracker link update

As discussed in the upstream meeting, update the placement bug tracker, link from storyboard to launchpad, so new bugs should be reported in launchpad instead storyboad. Whats not updated: - all links of storyboard which do not point to bugs - links of existing stories, features, docs etc Change-Id: I64b9d6feb4fb35f36c5a290b8b79d9b78736efd2
2023-03-07 16:56:21 +00:00
parent 1a6cc9af4a
commit 972dfd4825
4 changed files with 35 additions and 89 deletions
--- a/CONTRIBUTING.rst
+++ b/CONTRIBUTING.rst
@@ -9,9 +9,9 @@ to set up and use Gerrit:

   https://docs.openstack.org/contributors/code-and-documentation/quick-start.html

-Bugs should be filed on Storyboard:
+Bugs should be filed on launchpad:

-   https://storyboard.openstack.org/#!/project/placement
+   https://bugs.launchpad.net/placement/+filebug

 For more specific information about contributing to this repository, see the
 placement contributor guide:
--- a/README.rst
+++ b/README.rst
@@ -42,7 +42,8 @@ operating system vendor, it is often wise to use their own bug tracker for
 reporting problems. In all other cases use the master OpenStack bug tracker,
 available at:

- `Bug Tracker <https://storyboard.openstack.org/#!/project/openstack/placement>`__
+- `Bug Tracker <https://bugs.launchpad.net/placement>`__
+- `File new Bug <https://bugs.launchpad.net/placement/+filebug>`__

 Developers
 ----------
--- a/doc/source/contributor/contributing.rst
+++ b/doc/source/contributor/contributing.rst
@@ -38,62 +38,18 @@ If in doubt, ask someone, either by sending a message to the
 `openstack-discuss`_ mailing list with a ``[placement]`` subject tag, or by
 visiting the ``#openstack-nova`` IRC channel on ``webchat.oftc.net``.

-StoryBoard
----------
-
-Placement uses `StoryBoard`_ for tracking bugs, features, "cleanups" (described
-below), and docs improvements. Different types of stories are distinguished by
-tags which are applied manually by people creating or reviewing the stories.
-These tags are used to create work lists.
-
-.. list-table:: Worklists
-   :header-rows: 1
-
-   * - List
-     - Main Tag
-     - Description
-   * - `Untriaged Stories <https://storyboard.openstack.org/#!/worklist/580>`_
-     - No tags
-     - New or unvisited stories which have not yet been categorized (and should
-       be).
-   * - `Bugs <https://storyboard.openstack.org/#!/worklist/574>`_
-     - ``bug``
-     - Incorrect behavior in existing code, features or documents. If the issue
-       is with documentation, add the tag ``docs``.
-   * - `Features <https://storyboard.openstack.org/#!/worklist/594>`_
-     - ``rfe``
-     - Planned or requested features or enhancements to the system.
-   * - `Cleanups <https://storyboard.openstack.org/#!/worklist/575>`_
-     -  ``cleanup``
-     - Improvements to the code or surrounding repository to help with
-       maintenance or other development lifecycle issues that are not otherwise
-       a bug or feature.
-   * - `Docs <https://storyboard.openstack.org/#!/worklist/637>`_
-     - ``docs``
-     - Required or recommended improvements to the documentation.
-
-When all the tasks in a story have a status of ``Merged`` or ``Invalid``, the
-story will be considered complete and its status will change from ``Active`` to
-either ``Merged`` or ``Invalid``. If there is at least one task in the
-``Merged`` state, the story will be ``Merged``. The worklists above are
-configured to only show stories that are ``Active``.
-
-.. note::
-
-   These worklists and their chosen tags are subject to change as the project
-   gains more experience with StoryBoard. The tags chosen thus far are, in
-   part, the result of them already existing elsewhere in the system.
-
 Submitting and Managing Bugs
 ----------------------------

-Bugs found in  placement should be reported in `StoryBoard`_ by creating a new
-story in the ``openstack/placement`` project.
+Bugs found in  placement should be reported in `Launchpad`_ by creating a new
+bug in the ``placement`` project.
+
+.. _new_bug:

 New Bugs
 ~~~~~~~~

-If you are submitting a new bug, explain the problem, the steps taken that led
+If you are submitting a `new bug`_, explain the problem, the steps taken that led
 to the bad results, and the expected results. Please also add as much of the
 following information as possible:

@@ -103,7 +59,8 @@ following information as possible:
 * The operating system(s) on which the placement is running.
 * The version(s) of Python being used.

-Tag the story with ``bug``.
+Tag the bug with ``tags``, like doc, api, etcetera.
+Learn more about launchpad from `openstack launchpad doc`_.

 .. _triage:

@@ -114,27 +71,23 @@ Triaging newly submitted bugs to confirm they really are bugs, gather missing
 information, and to suggest possible solutions is one of the most important
 contributions that can be made to any open source project.

-If a `new bug`_ doesn't have the ``bug`` tag, add it. If it isn't a functional
-problem with existing code, consider adding the ``rfe`` tag for a feature
-request, or ``cleanup`` for a suggested refactoring or a reminder for future
-work. An error in documentation is a ``bug``.
+If a new bug doesn't have tags, add the relevant tag as per the area of
+affected code.

-Leave comments on the story if you have questions or ideas. If you are
-relatively certain about a solution, add the steps of that solution as tasks on
-the story.
+Leave comments on the bug if you have questions or ideas. If you are
+relatively certain about a solution, add the steps of that solution as tasks
+on the bug.

-If submitting a change related to a story, the `gerrit`_ system will
-automatically link to StoryBoard if you include ``Story:`` and, optionally,
-``Task:`` identifiers in your commit message, like this::
+While triaging, only if you are sure, update the status of the bug from new
+to others.

-    Story: 2005190
-    Task: 29938
-
-Using solely ``Story:`` will leave a comment referring back to the commit in
-gerrit. Adding ``Task:`` will update the identified task to indicate it is in a
-``Review`` state. When the change merges, the state will be updated to
-``Merged``.
+If submitting a change related to a bug, the `gerrit`_ system will
+automatically link to launchpad bug if you include ``bug_id:`` identifiers in
+your commit message, like this::

+    Related-Bug: 2005189
+    Partial-Bug: 2005190
+    Closes-Bug: 2005190

 Reviewing Code
 --------------
@@ -181,6 +134,7 @@ Some guidelines that reviewers and patch submitters should be aware of:
  gate is an indication that OpenStack is not robust and at the root of all
  this, making OpenStack work well is what we are doing.

+  See here for `How to Recheck`_

 Special Considerations For Core Reviewers
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -258,10 +212,6 @@ pieces fit together.
    return_value = self.some_method(
        arg1, arg2, arg3, arg4)

-* Changes associated with stories and tasks in StoryBoard_ should include
-  ``Story`` and ``Task`` identifiers in the commit message, as described in
-  :ref:`triage` above.
-
 New Features
 ------------

@@ -273,21 +223,13 @@ are needed in the Placement API_ or elsewhere in the project. That interaction
 should happen in the usual ways: At Project Team Gatherings, on the
 openstack-discuss_ list, and in IRC.

-Once there is a clear need for a change, a story should be created in
-StoryBoard_ with a tag of ``rfe``. Placement team members will evaluate the
-story to determine if a :doc:`spec </specs/index>` is required. If it is, a
-task to create the spec will be added to the story. At this time there are no
-hard and fast rules on what will require a spec. If the implementation is well
-understood it may be the case that a detailed story and a series of tasks
-associated with that story will be sufficient. If further discussion is
-required to understand the problem or to evolve or verify the design of the
-solution, a spec is a good idea.
+Create a new bug as described in :ref:`new_bug` above.

 If a spec is required there are some guidelines for creating one:

 * A file should be created in the `placement code`_ in
  ``doc/source/specs/<cycle-name>/approved`` with a filename beginning with the
-  identifier of the story. For example::
+  identifier of the bug. For example::

     docs/source/specs/train/approved/200056-infinite-resource-classes.rst

@@ -304,8 +246,9 @@ If a spec is required there are some guidelines for creating one:
  case basis. See the `stein schedule`_ for an example schedule.

 * Work items that are described in a spec should be reflected as tasks
-  created on the originating story. Update the story with additional tasks as
-  they are discovered. Most new tasks will not require updating the spec.
+  created on the originating launchpad bug. Update the bug with additional
+  tasks as they are discovered. Most new tasks will not require updating the
+  spec.

 * If, when developing a feature, the implementation significantly diverges from
  the spec, the spec should be updated to reflect the new reality. This should
@@ -330,8 +273,8 @@ PTL duties are enumerated in the `PTL guide`_.
 .. _Project Team Guide: https://docs.openstack.org/project-team-guide/
 .. _openstack-discuss: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss
 .. _list archive: http://lists.openstack.org/pipermail/openstack-discuss/
-.. _StoryBoard: https://storyboard.openstack.org/#!/project/openstack/placement
-.. _new bug: https://storyboard.openstack.org/#!/worklist/580
+.. _Launchpad: https://bugs.launchpad.net/placement
+.. _new bug: https://bugs.launchpad.net/placement/+filebug
 .. _gerrit: http://review.opendev.org/
 .. _How to Review Changes the OpenStack Way: https://docs.openstack.org/project-team-guide/review-the-openstack-way.html
 .. _core reviewers: https://review.opendev.org/#/admin/groups/1936,members
@@ -342,3 +285,5 @@ PTL duties are enumerated in the `PTL guide`_.
 .. _release note: https://docs.openstack.org/reno/latest/
 .. _PEP 8: https://www.python.org/dev/peps/pep-0008/
 .. _PTL guide: https://docs.openstack.org/project-team-guide/ptl.html
+.. _openstack launchpad doc: https://docs.openstack.org/contributors/common/task-tracking.html#launchpad
+.. _How to Recheck: https://docs.openstack.org/project-team-guide/testing.html#how-to-handle-test-failures
--- a/setup.cfg
+++ b/setup.cfg
@@ -7,7 +7,7 @@ author = OpenStack
 author_email = openstack-discuss@lists.openstack.org
 url = https://docs.openstack.org/placement/latest/
 project_urls =
-    Bug Tracker = https://storyboard.openstack.org/#!/project/openstack/placement
+    Bug Tracker = https://bugs.launchpad.net/placement
    Documentation = https://docs.openstack.org/placement/latest/
    API Reference = https://docs.openstack.org/api-ref/placement/
    Source Code = https://opendev.org/openstack/placement