Bug 1730176 - [Tracker] RHCS 4.0 - Release Notes
Summary: [Tracker] RHCS 4.0 - Release Notes
Keywords:
Status: NEW
Alias: None
Product: Red Hat Ceph Storage
Classification: Red Hat
Component: Documentation
Version: 4.0
Hardware: Unspecified
OS: Unspecified
medium
high
Target Milestone: rc
: 4.0
Assignee: ceph-docs@redhat.com
QA Contact: Tejas
URL:
Whiteboard:
Depends On: 1762197 1765536 1772310 1772316 1778608 1779170 1785077 1786107 1786455 1786457 1792320 1792818 1793564 1794027 1794351 1796160 1397212 1398028 1412343 1421842 1457536 1493476 1506410 1559026 1592189 1601041 1623750 1650922 1656468 1656527 1656530 1656588 1656591 1656808 1660185 1660186 1674083 1674084 1674086 1677431 1686710 1701030 1709518 1710358 1710548 1717011 1722071 1723392 1727883 1729267 1734608 1739233 1748412 1760257 1760862 1765430 1765493 1766064
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-07-16 05:16 UTC by Anjana Suparna Sriram
Modified: 2020-02-13 02:24 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Target Upstream Version:


Attachments (Terms of Use)

Description Anjana Suparna Sriram 2019-07-16 05:16:52 UTC
This tracker bug is not a tracker just for known issues but for every change that should appear in the Release Notes - major updates, technical previews, deprecated functions, and so on.

If there is a change that does not have a separate bug (for example it is a change introduced in a rebase), add that rebase bug as a blocker and specify the nature of the change in the doc text field of that bug.


**How to let us know that a bug should be documented in the Release Notes**

1) Add the BZ number of the bug that needs to be documented to the "Depends On" field in the Release Notes tracker bug. Alternatively, add the tracker bug BZ number to the "Blocks" field in the bug that needs to be documented.

2) In the bug that needs to be documented, set the doctype to one of the following:

* bug fix - for notable bug fixes that have a significant impact on customers

* enhancement - for new features and major enhancements, RFE bugs

* technology preview - for new features shipped as tech previews

* known issues - for the known issues found in this release

3) In the bug that needs to be documented, fill in the Doc Text field with the initial information. Use the template that is in the field.

----

**Candidates for inclusion**

* Bugs with a customer case attached

* Major new features and enhancements

* Bugs with significant impact on users

* Urgent or high priority bugs

* Fixed known issues

----

**How a good initial description looks like**

* Use the cause-consequence-fix-result (CCFR) format for bug fixes:

  Cause – what user action or circumstances trigger this bug 
    
  Consequence – what the user experiences when the bug occurs 
   
  Fix – what has been changed to fix the bug (overly technical details are not necessary)
    
  Result – what happens now with the fix applied

* Use the feature-reason-result (FFR) format for major updates:

    Feature – describes the enhancement from the user's point of view
    
    Reason – why was the enhancement implemented
    
  Result – what is the current user experience (may also be compared to the previous user experience)

----

**I want to document a change that does not have a bug - how to do it?**

Add a comment here, we will add that description manually.

Comment 1 Giridhar Ramaraju 2019-08-05 13:06:41 UTC
Updating the QA Contact to a Hemant. Hemant will be rerouting them to the appropriate QE Associate. 

Regards,
Giri

Comment 2 Giridhar Ramaraju 2019-08-05 13:09:18 UTC
Updating the QA Contact to a Hemant. Hemant will be rerouting them to the appropriate QE Associate. 

Regards,
Giri

Comment 3 RHEL Program Management 2019-09-05 07:22:18 UTC
Please specify the severity of this bug. Severity is defined here:
https://bugzilla.redhat.com/page.cgi?id=fields.html#bug_severity.


Note You need to log in before you can comment on or make changes to this bug.