Sheriffing/survey: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 5: Line 5:
= Uplifts =
= Uplifts =


Sheriff Teamowner: Ryan
Sheriff Teamowner: Ryan ?
Peers: Tomcat
Peers: Tomcat


Line 47: Line 47:
| Q2 || Tomcat: Identified needs from the Survey || Done ||
| Q2 || Tomcat: Identified needs from the Survey || Done ||
|-
|-
| Q2  || Tomcat: Create Processes ||  
| Q2  || Tomcat: Create/Streamline Processes ||  
|-
|-
| Q2 + Beyond || Tomcat: Inform Relman etc ||  
| Q2 + Beyond || Tomcat: Inform Relman etc ||  
Line 59: Line 59:
Plans for Q2. Identify Teamleads for Autoland and find out about status
Plans for Q2. Identify Teamleads for Autoland and find out about status


Sheriff Driver: Tomcat
Peer : ?
{| class="wikitable"
|-
! Timeline !! What !! Who
|-
| q2 || Identify Autoland leads || Tomcat
|-
| q2 || Query Status and inform them about survey results || Tomcat
|-
| q3 and beyond || Stay in Touch with Autoland devs to get autoland in at some time || Tomcat
|}


= Tree Closures due Code Quality issues =
= 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 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.
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.

Revision as of 12:32, 8 June 2015

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/Streamline 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

Sheriff Driver: Tomcat Peer : ?

Timeline What Who
q2 Identify Autoland leads Tomcat
q2 Query Status and inform them about survey results Tomcat
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 helful Sheriff meeting
Q2 Tomcat: Bring Topic to Ateam Sent mail
Q2 + Beyond Tomcat: Remind People of using Try Example