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

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
• when you expect it to be completed
• if you are busy with something else.

Date	Who	What	State
Q2	Tomcat: Identified needs from the Survey	Done
Q2	Tomcat: Create Processes
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

Tree Closures due Code Quality issues

The Survey revealed that as example in non-Pacific Timezones Tree Closures due to before-regressed-code-or-bustage cause frustration around Developers. That is because other Developers who start then to work are not able to checkin patches and so acomblish 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 helful	Sheriff meeting
Q2	Tomcat: Bring Topic to Ateam	Sent mail
Q2 + Beyond	Tomcat: Remind People of using Try	Example