mozdev.org

• Saturday November 21st 2009
• All the leaves are brown …

Skip to Content

Mozile (xhtml editing in your browser)    

resources:	Home Use FAQ Contribute Mailing List Plan Source Code Bugs

Contribute

Mozile is an open source project. Everyone is welcome to contribute code, documentation, bug reports, internationalization, feature requests, etc. If you find Mozile useful and you want to make it better, please consider contributing your time and talents. Every bit of help is appreciated.

Mozile 0.8 is the focus of most new development. Mozile 0.6 is being maintained and updated to work with new Firefox versions. We continue to fix bugs and do minor maintenance the Mozile 0.7 code. Mozile 0.5 is no longer being developed.

Getting Started

All you need to contribute to Mozile is a web browser, a text editor, and a copy of the source code. There's documentation for users and developers available:

• General usage
• Mozile 0.8
• Mozile 0.7
• Mozile 0.6.23+ documentation

You can also take advantage of:

• our mailing list,
• our IRC chat room at irc://irc.freenode.net/#mozile

Report Bugs

If you find a bug, please report it.

Ideas for Improvements

Things we'd like to see in Mozile 0.8:

• Better support for Opera and Safari.
• Saving modules: Dialog, HTTPPost, (poerted from 0.7), WebDAV, FTP, ?
• Internationalization and localization support.
• Better list editing. Commands for moving list items up and down, and for creating sub-lists.
• A table editing module. Tools for inserting, removing, splitting, merging, etc.
• Better XML support. Complete the RNG validation system.
• Source editing and tag view (ported from 0.6).
• An extension version of Mozile for Mozilla browsers.
• A spell-checking system.
• Code optimization.
• More JsUnit tests.
• More demonstration pages.
• Documentation improvements.

Got a contribution or proposal? Just send an email to our mailing list.

Submitting Patches

If you've made a change to the Mozile code that you think will be useful to other people, please send it to us. We prefer to receive patch files, made against the latest CVS source. Remember to:

• Update the DocBook documentation file (mozile/www/0.8/doc/docbook/mozile.xml), if appropriate.
• Add your name under "Contributors" in the license block of each file you improve.
• Give the patch a descriptive name, including the Mozile version you're patching, a name for your patch and a version of your patch. For example mozile-0.8.0-inlineWhiteSpace-1.0.patch
• Add a few lines of description to the top of the file, following the sample below.
• Create a new bug report, with a clear description of what the patch does, and attach the patch file to the bug report.
• You may wish to send an email to our mailing list with a link to the bug report. More people read the mailing list than the list of new bug reports.

The following is a sample of a small patch, adapted from the Linux From Scratch patch submission guidelines. Starting with Index: core/core.js all the lines are the result of the diff operation. The lines above that have been added by the patch submitter.

Submitted By: James A. Overton 
Date: 2006-06-14
Initial Package Version: 0.8.0
Description: This is a sample patch. This was created so that there is an
             easy reference for those submitting patches.

Index: core/core.js
===================================================================
RCS file: /cvs/mozile/www/0.8/core/core.js,v
retrieving revision 1.12
diff -u -r1.12 core.js
--- core/core.js	14 Jun 2006 15:03:52 -0000	1.12
+++ core/core.js	14 Jun 2006 18:17:32 -0000
@@ -30,6 +30,8 @@
 // Ensure the global container is present.
 if(!mozile) throw Error("The 'mozile' object should have been defined in mozile.js, but it was not.");
 
+// Magical white space fix:
+mozile.foo();
 
 /**
  * Set the version number.

Creating Patches

If you're new to CVS, the source page has information on getting started. If you're new to patches, here's an explanation of how they work.

There's a fair amount of code in our CVS repository, and compared to the total each of the changes we make is small. It would be a pain to send a copy of the entire repository every time a change is made. So there are special tools for sharing just the information about the changes: diff to find the differences in Alice's code and store them in a "patch" file, which she can email to Benjamin, and patch to take the patch file and apply the changes to Benjamin's copy of the code.

Both diff and patch come with pretty much every Unix, Linux, and Mac OS X system (although you may need to install "developer" tools). You can also get a Windows version of diffutils. A diff tool is built in to CVS command line clients. And Integrated Development Environments (IDEs) like Eclipse often include CVS support and patching tools, if you prefer to use an IDE.

Before making a patch you might consider some of this advice on good patching practice. Here's a summary:

• Do send patches, don't send whole archives or files.
• Send patches against the current version of the code. Make sure your CVS working copy is up to date.
• Don't include patches for generated files. This includes all the documentation files other than the DocBook or XML originals (i.e. mozile/www/0.8/doc/docbook/*).
• Do use -c or -u format, don't use the default (-e) format.
• Do include documentation with your patch. Please include JSDoc comments with your code, and make changes to the DocBook or XML documentation files if it's appropriate.
• Do include an explanation with your patch.
• Do include useful comments in your code.
• Don't take it personally if your patch is rejected. There could be lots of reasons which don't reflect on you or the quality of your code.

The golden rule is that everyone is short on time, so we all do our best to make things quick and easy for each other.

Here are the steps you should usually take to create a patch file for Mozile:

• Go to the root directory of your working copy
  cd ~/working_copy/mozile/www/0.8/
• Make sure your CVS working copy is up to date
  cvs -d :pserver:guest@mozdev.org:/cvs update
• Resolve any issues caused by the update.
• Create the patch file with a descriptive name
  cvs -d :pserver:guest@mozdev.org:/cvs diff -R -uN > mozile-0.8.0-inlineWhiteSpace-1.0.patch
• Look over the patch file in your text editor, to make sure that everything worked properly and nothing unnecessary has been included.
• Follow the steps above to format and submit the patch.

Applying Patches

If you find a patch file (in our bug database or on our mailing list) which you'd like to try out, here are the general steps.

• To apply the path you will need a copy of the Mozile source. If you don't have one, get one from the source page.
• Make a backup of your working copy. If something goes wrong with the patch, you want to be able to restore your files quickly and easily.
• Open the patch in your text editor. Make sure that you have a good idea of what it will do. And make sure that the patch wasn't made against an out-of-date version of Mozile.
• Copy the patch file to the root directory of your working copy.
• Go to the root directory of your working copy
  cd ~/working_copy/mozile/www/0.8/
• Make sure your CVS working copy is up to date
  cvs -d :pserver:guest@mozdev.org:/cvs update
• Resolve any issues caused by the update.
• Apply the patch
  patch -p0 < mozile-0.8.0-inlineWhiteSpace-1.0.patch
• If the patch does not apply cleanly the first time, try changing -p0 to -p1, -p2, -p3, etc. This adjusts the way patch reads the file names inside the patch file.