Sheriffing/survey

When we created the Sheriff Survey, one important point was what we can do better and whats on the wishlist from our Developers. We got a lot of valuable feedback to improve our work.

We identified 3 top issues from the Sheriff Survey.

Uplifts

General Timeline:

Timeline	What	Who	Status
Q2	Documentation	done by Ryan	done
Q2	Create Communication Part from Feedback	Tomcat	done
Q2	Getting Started with uplifts	Tomcat	done -

Sheriff Teamowner: Ryan ? Peers: Tomcat

Uplifts of patches is a big area where Sheriffs can help like uplifting patches. With the Survey we identified the need to improve work here. Especially in the Documentation and Communication Area.

So we have 2 Work Areas

= Documentation

-> Done by Ryan in #uplift docu [[1]]

Example for a uplift command taken from :

1. unified repro doc [[2]]

Pull and update to prepare for the uplifts:

   hg pull central
   hg pull aurora
   hg up aurora

Graft the mc commit and bring up the editor to edit the commit message, adding "a=foo" as needed:

   hg graft --edit -r <revision>

Repeat the previous step as needed for all uplifts as needed. Verify the outgoing changes and push:

   hg out -r . aurora
   hg push -r . aurora

Communication

also a Communication part:

*when you start to uplift patches

This should be daily routine (= uplifts are done on a daily basis by the |sheriffduty Sheriffs) by checking the bug querys for uplifts. Also for last-minute-important uplifts feel free to ping the sheriffs.

*when you expect it to be completed:

Given more people will look at uplifts, the eta for landing uplifts should be very short once a bug is approved. Depend on the approvals where we have as sheriffs no influence.

* if you are busy with something else.

With more people looking at uplifts and with the new documentations, it should be possible to "load-balance" uplifts, mean when one Sheriff is busy with something else or on pto, another one should be able to take over. However there might be scenarios like a complete tree closure where sheriffs are buys with handling this situation but there is always irc to connect to sheriffs/relman :)

Date	Who	What	State
Q2	Tomcat: Identified needs from the Survey	Done
Q2	Tomcat: Create/Streamline Processes	done
Q2 + Beyond	Tomcat: Inform Relman etc

Autoland

We got a very high demand of Feedback asking for a way to autoland patches and so having a automated vs. human-depending way of landing patches in the Mozilla Repos.

Plans for Q2. Identify Teamleads for Autoland and find out about status

Sheriff Driver: Tomcat Peer : ?

Timeline	What	Who
q2	Identify Autoland leads	Tomcat
q2	Query Status and inform them about survey results	Tomcat	done
q3 and beyond	Stay in Touch with Autoland devs to get autoland in at some time	Tomcat

Tree Closures due Code Quality issues

The Survey revealed that Tree Closures due to before-regressed-code-or-bustage cause frustration around Developers. That is because other Developers who start to work are not able to checkin patches and so accomplish work tasks.

The Feedback was not meant as critics that Sheriffs are too picky on closing the trees for code issues its more that everyone need to be sure what she/he commits and about the stability of the change. One Suggestion was to encourage try runs for changes that could cause bustages etc.

Project Owner: Tomcat

Planing of tasks

Date	Who	What
Q2	Tomcat: Dicuss with Sheriffs if this is helpful	Sheriff meeting
Q2	Tomcat: Bring Topic to Ateam	Sent mail
Q2 + Beyond	Tomcat: Remind People of using Try	Example