Releases/Quarterly Release Logistics Brainstorming: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
Line 37: Line 37:
* Crashes / ADU will become less useful for project branches. Will [https://bugzilla.mozilla.org/show_bug.cgi?id=619246 bug 619246] give more info before merge and perhaps lessen integration time?
* Crashes / ADU will become less useful for project branches. Will [https://bugzilla.mozilla.org/show_bug.cgi?id=619246 bug 619246] give more info before merge and perhaps lessen integration time?
* Create something like Chrome's about:labs and have a policy of landing controversial changes preffed off?
* Create something like Chrome's about:labs and have a policy of landing controversial changes preffed off?
** from a releng/build mechanics perspective this will come into play if those features can only be enabled with build-time flags or somesuch; otherwise seems more about architectural changes required in how we develop new features [[User:Beltzner|Beltzner]] 14:53, 15 December 2010 (PST)
* A/B testing for features via updates (or some other mechanism)?
* A/B testing for features via updates (or some other mechanism)?

Revision as of 22:53, 15 December 2010

This page is brainstorming what it would look like to change infrastructure / release processes to facilitate quarterly Firefox releases)

Overview

It might be helpful to think about this in three ways:

  1. How fixes will be landed
  2. How the repositories/branches will be structured and managed
  3. How builds will be created and tested out of the repositories/branches

Landing fixes

  • Do we want to support manual committing or something automated?
    • Automated example: nominated patches in bugzilla are checked in and run through the proper try repo and report back to the bug, approved patches are landed on the proper repo/branch, developers don't (ever?) land manually
      • Chrome does something like this I believe, WebKit has bugzilla integration with their "try" server to preflight patches
  • Do we want to force user interaction on commit to get additional metadata?
  • Do we want automated merging / fix forwarding / repository syncing?
  • More automated backouts?
  • More testing up front and rejecting commits?

Branch/Repo structure

  • Seems like consensus is forming to have project branches and integration/release branches
  • Likely needs to support multiple concurrent release development
    • That is, we don't clone FF4.2 right when FF4.1 is about to ship
  • Do we need a "trunk"?
  • Do we need "try"?
  • Support more than HG for repos?
    • Some projects might benefit from external hosting (GitHub, etc)
  • How do we merge from repo to repo? Changesets? Tags? Entire repos?
  • Code names rather than products with version numbers?

Build Mechanics

  • Created nightly? Created only when there are new changes?
  • Tests run every checkin on every repo?
  • How do we manage our test / nightly / beta audience
  • What channels?
  • What are they called? Minefield? Firefox? Have the repo name?

Misc

  • Crashes / ADU will become less useful for project branches. Will bug 619246 give more info before merge and perhaps lessen integration time?
  • Create something like Chrome's about:labs and have a policy of landing controversial changes preffed off?
    • from a releng/build mechanics perspective this will come into play if those features can only be enabled with build-time flags or somesuch; otherwise seems more about architectural changes required in how we develop new features Beltzner 14:53, 15 December 2010 (PST)
  • A/B testing for features via updates (or some other mechanism)?
Retrieved from "https://wiki.mozilla.org/index.php?title=Releases/Quarterly_Release_Logistics_Brainstorming&oldid=273880"