From The Document Foundation Wiki
Revision as of 2013-01-17T21:42:09 by Jmadero (Talk | contribs) (Finding a first task: Easy Hacks: List to All Confirmed Bugs + Minor Organization Edit)

Jump to: navigation, search

How to get involved

Developers and users can contribute to the LibreOffice development in many ways and everyone is welcome in the project. Users, for instance, can help the development by testing beta releases of the software, reporting and testing of bugs, writing documentation, contributing to templates, art work, thesaurus, dictionaries, etc. and last but not least promoting LibreOffice.

Developers can help to improve the LibreOffice code base. At first, the enormous code base can be intimidating, but documentation is improving and you will receive assistance by the existing developers team. To get started there is:

Reporting Bugs

Reporting bugs to the LibreOffice Bugtracker, verifying them and test whether issues still exist in newer versions of LibreOffice, are valuable contributions to the project. Here is information on how to submit new bugs.

Finding a first task: Easy Hacks

In order to set the entry barrier for new contributors as low as possible, the LibreOffice team has collected a list of Easy Hacks. It's purpose it to help you find a first task. For a general introduction, see Michael Meeks slides for the Easy Hacks Talk at FOSDEM 2012. Please note that any bug assigned to is unassigned (this is our default).

Of course there are also other bugs/enhancements in the bugtracker:

Lists of enhancements and missing features

Besides the Easy Hacks Wiki page, several other lists of enhancements and missing features have been created:

  • There is a list of Crazy Ideas that contain disruptive changes as well as other missing features.
  • A page dedicated to missing features and enhancements that are related to the special needs of large corporations, where IT management has some challenges in deployment and support. We listed in this page what enterprises have already told us they love to have in LibreOffice. If you want your boss happy, help us to fix these!
  • A page to collect ideas for improvements to the default user experience, has been started on Default UI Improvements.
  • A page which lists Really basic missing features and enhancements.
  • A list where users express their need for certain enhancements has been set up: Vote for Enhancement.

Preparing patches

First of all, it would make sense to follow the Coding Style and general code conventions (such as variable naming schemes, etc). To prepare a patch that you can send to the developers, you best

  • start with a unmodified master branch
  • Hack the code to your hearts content (if you plan something bigger, consider using feature branches)
  • commit your changes locally

Commiting your changes locally

To commit your changes locally to git, you first have to declare what to include. Here are two ways to do that:

  • This one adds all modified files: git commit -a
  • while git add file1 file2 allows you to explicitly select the files to include. see the Pro Git Book for the details.

Then do:

git commit

to locally commit your changes. When you type a commit message:

  • start the first line with a bug reference like fdo#12345, if you have one for your commit (see details below)
  • use the rest of the first line as a concise summary of your changes
  • the 2nd line remains empty
  • and starting on the 3rd line you can explain how and what changes have been made for what reasons.

If your patch fixes a bug that is already filed in Bugzilla, then you can take advantage of automatic bug-notifications that are triggered by commit-messages: When the first line of the commit message includes a reference to a bug in the form fdo#12345, then a corresponding comment will automatically be added to the bugreport, when the change is pushed to the repository. See the announcement-thread on or on fdo-listarchive for more details.

After commiting your change locally you have three options:

Sending patches directly to

You can push your patches to for review directly. Once you are set up (which is done in a minute) all you have to do is:

./logerrit submit

which will upload your local commit to gerrit. All the gory details are here.

Alternative: Sending patches manually to the mailing list

Alternatively, you can go oldschool and read these notes on how to use the development mailing list and then:

  • create the patch file that you want to mail. If you are in one repository you can use git directly to get e.g. the last change in your branch as a diff file with:
git format-patch HEAD~1

If you have made more wide sweeping changes across multiple repositories you can get those patches for all those repositories in one go with:

./g format-patch --suffix=.@REPO@.patch -o/home/me/somedir/to_save_my_patches_in origin/master..HEAD
  • create a mail to the development list and attach those patch files to your email.
  • Use a subject line of the form: "[PATCH] fdo#<bug number>: <Bug title>". For example: "[PATCH] fdo#43398: FORMATTING: Documents opened in LibreOffice Writer incorrectly appear as right justified".
  • after sending in your patch, if you want to go back to the regular upstream master, you can use the command:
./logerrit nextchange

or these manual instructions to get back to a prestine copy.

Please refer to the Patch Handling Guideline page for more detailed patch handling rules and workflow to make our patch integration process as efficient and painless as humanly possible.

Alternative: Offer git branches to pull from

LibreOffice being developed using git means of course that we can use all the wonderful features that git offers. E.g. people can prepare a cloned git branch that committers can pull patches from. If you plan to do that, it might be wise to coordinate with a committer in advance whether he feels comfortable in doing so.

General Programming Guidelines

Getting your first build done

Getting your first successful build of LibreOffice can be an intimidating and daunting task. Find a walkthrough that should guide you towards getting your first build finished on the How to Build page.

If you want to compile LibreOffice without GUI support (e.g. for servers) you can find additional information on the headless build page.

Using Git for LibreOffice development

Git is a Distributed Version Control System (DVCS). It is a very powerful yet simple system, but if you are unfamiliar with DVCS, it can be confusing. Thankfully there are great resources on the Web to learn about Git. If you are not familiar with it, you should visit .

Most of LibreOffice source code is in the 'core' git repository, but few modules are in separate repository: 'translations', help', 'dictionaries' and 'binfilter'. In most cases you probably won't have to modify these repositories, but if you do you might want to read Git For LibreOffice Developers about the ./g tool that should help you to make this a bit less painful.

Getting and using commit access

In order to get commit access you need to be "sponsored". Once you've submitted patches and got yourself recognised this won't be a problem, but it's best to wait until you're asked. Once you've been asked (or asked for someone to sponsor you), you need to get an account

code conventions

sal_Bool should be used only when it comes to UNO, and bool is preferred otherwise. More elaborate guidelines can be found:


Assertions and Logging

To assert invariants of the code (that can only be violated if there are programming errors) use standard C/C++ assert. Production builds define NDEBUG, while --enable-debug/--enable-dbgutil do not. Do not follow an assert with code intended to mitigate the consequences of the detected programming error in production builds.

To log warnings about unusual events (that the code nevertheless needs to handle in some way, like malformed input or I/O failures), use the SAL_WARN/SAL_WARN_IF macros from sal/log.hxx. It is generally better to report a detected problem up the call stack than to silence it locally. That is, a SAL_WARN is likely followed by a throw, and code should not catch and swallow exceptions that it cannot meaningfully handle.

To log other information useful for debugging, use the SAL_INFO/SAL_INFO_IF macros.

For temporary debug output, use the SAL_DEBUG macro. Commit hooks will prevent accidental committing of it.

The SAL_WARN/SAL_INFO macros are inactive in a production build; --enable-debug/--enable-dbgutil activates them. Which logging calls actually produce output is then further controlled by the SAL_LOG environment variable. See the documentation in sal/log.hxx for further details.

The functionality offered by osl/diagnose.h and tools/debug.hxx is obsoleted by sal/log.hxx.

Further developer hints