Spreadthunderbird

From MozillaWiki
Jump to navigation Jump to search

Background

People

Milestones

  • Current Bugs (Coming soon :-))

Bespoke modules and derivative theme

Contributed modules and themes

Meetings

Every Thursday on irc.mozilla.com #marketing

Getting Started

  1. Get drupal core
  2. Get the list of contributed modules
  3. Checkout our bespoke modules and our acquia derivate theme
  4. Test the code ...


For more specific detailed instructions on how to setup a local MAMP server for development , please click here For generic instructions on setting up a local server on different OS's please click here

How to develop STB

  1. Get svn access if you don't already
  2. Get a bug to work on
  3. Write code for the bug
  4. If the bug fixes a problem with a contributed module on drupal.org then create a patch and submit for review on drupal.org by the module maintainer. As soon as the patch is accepted and the module updated then update the ticket so that the module can be updated on STB. If the bug fixes a problem with bespoke code that is in SVN then create a patch upload to Bugzilla and request a review.Once the patch is accepted, commit to SVN with the bug # in the commit message and a brief description of what the patch does or the bug title. Add a comment to Bugzilla with the revision number of the commit: 'rXXXX'.
  5. Mark the bug as fixed
  6. QA verifies bug and marks as VERIFIED if it's really been fixed
  7. Please commit changes back to drupal.org wherever possible as it's important that we don't fork our distribution

Basic Functionality Testing

(Coming soon)

Do's and Don'ts

  • Use PEAR coding style
  • Always comment your code.
    • Function definition blocks at the least
    • Inline comments for complex code, use your best judgment
  • Always put a bug # and comment in your commit messages.
  • Don't embed HTML code in module files.
    • Define templates and keep presentation separate from logic code.
  • Don't touch the Drupal core. If you think you absolutely have to, ok it with another developer and document where and why you did so.
  • Don't push on Fridays or when you won't be around to verify the changes.

Staging Server

Deployment

  • File an IT bug requesting that changes on stage be synchronised with production
  • When IT closes the bug, verify the fixes/features are working.