Archive for the 'sheriffing' Category

Sheriff Survey 2017 started !

Wednesday, June 7th, 2017

One thing i love at Mozilla is that there is no general “that’s the way we have always done it..” – we at Mozilla try to improve things – our Software but also our processes and so its also with Sheriffing – We try to optimize our workflow/processes constantly to make your live as developer easier when working with us but … we rely also on your feedback 🙂

So we created a Survey for YOU to give us Feedback about how we do and also where we can improve. This input/Feedback from you is very valuable for us!

You can find the Survey at

Thanks for taking part in the Survey!

– Tomcat

Sheriffing @ Mozilla – Sheriffing a Community Task!

Monday, February 27th, 2017
i was recently asked if volunteers can help with Sheriffing!
And the answer is very simple: Of course you can and you are very welcome! 
As every part of Mozilla, volunteers are very important. Our team is mixed of Full-Time Employees and Volunteers.
What is needed to join as Community Sheriff:
I think basically there are 3 things you need to have to participate as Community Sheriff:
-> Communication Skills and Teamwork – Sheriffing means a lot of communication – communication with the other sheriff Teams, developers and teams like Taskcluster and Release Engineering. 
-> Background Knowledge how Bugzilla works (commenting in bugs, resolving bugs and setting flags etc)
-> Ability to see context & relationships between failures (like the relation of a set of failures to a checkin) to identify the changeset that causes the regression.
All our tools are public accessible and you don’t need any specific access rights to get started.
Our main tool is Treeherder ( and the first task a Community Sheriff could do is to watch Treeherder and star failures.
We have described this task here
That would help us a lot!
When you are curious how a day in Sheriffing looks then maybe can help 🙂
Please let us know when you are interested in becoming a Sheriff! You can find us on in the #sheriffs channel!

Sheriffing @ Mozilla – checkin-needed

Thursday, January 26th, 2017
Working as Sheriff @ Mozilla is much more than just monitoring our trees and doing things like backouts. In 2017 i wanted to start to blog more about what we do and here is:
Part 1 – Checkin-needed
A lot of checkins land everyday on the Mozilla repositories. Some are great new features and improvements and some are bugfixes of existing bugs etc.
While a lot of checkins are done by the developers themselves, also sheriffs are involved in this.
We not only monitor the Mozilla repositories (aka the tree) we also do checkins for people who don’t have the appropriate level of permission to check in changes (for example new community members).
In the past checkin-needed was used by developers to reduce load on our build systems with fewer pushes but with a more robust build system this isn’t relevant anymore. 
So checkin-needed is more and more important for developers without access-levels to do commits and, as mentioned, new community members who for example finished their first patch.
To request checkin-needed people use this keyword in Bugzilla or use the [checkin-needed-beta] or [checkin-needed-aurora] whiteboard entry for the patches in a bug.
For me personal is checkin-needed a very important task because you sometime check in a patch from someone who just started to contribute to Mozilla. So you are one of the people that are the first contacts to the new contributor and you help them getting the patch landed. Thats also a good opportunity to say “thanks for contributing to Mozilla” to the new community member, this is great motivation and recognition! 
How we work :
We have a wiki page with a bug query and some basic information for the Sheriff on Duty [1]. We use this query to get a overview what bugs need checkins.
For bugs with a patch attached that is not on mozreview we check the checkin-neeed request for:
    -> Has proper review before doing anything else
    -> Has a successful try run to avoid any bustage on checkin
and land the patch on mozilla-inbound.
For bugs with patches in mozreview we use the autoland tool to do the checkins. 
However we still check if the bug has review and check the try run.
This is the preferred way of doing checkin-neededs since autoland is an automated system.
How can you help 
  • ->  Use Mozreview – Autoland – it helps us to do more checkins in less time due to the automated tasks. Please make sure that there are no open issues in Mozreview when you request checkin-needed. In fact, you can land them yourself with autoland. In the future, checkin-needed will only be allowed on security bugs.
  • -> Make sure that you have a passing try run. It is a waste of the sheriffs time to come look at a checkin-needed and it has failures in the try run.
  • -> When you have multiple patches that need to land and the patches need to land in a specific order – please make a comment in the bug with the correct order.
  • -> When there are dependencies with other bugs – please state this in the bug.  
We try to do checkin-needed checks and checkins several times a day depending on sheriff workload etc so we cannot guarantee a turnaround time but trying to do our best.
When you have feedback/suggestions or idea how to do this task better let us know anytime!
Also as every part of the Mozilla Project we also depend on Community Members like you! So if you are interested to be become a Community Sheriff let me know!
– Tomcat

Sheriff Newsletter for January 2016

Friday, February 5th, 2016
To give a little insight into our work and make our work more visible to our Community we decided to create a  monthly report of what’s going on in the Sheriffs Team.
If you have questions or feedback, just let us know!
In case you don’t know who the sheriffs are, or to check if there are current issues on the tree, see:
Topics of this month!
1. How-To article of the month
2. Get involved
3. Statistics for January
4. Orange Factor
5. Contact
1. How-To article of the month and notable things!
-> In the Sheriff Newsletter we mentioned the “Orange Factor” but what is this ?  It is simply the ratio of oranges (test failures) to test runs. The ideal value is, of course, zero.

Practically, this is virtually impossible for a code base of any substantial size,so it is a matter of policy as to what is an acceptable orange factor.

It is worth noting that the overall orange factor indicates nothing about the severity of the oranges. [4]

The main site where you can checkout the “Orange Factor” is at  and some interesting info’s are here
-> As you might be aware Firefox OS has moved into Tier 3 Support [5] – this means that there is no Sheriff Support anymore for the b2g-inbound tree.

Also with moving into tier-3 – b2g tests have also moved to tier 3 and this tests are by default “hidden” on treeherder. To view test results as example on treeherder for mozilla-central you need to click on the checkbox in the treeview “show/hide excluded jobs”.

2. Get involved!
Are you interested in helping out by becoming a Community Sheriff? Let us know!
3. Statistics
Intermittent Bugs filed in January  [1]: 667
and of those are closed: 107 [2]
For Tree Closing times and reasons see:
4. Orange Factor
Current Orangefactor [3]: 12.92
5.  How to contact us
There are a lot of ways to contact us. The fastest one is to contact
the sheriff on duty (the one with the |sheriffduty tag on their nick
🙂 or by emailing sheriffs @ mozilla dot org.

– Tomcat on the behalf of the Sheriffs

a day in sheriffing

Friday, July 3rd, 2015


since i talked with a lot of people about Sheriffing and what we do here is what a typical day for me look:

We care about the Code Trees like Test Failures etc

I usually start the day with checkin the trees we are responsible for  for test failures using treeherder. This gives me first a overview of the current status and as well make sure that everything is ok for the Asian and European Community which is online at that time.

This Tasks is ongoing till the end of my duty shift. From time to time this means we have to do backouts for code/test regressions.
Beside this i do stuff like checkin-neededs, uplifts etc and other tasks and of course always availble for questions etc on irc 🙂

Also i was thinking about some parts of my day-to-day experience:

Backouts and Tree Closures:

While backouts of code for test failures/bustages etc is one important task of sheriffs (and the managing of tree closures related to this), its always a mixed feeling to backout work from someone (and no one wants to cause a bustage) but its important to ensure quality of our products.

Try Server!!!

Tree Closures due to backouts can have the side effect that others are blocked with checkins. So if in doubt if your patch compile or could cause test regressions, please consider a try run, this helps at lot to keep tree closures for code issues at a minimum.

And last but not least Sheriffing is a Community Task! So if you want to be part of the Sheriff Team as Community Sheriff please sent me a mail at tomcat at mozilla dot com


– Tomcat