1.1 --- a/es/mq-collab.tex	Sat Oct 18 15:44:41 2008 -0500
     1.2 +++ b/es/mq-collab.tex	Mon Jan 05 00:18:31 2009 -0500
     1.3 @@ -1,54 +1,61 @@
     1.4 -\chapter{Advanced uses of Mercurial Queues}
     1.5 +\chapter{Usos avanzados de las Colas de Mercurial}
     1.6  \label{chap:mq-collab}
     1.7  
     1.8 -While it's easy to pick up straightforward uses of Mercurial Queues,
     1.9 -use of a little discipline and some of MQ's less frequently used
    1.10 -capabilities makes it possible to work in complicated development
    1.11 -environments.
    1.12 -
    1.13 -In this chapter, I will use as an example a technique I have used to
    1.14 -manage the development of an Infiniband device driver for the Linux
    1.15 -kernel.  The driver in question is large (at least as drivers go),
    1.16 -with 25,000 lines of code spread across 35 source files.  It is
    1.17 -maintained by a small team of developers.
    1.18 -
    1.19 -While much of the material in this chapter is specific to Linux, the
    1.20 -same principles apply to any code base for which you're not the
    1.21 -primary owner, and upon which you need to do a lot of development.
    1.22 -
    1.23 -\section{The problem of many targets}
    1.24 -
    1.25 -The Linux kernel changes rapidly, and has never been internally
    1.26 -stable; developers frequently make drastic changes between releases.
    1.27 -This means that a version of the driver that works well with a
    1.28 -particular released version of the kernel will not even \emph{compile}
    1.29 -correctly against, typically, any other version.
    1.30 -
    1.31 -To maintain a driver, we have to keep a number of distinct versions of
    1.32 -Linux in mind.
    1.33 +Auunque es fácil aprender los usos más directos de las Colas de
    1.34 +Mercurial, tener algo de disciplina junto con algunas de las
    1.35 +capacidadees menos usadas de MQ hace posible trabajar en entornos de
    1.36 +desarrollo complejos.
    1.37 +
    1.38 +En este capítulo, usaré como ejemplo una técnica que he usado para
    1.39 +administrar el desarrollo de un controlador de dispositivo Infiniband
    1.40 +para el kernel de Linux. El controlador en cuestión es grande
    1.41 +(al menos en lo que se refiere a controladores), con 25,000 líneas de
    1.42 +código esparcidas en 35 ficheros fuente. Es mantenido por un equipo
    1.43 +pequeño de desarrolladores. 
    1.44 +
    1.45 +Aunque mucho del material en este capítulo es específico de Linux, los
    1.46 +mismos principios aplican a cualquier base de código de la que usted
    1.47 +no sea el propietario principal, y sobre la que usted necesita hacer
    1.48 +un montón de desarrollo.
    1.49 +
    1.50 +\section{El problema de múltiples objetivos}
    1.51 +
    1.52 +El kernel de Linux cambia con rapidez, y nunca ha sido estable
    1.53 +internamente; los desarrolladores hacen cambios drásticos entre
    1.54 +%TODO no encontré una traducción adecuada para "release". Por eso el
    1.55 +%cambio
    1.56 +versiones frecuentemente. Esto significa que una versión del
    1.57 +controlador que funciona bien con una versión particular del kernel ni
    1.58 +siquiera \emph{compilará} correctamente contra, típicamente, cualquier
    1.59 +otra versión.
    1.60 +
    1.61 +Para mantener un controlador, debemos tener en cuenta una buena
    1.62 +cantidad de versiones de Linux en mente.
    1.63  \begin{itemize}
    1.64 -\item One target is the main Linux kernel development tree.
    1.65 -  Maintenance of the code is in this case partly shared by other
    1.66 -  developers in the kernel community, who make ``drive-by''
    1.67 -  modifications to the driver as they develop and refine kernel
    1.68 -  subsystems.
    1.69 -\item We also maintain a number of ``backports'' to older versions of
    1.70 -  the Linux kernel, to support the needs of customers who are running
    1.71 -  older Linux distributions that do not incorporate our drivers.  (To
    1.72 -  \emph{backport} a piece of code is to modify it to work in an older
    1.73 -  version of its target environment than the version it was developed
    1.74 -  for.)
    1.75 -\item Finally, we make software releases on a schedule that is
    1.76 -  necessarily not aligned with those used by Linux distributors and
    1.77 -  kernel developers, so that we can deliver new features to customers
    1.78 -  without forcing them to upgrade their entire kernels or
    1.79 -  distributions.
    1.80 +\item Un objetivo es el árbol de desarrollo principal del kernel de
    1.81 +  Linux. En este caso el mantenimiento del código es compartido
    1.82 +  parcialmente por otros desarrolladores en la comunidad del kernel, 
    1.83 +  %TODO drive-by. 
    1.84 +  quienes hacen modificaciones ``de-afán'' al controlador a medida que 
    1.85 +  desarrollan y refinan subsistemas en el kernel.
    1.86 +  %TODO backport
    1.87 +\item También mantenemos algunos ``backports'' para versiones antiguas
    1.88 +  del kernel de Linux, para dar soporte a las necesidades de los
    1.89 +  clientes que están corriendo versiones antiguas de Linux que no
    1.90 +  incorporan nuestros controladores. (Hacer el \emph{backport} de un
    1.91 +  pedazo de código es modificarlo para que trabaje en una versión
    1.92 +  de su entorno objetivo anterior a aquella para la cual fue escrito.)
    1.93 +\item Finalmente, nosotros liberamos nuestro software de acuerdo a un
    1.94 +  cronograma que no necesariamente está alineado con el que usan los
    1.95 +  distribuidores de Linux y los desarrolladores del kernel, así que
    1.96 +  podemos entregar nuevas características a los clientes sin forzarlos
    1.97 +  a actualizar kernels completos o distribuciones.
    1.98  \end{itemize}
    1.99  
   1.100 -\subsection{Tempting approaches that don't work well}
   1.101 -
   1.102 -There are two ``standard'' ways to maintain a piece of software that
   1.103 -has to target many different environments.
   1.104 +\subsection{Aproximaciones tentadoras que no funcionan adecuadamente}
   1.105 +
   1.106 +Hay dos maneras estándar de mantener una porción de software que debe
   1.107 +funcionar en muchos entornos diferentes.
   1.108  
   1.109  The first is to maintain a number of branches, each intended for a
   1.110  single target.  The trouble with this approach is that you must