All about the RelEng sheriff, revisited

Posted 7 months ago at 15:37. 0 comments

Sheriff badgeThis is a follow-up to Ben’s blog post about the RelEng Sheriff back in October. His post described clearly what the RelEng Sheriff (and more generally, the RelEng team) can do to help developers.

Since we implemented the RelEng sheriff (or “buildduty” as it is more informally called) last spring, developers have been getting better about using the buildduty person as the first point of contact for RelEng issues. I’d like to implore people to continue doing so. There are a few exceptions, of course:

  • It is outside of regular work hours and/or the designated buildduty person is not available; or,
  • you are already working on a bug with a specific release engineer.

We recognize that different release engineers have different core competencies, and it may be tempting to go “straight to the source,” but please respect our process. The process is in place to limit (as much as possible) the interrupt-driven nature of release engineering work and to minimize the impact of those interrupts on ongoing projects. In many cases, the person with the expertise you need will still end up helping you (we’re all in the same IRC channels, after all), but the buildduty person is specifically committed to helping you, even if only as a thin scheduling proxy for another release engineer.

Ben’s post had a good list things that RelEng can help developers with. Based on actual requests over the past few months, here are a few other services we can offer:

  • clone a virtual machine for one-off debugging/testing: Sometimes patches work on the try server but (for whatever reason) don’t once checked in. Sometimes tests fail or are intermittently orange. If you’re seeing issues like these after landing a patch, or need access to a specific platform for short-term work, the RelEng team can clone one of our reference machines and give you access (under certain circumstances).
  • grab build/extra logs from a build machine (provided they exist). This is often useful if a try server build generates extra, non-standard output

In both the above cases, the best thing to do is talk to the person on buildduty and then file a bug.

Conspicuously missing from Ben’s post was a list of what RelEng can’t do for you. While we can usually point you in the right direction, there are some things that we explicitly cannot do:

  • help you debug issues with your own local builds. We’re not (necessarily) build config experts, so unless you’re running with exactly the same configuration as our build machines and don’t have any code patches applied, you’d be better served asking the talented folk in #developers or posting to the newsgroups (m.d.builds or m.d.a.firefox)
  • shepherd your patch through the landing process. Standard patch landing rules apply: *you* are expected to be around when you land patches. If builds/tests fail and you’re not around, your patch will likely be backed out.

Need help finding the RelEng sheriff? Here’s the RelEng sheriff schedule.

Current Tunes: The Gareth Emery Podcast - Episode 96 | Filed under Build/Release, Mozilla |

No Replies

Feel free to leave a reply using the form below!


Leave a Reply