Tip:
Highlight text to annotate it
X
So after you've submitted your bug to get a review,
you'll get an email that looks either like this: Review not granted.
And that's for an r-.
Or you'll get an email like this: Which is review granted.
And that's for an r+.
Now if you get an r-, you need to make changes to your patch.
And then once these changes are made, do an hg qrefresh to get those changes in the patch.
And then you'd re-attach the patch into the bug. And re-request a review again from the reviewer.
If you get an r+, congratulations on getting your first r+.
And your patch is now ready to land.
Before landing, if you haven't run the patch through any tests yet.
And if you don't have commit access level 1 yet.
You should ask the reviewer if they can run it through try for you.
I'm just going to open this bug in a new tab.
So if you don't have commit access yet, and you do have editbugs. What you'll do is you can add a keyword right there.
And that keyword should be checkin-needed.
Now if you don't have editbugs, like for this case for the user that I'm logged in with.
I can just scroll down, and I can ask someone to do it for me.
This patch is ready to be checked in, can someone help me.
And then press Save Changes.
Now you can also ask for help landing your patch on try if you don't have commit access level 1 yet.
And the person that reviewed your code should do that for you.
And after about a day, if they haven't responded back,
just ask them if the try push went correctly or not.
And they'll let you know.
So once your patch is ready to land, if you don't have commit access.
Someone will push it to mozilla-inbound, or fx-team which are integration branches.
And from those branches, within about a day, they'll get moved to mozilla-central.
Now if you do have commit access level 3, you can push those patches yourself to the inbound branches.
And after you push them, you'd paste the changeset for the inbound push right here.
Subtitles by the Amara.org community