UX Branch: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
Line 20: Line 20:
* Backout your patch when it lands on mozilla-central.
* Backout your patch when it lands on mozilla-central.
* Since this branch is experimental, you do not need to make sure all tests pass, but it would be in your best interest to fix your patch, since a broken patch won't be able to land on mozilla-central later. There is a [http://tbpl.mozilla.org/?tree=UX UX branch TBPL] you can monitor.
* Since this branch is experimental, you do not need to make sure all tests pass, but it would be in your best interest to fix your patch, since a broken patch won't be able to land on mozilla-central later. There is a [http://tbpl.mozilla.org/?tree=UX UX branch TBPL] you can monitor.
* While patches that are works-in-progress can have known issues and still land on the UX branch, they should not cause the UX branch to fail to compile or be unable to perform the basic functions of a browser.


== What if I have questions? ==
== What if I have questions? ==


You can ask for help in #ux on irc.mozilla.org.
You can ask for help in #ux on irc.mozilla.org.

Revision as of 06:10, 2 August 2011

What is the UX branch?

The UX branch is a project branch for landing experimental UX changes before they are ready to land on mozilla-central. Developers can use this branch to gather feedback on un-reviewed patches and work with the UX team to iterate on UX design. After a final design is reached, patches must go through the normal review process before landing on mozilla-central.

Where is the UX branch?

The hg repository is available at: http://hg.mozilla.org/projects/ux

Nightly builds are available at: ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-ux/

What are the rules for the UX branch?

  • When you land a patch, add it to the UX branch etherpad. You should include:
    • Your name
    • Bug number
    • Changeset link
    • Any additional comments
  • If you iterate on your patch, you should backout your original changeset and re-land a new patch. This makes patches easy to track and prepares them for the normal review process.
  • When you push to the UX branch, you should be a good citizen and merge mozilla-central into the branch.
  • Backout your patch when it lands on mozilla-central.
  • Since this branch is experimental, you do not need to make sure all tests pass, but it would be in your best interest to fix your patch, since a broken patch won't be able to land on mozilla-central later. There is a UX branch TBPL you can monitor.
  • While patches that are works-in-progress can have known issues and still land on the UX branch, they should not cause the UX branch to fail to compile or be unable to perform the basic functions of a browser.

What if I have questions?

You can ask for help in #ux on irc.mozilla.org.