Personal tools

Mozilla.com

From MozillaWiki

(Difference between revisions)
Jump to: navigation, search
(Roadmap)
Line 19: Line 19:
 
= Roadmap =
 
= Roadmap =
  
[[https://wiki.mozilla.org/Mozilla.org/Roadmap_2011]]
+
https://wiki.mozilla.org/Mozilla.org/Roadmap_2011
  
 
mozilla.org and mozilla.com will be merging soon, and the above roadmap applies to both sites.
 
mozilla.org and mozilla.com will be merging soon, and the above roadmap applies to both sites.

Revision as of 13:26, 24 January 2011

mozilla.com was launched on November 29, 2005 with the Firefox 1.5 release with the goal of simplifying the experience of obtaining Mozilla products.

The mission of mozilla.com is to:

  • provide a quick and easy path for obtaining our software
  • educate visitors about the advantages of our software
  • connect users with other Mozilla web properties they may be looking for

The audiences for mozilla.com:

  • End users of Mozilla products (both consumers and power users)
  • Current Firefox and Thunderbird users looking for upgrade information
  • Visitors interested in information about Mozilla Corporation

Contents

Projects

Roadmap

https://wiki.mozilla.org/Mozilla.org/Roadmap_2011

mozilla.org and mozilla.com will be merging soon, and the above roadmap applies to both sites.

Workflow

Work is done on trunk, pushed through a staging branch for review/testing, and pushed to a production branch to go live.

  1. Dev works on a bug and makes a commit to trunk with bug number, leaves a comment on bug with trunk revision (multiple commits per bug are fine)
  2. When fixed, dev marks bug as "resolved fixed", merges all changes into "stage" branch, leaves comment on bug with stage revision
  3. If requesting code review (larger changes), attach patch from stage's revision and flag for review
  4. Add keyword "qawanted" to bug to move to testing
  5. QA checks on stage, approves by replacing the "qawanted" keyword with "qaverified"; if not, QA re-opens bug and removes "qawanted" keyword
  6. If the bug is ready to be pushed to production, anyone can add "push-needed" keyword. If the bug is waiting on a particular launch date, don't add this
  7. Dev pushes all related staging revisions (usually just one) to "prod" branch leaving commit with new revision number, removes "push-needed" keyword
  8. QA checks on production, marks "verified fixed"; if there's a problem, re-opens bug and removes "qaverified" keyword, dev might revert changes on production if problem is critical

Here are a few example SVN commands one might use:

commit to trunk (r100)
  svn commit -m 'bug 60000 - spread happiness around'

merge to staging (r50)
  svn merge --ignore-ancestry -c100 trunk tags/stage
  cd tags/stage && svn commit -m 'r100 from trunk for bug 60000'

get patch from staging
  cd tags/stage && svn diff -c50

merge to prod (r40)
  svn merge --ignore-ancestry -c50 tags/stage tags/prod
  cd tags/prod && svn commit -m 'r50 from staging for bug 60000'

revert on prod
  cd tags/prod && svn merge -c-40 .

The important point in this process is that the developer can commit what he/she wants to trunk, but he/she is responsible for merging those changes into stage. Since it potentially collapses many small commits into one large bugfix commit, it helps in the publishing process.

QA should always test on staging (https://www.authstage.mozilla.com/) to force devs to follow this process.

Mozilla.com SVN Source

The source behind mozilla.com (PHP, HTML, images, CSS, javascript, etc.) is hosted and managed in Subversion. For details merging from trunk to stage, see the SVN Guidelines.


Meeting Notes

Bugs

See all bugs related to mozilla.com

Docs