Desarrollando en LibreOffice

From The Document Foundation Wiki
Jump to: navigation, search

Como involucrarse

Desarrolladores y usuarios pueden contribuir al desarrollo de LibreOffice en muchas formas y todos son bienvenidos en el proyecto. Usuarios, por ejemplo, pueden ayudar al desarrollo de pruebas beta de los lanzamientos del software, reportar y confirmar bugs, escribir documentación contribuir con plantillas, arte, diccionarios, etc. y la promoción de LibreOffice.

Desarrolladores pueden ayudar a la base de codigo de LibreOffice. Primero, lo extenso del codigo puede resultar intimidante, pero con la mejoras en la documentación y la asistencia que recibiras por el equipo de desarrolladores. Para una vista de la complejidad del código de LibreOffice, ver el sitio revisión del codigo para ayudarte a entender lo que contiene cada directorio en el repositorio.

Tambien hay una lista de Preguntas comunes.

Puedes seguir el desarrollo en lista de todos los commits en tiempo real (cortesia de cia.vc).

Reportando Bugs

El reporte y verificación de bugs es un muy valorada actividad dentro del desarrollo. Aquí esta la información de como dar de alta nuevos bugs.

Encontrando un problema para resolver y listar las mejoras faltantes

Una lista de Hacks fáciles ha sido recolectada para ayudar a encontrar tus primeras tareas. Claro que existe un bugtracker con bugs abiertos, algunos de ellos son marcados como HacksFaciles para su rápida detección. Y hay una lista de Ideas locas que algunas personas han comenzado a compilar.

Una página para recolectar ideas para mejoras de las experiencias de uso defacto, ha sido comenzada en Default Mejoras de interfaz.

Herramientas que empressa desearían tener

Another interesting feature list is 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!

Creando parches

Antes que nada, tiene sentido seguir los estandares de programación de OpenOffice.org Estilo de programación y convenciones generales (tales como nombramiento de variables y esquemas, etc). Para preparar un parche puedes enviarlo a la lista de desarrollo, asumimos que tu has comenzado con una rama maestra sin modificación, los pasos serían los siguientes:

  • Hackea el codigo hasta donde desees (si planeas algo mas grande, considera usar ramas de mejoras)
  • Comitea tus cambios locales en git. La primera opción agrega todos tus archivos modificados, mientras que la segunda opción te permite resolver cuales archivos se convierten en el commit:
git commit -a

 ... o ...

git add <archivo1> <archivo2> ...
git commit

Cuando escribas un mensaje de commit, usa la primera linea como resumen consiso de tus cambios. La segunda linea permanecera vacia y comenzando con la tercera linea puedes explicar como y que cambios se han realizado por esa razón.

  • Crea un archivo de parche y envialo por correo. Si estas en un repositorio puedes usar git directamente para obtener por ejemplo, los ultimos cambios de la rama como un archivo diff con:
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.

Alternado: Mostrando ramas git de donde jalar

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.

Lista de correo de desarrolladores - como usarse

Profavor lea esta página.

Creando tu primer build

Obteniendo tu primer build exitoso de LibreOffice puede ser intimidante y muchas veces una tarea pesada. Encuentra una guia que te puede dar los pasos que necesitas para tener tu primer build terminado en la pagina Como construir un build.


Usando Git para el desarrollo de LibreOffice

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 http://git-scm.com/ . The rest of this article will assume a basic working knowledge of Git.

Due to the large size of the project, the LibreOffice source code is spread among 19 distinct Git repositories. This creates new challenges even for avid git users.

If you are just interested in a cookbook of git command to use see Git For LibreOffice Developers

NOTE: you don't need to use './g' if you are working in just one repository. Just go to the repository's top directory (this would either be a directory off of 'libo' OR a directory in 'libo/clone/') and use straight git commands (i.e. 'git add', 'git commit').

./g

Uno de los cambios pincipales es que te encontraras es la necesidad de correr el mismo comando de git en todos los 19 repositorios. El repositorio bootstrap continue una pequeña utilería llamada g, localizada en ./g.

Muchos comandos que pueden tener tipos como git xxxx, pueden ser escritas ./g xxxx el cual significa 'corre git xxxx en cada repositorio contenido en ./clone/'.

Como defacto, para la mayoría de los comandos git, si un error ocurre ejecutando los comandos en cuada una de los repositorios de LibreOffice's git, ./g se parará y no aplicara los comandos en el resto de los repositorios. Para sobrellevar este comportamiento puede escribir ./bin/g -f xxxx.

Simplificando el uso de ./bin/g

./bin/g is normally not in your PATH. You could, of course, put it in your PATH, but that would prevent you from having multiple copies of the code base. Due to the time it takes to do a full clean build, I prefer having a second copy of the repositories, where I do mostly fresh make out of the development tip.

./bin/g not being in your PATH, makes typing the command cumbersome and error prone. The following little script - which is to be put in a directory that is in your PATH, under the name find-lo-bin - provides a solution for this problem:

#!/bin/bash

current_dir=`pwd`
while [ ${current_dir} != "/" -a -d "${current_dir}" -a ! -d "${current_dir}/.git" ] ;
do
current_dir=$(dirname "${current_dir}")
done
if [ $(basename $(dirname ${current_dir})) = "clone" ] ; then
current_dir=$(dirname $(dirname "${current_dir}"))
fi
echo "${current_dir}/bin"
unset current_dir

Now you can add this to your alias list (in your .bashrc for example):

alias g='$(find-lo-bin)/g'

With that in place, you can now just type 'g xxxx' as long as you are in a directory somewhere inside of the root LibreOffice repository.

Another limitation of ./bin/g is that it applies only to the git repositories in ./clone/ and not on the root git repository itself. More often than not, you will find yourself typing git xxx && ./bin/g xxx.

The following little script, called 'ga' provides a wrapper for just that:

#!/bin/bash

cd $(find-lo-bin)/..
if [ "$1" = "-f" ] ; then
shift
git "$@"
./bin/g -f "$@"
else
git "$@" && ./bin/g "$@"
fi
cd - > /dev/null

Grepping

You can use git grep instead of grep as it is much faster on large source trees by only looking at the files under revision control. And you can use g grep or ga grep to search on all the git repositories at once.

Another alternative is to use the opengrok web-based tool, which may be much faster than searching on your own machine.

Manejando las ramas de git

Mostrando las ramas actuales

To see which branch your repositories currently are on, issue:

~/loroot $ ./g branch

This lists the local branch for each repository and put a '*' in front of the one currently active. Every repository should report the same branch as active.

Adding -r after the branch command will show you the branches that are available on the remote repositores (e.g. the list of available feature branches).

Cambiando a la rama de funcionalidades

Let's create a new feature branch 'feature/slicebread' on all git repositories based on origin/master, which allows you to safely develop a new feature:

~/loroot $ ./g checkout -b feature/slicebread origin/master

If you display again the active branch, all repositories should report 'feature/slicebread'.

If you want to switch to an existing feature branch, rather than creating a new one, do:

~/loroot $ ./g -f checkout -b feature/slicebread origin/feature/slicebread

This will create a local branch 'feature/slicebread' which tracks the remote branch feature/slicebread. The -f forces bin/g to go through all repositories without aborting, even if some repositories don't have the branch.

Going back: If you ever want to go back to master and delete your local branch, make sure you don't have any uncommited changes in your repositories, then first go back to master, and then delete your local branchfeature/slicebread.

~/loroot $ ./g checkout master
~/loroot $ ./g -f branch -D feature/slicebread

Hack y 'commitea' en una rama de funcionalidades

Now you can hack and compile as you wish. Do not be shy about commiting your work. These commits are purely local and will not be visible until you publish them. You can always re-organize or fuse some commit later if you want to present a cleaner history. Each commit should contain a set of changes that are related to each other and be described clearly in the commit-log message. The first line of the commit-log message must be a concise (80 chars or less) summary of the change, then skip a line and enter a more detailed description as-needed.

Now you have implemented your new feature or you have made some progress and want to get some feedback.

First, since the master branch has probably changed since you branched-out your feature branch, you should rebase your changes, so that they apply to the most current master's HEAD.

To rebase, you need to make sure that you have committed everything that matters and clean-up your repository so that there are no changes 'pending'. Then return to the master branch with:

~/loroot $ ./g checkout master

Refresh your master branch

~/loroot $ ./g pull -r

Go back to your feature branch

~/loroot $ ./g checkout feature/slicebread

and rebase

~/loroot $ ./g rebase origin/master

If there are conflicts you need to resolve them manually and continue rebasing until you're done.

Now, it's time to publish. There are two cases.

If you do not have a set of git repositories to push these changes to, then you want to prepare a set of patches to be able to post them on the Dev-List for review.

~/loroot $ ./g format-patch --suffix=-@REPO@.patch --output-dir=<where_you_want> master..HEAD

This will generate a file per commit suffiexed by the repo name, in the directory you specified. You can then attach them to an email to the mailing list.

If you have the ability to push to a set of git repository, then

~/loroot $ ./g push origin feature/slicebread

There are plenty of excellent tutorials, books and even videos on how to use git. You are strongly encouraged to look into them. The LibreOffice Development Environment has 20 git repositories that are logically one but need to be cared for individually (hence the g and ga script).

Hackea y comitea en una rama estable

Stable branches are created from master or another stable branch to stabilize the code base for the release and further maintenance updates. There are just some rules during the beta phase:

  • allowed any bug fixes
  • allowed late features that are approved by Steering Committee
  • allowed any changes in translations

There are more strict rules during the release candidate phase:

  • allowed save fixes that are reviewed by another person, see below
  • allowed changes in translations; it is recommended to ask for review on the native l10n mailing list

Please, do not commit the fixes directly during the RC phase. Instead, please, ask another developer for review on the libreoffice@lists.freedesktop.org mailing list, personal mail, on irc or via the related bug entry. The fix should be commited by the reviewer using:

git commit -s --author='Author name <author@mail.address>'

Resetea tu repositorio modificado a uno nuevo

~/loroot $ bin/g reset --hard origin/master

will discard all your local changes (whether committed or not) and reset the current branch that you are on to the one on the remote repository.

Obteniendo y usando accesso a commit

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

Lineamientos generales de programación

sal_Bool should be used only when it comes to UNO, and bool is preferred otherwise.

The OpenOffice.org C++ coding standards.

The OpenOffice.org code conventions. For variable naming schemes etc.

Trabajando en una sección especifica de libreoffice

automake/configure

As currently implemented, there are two main configure.in files, one in the top-level build directory, and one in the libreoffice sub-directory. Any important changes should be made to both, as the top-level one is slated for removal once all the patch-sets currently in the system have been merged into the main code base.

The default arguments into the build system are currently in <loroot>/build/distro-configs.

Current configure options of the sub-level configure.in and also which options are top-level present only.

Hacking configure.in

Debugeando

Desarrollo / Notas de hackeo

Plan de lanzamiento