This is a place where Fedora contributors vote on Fedora release blockers. The process is described here:
It is meant to replace or complement Blocker Bug Meetings:
It is not intended that you navigate through this repo's tickets manually. Instead, visit:
then select a desired milestone and for each proposed blocker/freeze exception you'll see a Vote link displayed, which will direct you to the matching discussion ticket.
If a bug report is very complex and requires real-time communication instead of asynchronous ticket discussions, we'll tag the ticket with the meeting tag and the discussion will take place during a blocker bug meeting (see above) instead of here.
You can Watch issues in this repo, which will send you an email for every new proposed bug and every new comment in any ticket. If you wish to participate in blocker review discussions in general and not just in a single topic, this is the best way to subscribe.
Place a voting command on a separate line in the form of:
TRACKER is one of these words (case-insensitive):
VOTE is one of:
+1(to vote in favor)
0(no strong feelings one way or the other or to take your vote back)
-1(to vote against)
If you want to cast several votes, you can use several separate lines (in one or more comments), or a single line:
BetaBlocker -1 BetaFE +1 FinalBlocker +1
You can swap the word order as well:
Voting commands must not be mixed with arbitrary other words, this will not be counted:
BetaBlocker +1 for sure
If you vote for the same tracker multiple times, only your last vote is counted. For example, if you submit these three votes (in one or more comments):
BetaBlocker +1 BetaFE +1 BetaBlocker -1
then your resulting vote is
BetaBlocker -1 BetaFE +1.
To take back your existing vote, simply re-vote it as
After submitting your vote, refresh the page and make sure it was counted properly.
To get more familiar with the bug review process and different tracker types, see:
Members of the fedora-qa Pagure group can issue administrative commands. Those commands are handled in the same way as voting commands, i.e. they need to be placed on a separate line and are case-insensitive. Those commands include:
AGREED (Accepted|Rejected)TRACKER... [JUSTIFICATION]
This will mark the specific tracker (one or more) as accepted or rejected. The justification is a free-form text that should then be copied to Bugzilla when setting appropriate blocker flags on the bug (this will happen automatically in the future, but currently it is the responsibility of the admin member). For example:
AGREED RejectedBetaBlocker AcceptedFinalBlocker This is not severe enough for Beta, but violates criterion X for Final.
AGREED RejectedBetaBlocker Happens only in very specific circumstances. # a few comments later AGREED AcceptedBetaFE We'll include the fix if it looks simple and safe.
A comment will be automatically added that will document the vote results at that particular point of time.
This will reset all votes for a specific tracker (one or more). When e.g. new information is discovered, this can be used to easily start a particular vote anew. Other trackers' votes will not be affected. For example:
REVOTE FinalBlocker FinalFE
All commands are case-insensitive.
Closed tickets are not processed at all (neither for voting nor for administrative commands). If you want the bot to process a command, you need to re-open the ticket first.
Once you submit a command in a comment, the ticket should get immediately updated by blockerbot and the summary in the initial description should get updated. Simply refresh the page to verify that it was processed correctly.
See contact information at:
Submit bugs and feature requests for this blocker-review discussion process at: