Release Management/Projects

From MozillaWiki
Jump to navigation Jump to search

This is just a brain dump for now

Release tracking

  • Create a release tracking web system that tracks state and is the single point of reference
    • Have an API so others can query / use the data
    • Use pulse to tie into the build system
    • Should have bug dashboards and charting
  • Online calendars that people can subscribe to in different ways
    • For example, subscribe to all Mozilla Beta releases or all mozilla-aurora migrations
  • Implement a release checklist / signoff system
  • Define, implement, and track metrics related to rapid release. Use that data to determine where we are in the process / if we need to adjust
    • Crash rates
    • User rates
    • Feedback query levels
    • Bug churn
    • Repo churn
    • Twitter sentiment
  • Work with kev/fligtar to better track add-on compatibility for each release
    • Tie it in with the release management system
    • Follow up with them to work with partners if we are at risk for release
  • Track mechanics end-to-end time and work to reduce it

Bug tracking

  • Come up with a better system to track where bugs are fixed and where they aren't
  • Work on mediawiki-bugzilla and get it rolled out
  • Implement bug 537749
  • Create scripts to do common tasks
    • Revoke approvals at the end of a cycle
    • Move bugs between various buckets (like mozilla-aurora approval requests to mozilla-beta approval requests after a migration)
  • Create query watchers / whines to keep us aware of items that need attention

Feature tracking

  • Help spec out and implement a web system for tracking features
  • Help tying the feature tracking system into the release tracking system
  • Specific features:
    • Stub installer
    • Patching to more than one version back
    • Mac App Store
    • Linux 64bit (?)
    • ...others

Automation

  • Automate / make less painful release note creation
  • Automate / make less painful MFSA tracking for a release
  • Automate / make less painful release announcements
  • Automate the hand-off between RelEng, QA, and RelMan
  • Instrument assorted systems to publish into pulse
  • Build a higher-level event/webhook system on top of pulse
  • Create a RelMan bot to answer common release questions
    • Did bug xxxxx make Firefox Beta X?
    • Is change xxxxx on mozilla-beta?
    • When is Firefox 30's release date?
    • etc
  • Create tool to help standardize triage flow
  • Create a first-responder Twitter bot to inform users about a release

Quality

  • Write a library to interact with the WinQual API
  • Lead the specification / integration of WinQual data with current systems
  • Add views to Socorro or work with the team to have them implement some useful ones
    • One thing that is desperately needed is a treemap / bucketing system
  • Create a verifier system
    • Source-level verifiers
    • Binary-level verifiers
    • Update verifiers

Process improvements

  • Write Mercurial hooks to enforce policies
    • Beef up the approval required hook
    • Make sure the bugs are correct / have a patch that has the right approvals
    • Warn release managers of lots of churn, big changes, changes to certain files, etc
  • Create tooling and processes to make source migrations less painful / error-prone
  • Investigate creating a patch forwarding system
  • Investigate formal spec writing for both QA and RelEng
    • Could be a formal way to ask what we want
    • Could be just dealing with the config generation ourselves
  • Create or drive tooling around snippet management
    • What is enabled, the upgrade paths available to users, etc
  • Come up with a nice triage and branch meeting plan
  • Make sure post-mortems happen and come up with a better framework for them
  • Brainstorm ways we can involve the community in RelMan more, implement what makes sense

Policies

  • Come up with EOL criteria and policies (working with product)
  • Come up with tree rule policies for each branch
  • Come up with notification policies if other rules are broken / need to change
  • Come up with SLAs for RelEng and QA