1.1 --- a/es/mq-collab.tex	Wed Jan 07 23:42:24 2009 -0500
     1.2 +++ b/es/mq-collab.tex	Thu Jan 08 22:05:24 2009 -0500
     1.3 @@ -308,33 +308,35 @@
     1.4  automatizada durante el proceso de compilación, pero puedo ajustar
     1.5  manualmente los guardias a usar para circunstancias poco comunes.
     1.6  
     1.7 -\subsection{The art of writing backport patches}
     1.8 -
     1.9 -Using MQ, writing a backport patch is a simple process.  All such a
    1.10 -patch has to do is modify a piece of code that uses a kernel feature
    1.11 -not present in the older version of the kernel, so that the driver
    1.12 -continues to work correctly under that older version.
    1.13 -
    1.14 -A useful goal when writing a good backport patch is to make your code
    1.15 -look as if it was written for the older version of the kernel you're
    1.16 -targeting.  The less obtrusive the patch, the easier it will be to
    1.17 -understand and maintain.  If you're writing a collection of backport
    1.18 -patches to avoid the ``rat's nest'' effect of lots of
    1.19 -\texttt{\#ifdef}s (hunks of source code that are only used
    1.20 -conditionally) in your code, don't introduce version-dependent
    1.21 -\texttt{\#ifdef}s into the patches.  Instead, write several patches,
    1.22 -each of which makes unconditional changes, and control their
    1.23 -application using guards.
    1.24 -
    1.25 -There are two reasons to divide backport patches into a distinct
    1.26 -group, away from the ``regular'' patches whose effects they modify.
    1.27 -The first is that intermingling the two makes it more difficult to use
    1.28 -a tool like the \hgext{patchbomb} extension to automate the process of
    1.29 -submitting the patches to an upstream maintainer.  The second is that
    1.30 -a backport patch could perturb the context in which a subsequent
    1.31 -regular patch is applied, making it impossible to apply the regular
    1.32 -patch cleanly \emph{without} the earlier backport patch already being
    1.33 -applied.
    1.34 +\subsection{El arte de escribir parches de backport}
    1.35 +
    1.36 +Al usar MQ, escribir un parche de backport es un proceso simple. Todo
    1.37 +lo que dicho parche debe hacer es modificar una sección de código que
    1.38 +usa una característica del kernel que no está presente en la versión
    1.39 +anterior del kernel, para que el controlador siga funcionando
    1.40 +correctamente en esa versión anterior.
    1.41 +
    1.42 +Una meta útil al escribir un buen parche de backport es hacer parecer
    1.43 +que el código hubiera sido escrito para la versión vieja del kernel
    1.44 +que usted tiene como objetivo. Entre menos intrusivo el parche, más
    1.45 +fácil será entenderlo y mantenerlo. Si usted está escribiendo una
    1.46 +colección de parches de backport para evitar el efecto de ``nido de
    1.47 +ratas'' de tener muchos \texttt{\#ifdef}s (secciones de código fuente
    1.48 +que sólo son usados condicionalmente) en su código, no introduzca
    1.49 +\texttt{\#ifdef}s dependientes de versiones específicas en los
    1.50 +parches. En vez de eso, escriba varios parches, cada uno de ellos
    1.51 +haciendo cambios incondicionales, y controle su aplicación usando
    1.52 +guardias.
    1.53 +
    1.54 +Hay dos razones para ubicar los parches de backport en un grupo
    1.55 +diferente, aparte de los parches ``regulares'' cuyos efectos son
    1.56 +modificados por ellos. La primera es que mezclar los dos hace más
    1.57 +difícil usar herramientas como la extensión \hgext{patchbomb} para
    1.58 +automatizar el proceso de enviar los parches a un mantenedor oficial.
    1.59 +La segunda es que un parche de backport puede perturbar el contexto en
    1.60 +el que se aplica un parche regular subsecuente, haciendo imposible
    1.61 +aplicar el parche normal limpiamente \emph{sin} que el parche de
    1.62 +backport sea aplicado antes.
    1.63  
    1.64  \section{Useful tips for developing with MQ}
    1.65