These BZ issues were included in EAP 6.2.0 Release Notes and haven't been fixed so they have to be included in EAP 6.3.0 Release Notes too: https://bugzilla.redhat.com/show_bug.cgi?id=1019232 https://bugzilla.redhat.com/show_bug.cgi?id=900378 https://bugzilla.redhat.com/show_bug.cgi?id=1015524 https://bugzilla.redhat.com/show_bug.cgi?id=1021607 https://bugzilla.redhat.com/show_bug.cgi?id=1019372 https://bugzilla.redhat.com/show_bug.cgi?id=900321 https://bugzilla.redhat.com/show_bug.cgi?id=1023193 https://bugzilla.redhat.com/show_bug.cgi?id=991389 https://bugzilla.redhat.com/show_bug.cgi?id=901231 https://bugzilla.redhat.com/show_bug.cgi?id=956281 https://bugzilla.redhat.com/show_bug.cgi?id=979369 https://bugzilla.redhat.com/show_bug.cgi?id=1027126 https://bugzilla.redhat.com/show_bug.cgi?id=918130 https://bugzilla.redhat.com/show_bug.cgi?id=995439 https://bugzilla.redhat.com/show_bug.cgi?id=1014048 https://bugzilla.redhat.com/show_bug.cgi?id=1026823 https://bugzilla.redhat.com/show_bug.cgi?id=1016546 https://bugzilla.redhat.com/show_bug.cgi?id=1029851 https://bugzilla.redhat.com/show_bug.cgi?id=1027586 https://bugzilla.redhat.com/show_bug.cgi?id=980246 https://bugzilla.redhat.com/show_bug.cgi?id=900047 https://bugzilla.redhat.com/show_bug.cgi?id=900620 https://bugzilla.redhat.com/show_bug.cgi?id=923836 https://bugzilla.redhat.com/show_bug.cgi?id=900609 https://bugzilla.redhat.com/show_bug.cgi?id=900564 https://bugzilla.redhat.com/show_bug.cgi?id=917683
Since the documentation workflow for release notes is largely automated, the best way to include these bugs in the 6.3.0 document is to clone them and set the target for this release. Will this cause undue chaos with the development team? Or do clones already exist for these issues? I found clones linked for 980246 [1049276] and 917683 [1072343] but neither of those clones has a target release set, so I'm unsure if pointing them at 6.3.0 will break someone's methodology.
I believe that the BZ search on which the Release Notes are based should NOT have specified a target release in its search criteria. To test this theory I have created a second BugDash "dashboard" [1]. [1] https://presentations.cloud.lab.eng.bne.redhat.com/release_note_docs/16
I'm not sure that's a viable approach. We'd be expending resources trying to sort the wheat from the stale chaff (older, irrelevant tickets).
Verified in revision 6.3.0-6