Lines Matching refs:bug
25 there are large number of bug-fixes in the stable branch or a critical bug
53 * Announce bug fix release schedule to the LLVM community and update the website.
55 * Tag bug fix -rc1 after 4 weeks have passed.
57 * Tag bug fix -rc2 4 weeks after -rc1.
232 If the bug can be reproduced with an unpatched upstream version of the release
239 In the subsequent stages, the testing is only to ensure that bug
249 should be filled in a bug in Bugzilla with the priority *release blocker* and
253 "[meta]" bug should be created and all regressions *blocking* that Meta. Once
256 If a bug can't be reproduced, or stops being a blocker, it should be removed
268 This section describes how to triage bug reports:
283 #. Review each bug and first check if it has been fixed in main. If it has, update
287 #. If a bug has been fixed and has a pull request created for backporting it,
293 You should also review the bug yourself to ensure that it meets the requirements
296 #. Once a bug has been reviewed, add the release:reviewed label and update the
328 #. *Before RC1* Patches should be limited to bug fixes, important optimization
333 #. *Before RC2* Patches should be limited to bug fixes or backend specific
339 #. *Bug fix releases* Patches should be limited to bug fixes or very safe
364 to date. The "Release Notes" must be updated to reflect new features, bug