hgbook
changeset 497:58dbbfef964f
translated all of section 13.8
author | Javier Rojas <jerojasro@devnull.li> |
---|---|
date | Thu Jan 08 22:05:24 2009 -0500 (2009-01-08) |
parents | 2de9cda0c7f8 |
children | a8cdb3cac133 |
files | es/mq-collab.tex |
line diff
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