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
For Q2 the following projects are going on:
- Mobile friendliness
- Create design/coding standards for making sites mobile-friendly
- Use metrics to determine pages to focus on
- Begin implementing design/coding standards for mozilla.com
- Preparing for .com/.org merge
- Keep discussing strategy
- Analyze current workflows: http://etherpad.mozilla.com:9000/mozilla-com-dev-cycle
- Automated tests
- Hook up Raymond's tests and get them running on Hudson
- Write tons of more tests
- Git transition
- Work with localizers to warn them of switch
- Work with IT on switching live site to git
- Use github from then on
These mostly came out of Q2 onsite meetings.
Our general goals align with mozilla.org, see the following page for Q2 goals:
Work is developed, tested, and reviewed on trunk, pushed to staging to be queued for rollout, and pushed to a production branch to go live.
- dev works on a bug and makes a commit to trunk with bug number, leaves a comment on bug with trunk revision
- work is reviewed and when fixed, bug is marked "resolved fixed"
- add keyword "qawanted" to bug to move to testing
- bug is tested and re-opened if not fixed, marked "qa-verified-trunk" if fixed
- dev merges all changes into "stage" branch, leaves comment on bug with stage revision
- if change is a one-off, add keywork "push-needed" for immediate rollout
- bug is rolled out individually (push-needed) or with milestone (staging is merged onto production)
- and "push-needed" keywords are removed
- QA checks on production, marks "verified fixed"; if there's a problem, re-opens bug, 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,104 trunk tags/stage cd tags/stage && svn commit -m 'r100,104 from trunk for bug 60000' 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 to be rolled out.
QA usually tests on trunk (https://www-trunk.stage.mozilla.com/).
Mozilla.com SVN Source
- Trunk - the main development version of mozilla.com. Most work happens here.
- SVN location: http://viewvc.svn.mozilla.org/vc/projects/mozilla.com/trunk/
- Preview URL: https://www-trunk.stage.mozilla.com/
- Stage - When changes are ready in trunk, they are merged to stage for review before going to production.
- SVN location: http://viewvc.svn.mozilla.org/vc/projects/mozilla.com/tags/stage/
- Preview URL: https://www.authstage.mozilla.com/
- Production - The live website. Beware!
- SVN location: http://viewvc.svn.mozilla.org/vc/projects/mozilla.com/tags/production/
- Preview URL: https://www.mozilla.com/