[docs] Add user-side for blockers/merges

[rovka]

docs/HowToReleaseLLVM.rst

267

Typo (fixed -> fixes)

[• tstellarAMD]

docs/HowToReleaseLLVM.rst

264–266

I think anyone should be able to backport as long as the code owner approves. This saves the code owner from having to do a lot of extra work.

I also think backport requests should be a separate bugzilla entry from the initial bug report. I realize this may be inconvenient, but it makes it much easier to track.

[hans]

I think anyone should be able to backport as long as the code owner approves. This saves the code owner from having to do a lot of extra work.

+1

I also think backport requests should be a separate bugzilla entry from the initial bug report. I realize this may be inconvenient, but it makes it much easier to track.

I personally prefer the "reply to the commit email and cc me" approach since that includes the context of the commit, keeps the merge discussion on the same thread on the mailing list, and is low overhead. I'm not picky about this though, as long as an email is generated.

[• tstellarAMD]

In D26963#606697, @hans wrote:

I also think backport requests should be a separate bugzilla entry from the initial bug report. I realize this may be inconvenient, but it makes it much easier to track.

I personally prefer the "reply to the commit email and cc me" approach since that includes the context of the commit, keeps the merge discussion on the same thread on the mailing list, and is low overhead. I'm not picky about this though, as long as an email is generated.

I think "reply to the commit email and cc me" works better for the x.y.0 releases, because all the commits being backported are fairly recent. For the stable releases, a lot of times people are requesting a 3+ month old commit be backported, they don't always have the commit email in their inbox any more.

However, my preference is to have policies that make the release manager's life easier, so I don't have any objections to doing the x.y.0 requests via email, but for the stable releases, I think bugzilla use should be mandatory.

[rengolin]

Addressing comments.

[rengolin]

Ping?

[hans]

lgtm

[rengolin]

Hm, just found this still open. I have no idea if this ever got merged, but it's completely irrelevant now. Closing.

docs/HowToReleaseLLVM.rst

 from the Meta and its priority decreased to *normal*. Debugging can continue,
 but on trunk.
 
+To help users report regressions and propose backports, the following standard
+is followed:
+
+ #. The Meta bug is named: "[Meta] X.n Merges and Bug Fixes", where X.n is the
+    release in question.
+ #. Regressions should be linked as a blocker to that bug, as a separate entry,
+    linking both the original bug (or reporting a new one) and the meta bug.
+    When fixed on trunk, it should be backported with the approval of the code
+    owner as soon as all the tests are done and all the bots are green.
+ #. Already existing fixes proposed as backports should create new bugs entitled
+    "Merge rN to the X.n branch", where rN is the commit(s) to backport and X.n
+    is the release, which should coincide with the release in the Meta.
+
+The ultimate decision to merge / backport fixes is done by the release manager
+and the code owners, so please make sure to copy them on any correspondence
+regarding that issue.
+
 Release Patch Rules
 -------------------