1.1 --- a/es/mq-collab.tex	Wed Jan 07 22:26:07 2009 -0500
     1.2 +++ b/es/mq-collab.tex	Wed Jan 07 23:19:40 2009 -0500
     1.3 @@ -183,92 +183,99 @@
     1.4  tienen precedencia sobre los guardias positivos.
     1.5  \interaction{mq.guards.qselect.foobar}
     1.6  
     1.7 -\section{MQ's rules for applying patches}
     1.8 -
     1.9 -The rules that MQ uses when deciding whether to apply a patch
    1.10 -are as follows.
    1.11 +\section{Reglas de MQ para aplicar parches}
    1.12 +
    1.13 +Las reglas que MQ usa para decidir si debe aplicar un parche son las
    1.14 +siguientes.
    1.15  \begin{itemize}
    1.16 -\item A patch that has no guards is always applied.
    1.17 -\item If the patch has any negative guard that matches any currently
    1.18 -  selected guard, the patch is skipped.
    1.19 -\item If the patch has any positive guard that matches any currently
    1.20 -  selected guard, the patch is applied.
    1.21 -\item If the patch has positive or negative guards, but none matches
    1.22 -  any currently selected guard, the patch is skipped.
    1.23 +\item Un parche sin guardias es aplicado siempre.
    1.24 +\item Si el parche tiene algún guardia negativo que corresponda con
    1.25 +  cualquiera de los guardias seleccionados, se salta el parche.
    1.26 +\item Si el parche tiene algún guardia positivo que corresponda con
    1.27 +  cualquiera de los guardias seleccionados, se aplica el parche.
    1.28 +\item Si el parche tiene guardias positivos o negativos, pero ninguno
    1.29 +  corresponde con cualquiera de los guardias seleccionados, se salta
    1.30 +  el parche.
    1.31  \end{itemize}
    1.32  
    1.33 -\section{Trimming the work environment}
    1.34 -
    1.35 -In working on the device driver I mentioned earlier, I don't apply the
    1.36 -patches to a normal Linux kernel tree.  Instead, I use a repository
    1.37 -that contains only a snapshot of the source files and headers that are
    1.38 -relevant to Infiniband development.  This repository is~1\% the size
    1.39 -of a kernel repository, so it's easier to work with.
    1.40 -
    1.41 -I then choose a ``base'' version on top of which the patches are
    1.42 -applied.  This is a snapshot of the Linux kernel tree as of a revision
    1.43 -of my choosing.  When I take the snapshot, I record the changeset ID
    1.44 -from the kernel repository in the commit message.  Since the snapshot
    1.45 -preserves the ``shape'' and content of the relevant parts of the
    1.46 -kernel tree, I can apply my patches on top of either my tiny
    1.47 -repository or a normal kernel tree.
    1.48 -
    1.49 -Normally, the base tree atop which the patches apply should be a
    1.50 -snapshot of a very recent upstream tree.  This best facilitates the
    1.51 -development of patches that can easily be submitted upstream with few
    1.52 -or no modifications.
    1.53 -
    1.54 -\section{Dividing up the \sfilename{series} file}
    1.55 -
    1.56 -I categorise the patches in the \sfilename{series} file into a number
    1.57 -of logical groups.  Each section of like patches begins with a block
    1.58 -of comments that describes the purpose of the patches that follow.
    1.59 -
    1.60 -The sequence of patch groups that I maintain follows.  The ordering of
    1.61 -these groups is important; I'll describe why after I introduce the
    1.62 -groups.
    1.63 +\section{Podar el entorno de trabajo}
    1.64 +
    1.65 +En el trabajo del controlador de dispositivo que mencioné
    1.66 +anteriormente, yo no aplico los parches a un árbol normal del kernel
    1.67 +de Linux. En cambio, uso un repositorio que sólo contiene una
    1.68 +instantánea de los ficheros fuente y de cabecera que son relevantes
    1.69 +para el desarrollo de Infiniband. Este repositorio tiene un~1\% del
    1.70 +tamaño del repositorio del kernel, por lo que es más fácil trabajar
    1.71 +con él.
    1.72 +
    1.73 +Luego escojo una versión ``base'' sobre la cual son aplicados los
    1.74 +parches. Es una instantánea del árbol del kernel de Linux en una
    1.75 +revisión de mi elección. Cuando tomo la instantánea, almaceno el ID de
    1.76 +conjunto de cambios en el mensaje de consignación. Ya que la
    1.77 +instantánea preserva la ``forma'' y el contenido de las partes
    1.78 +relevantes del árbol del kernel, puedo aplicar mis parches sobre mi
    1.79 +pequeño repositorio o sobre un árbol normal del kernel.
    1.80 +
    1.81 +Normalmente, el árbol base sobre el que se aplican los parches debería
    1.82 +ser una instantánea de un árbol de desarrollo muy reciente. Esto
    1.83 +facilita mucho el desarrollo de parches que puedan ser enviados al
    1.84 +árbol oficial con pocas o ninguna modificación.
    1.85 +
    1.86 +\section{Dividir el fichero \sfilename{series}}
    1.87 +
    1.88 +Yo categorizo los parches en el fichero \sfilename{series} en una
    1.89 +serie de grupos lógicos. Cada sección de parches similares empieza con
    1.90 +un bloque de comentarios que describen el propósito de los parches que
    1.91 +le siguen.
    1.92 +
    1.93 +La secuencia de grupos de parches que mantengo se muestra a
    1.94 +continuación. El orden de los grupos es importante; explicaré porqué
    1.95 +luego de que presente los grupos.
    1.96  \begin{itemize}
    1.97 -\item The ``accepted'' group.  Patches that the development team has
    1.98 -  submitted to the maintainer of the Infiniband subsystem, and which
    1.99 -  he has accepted, but which are not present in the snapshot that the
   1.100 -  tiny repository is based on.  These are ``read only'' patches,
   1.101 -  present only to transform the tree into a similar state as it is in
   1.102 -  the upstream maintainer's repository.
   1.103 -\item The ``rework'' group.  Patches that I have submitted, but that
   1.104 -  the upstream maintainer has requested modifications to before he
   1.105 -  will accept them.
   1.106 -\item The ``pending'' group.  Patches that I have not yet submitted to
   1.107 -  the upstream maintainer, but which we have finished working on.
   1.108 -  These will be ``read only'' for a while.  If the upstream maintainer
   1.109 -  accepts them upon submission, I'll move them to the end of the
   1.110 -  ``accepted'' group.  If he requests that I modify any, I'll move
   1.111 -  them to the beginning of the ``rework'' group.
   1.112 -\item The ``in progress'' group.  Patches that are actively being
   1.113 -  developed, and should not be submitted anywhere yet.
   1.114 -\item The ``backport'' group.  Patches that adapt the source tree to
   1.115 -  older versions of the kernel tree.
   1.116 -\item The ``do not ship'' group.  Patches that for some reason should
   1.117 -  never be submitted upstream.  For example, one such patch might
   1.118 -  change embedded driver identification strings to make it easier to
   1.119 -  distinguish, in the field, between an out-of-tree version of the
   1.120 -  driver and a version shipped by a distribution vendor.
   1.121 +\item El grupo ``aceptado''. Son parches que el equipo de desarrollo
   1.122 +  ha enviado al mantenedor del subsistema Infiniband, y que él ha
   1.123 +  aceptado, pero que no están presentes en la instantánea en la cual
   1.124 +  está basada el repositorio pequeño. Estos son parches de
   1.125 +  ``sólo lectura'', presentes únicamente para transformar el árbol en
   1.126 +  un estado similar al del repositorio del mantenedor oficial.
   1.127 +\item El grupo ``revisar''. Parches que yo he enviado, pero sobre los
   1.128 +  que que el mantenedor oficial ha solicitado modificaciones antes de
   1.129 +  aceptarlos.
   1.130 +\item El grupo ``pendiente''. Parches que no he enviado al mantenedor
   1.131 +  oficial, pero que ya están terminados. Estos parches serán de
   1.132 +  ``sólo lectura'' por un buen tiempo. Si el mantenedor oficial los
   1.133 +  acepta cuando los envíe, los moveré al final del grupo ``aceptado''.
   1.134 +  Si él solicita que modificaciones en alguno de ellos, los moveré al
   1.135 +  principio del grupo ``revisar''.
   1.136 +\item El grupo ``en proceso''. Parches que están siendo activamente
   1.137 +  desarrollados, y no deberían ser enviados a ninguna parte aún.
   1.138 +\item El grupo ``backport''. Parches que adaptan el árbol de fuentes a
   1.139 +    versiones antiguas del árbol del kernel.
   1.140 +\item El grupo ``no enviar''. Parches que por alguna razón nunca deben
   1.141 +  ser enviados al mantenedor oficial del kernel. Por ejemplo, alguno
   1.142 +  de esos parches podría cambiar las cadenas de identificación
   1.143 +  embebidas del controlador para hacer más fácil la distinción, en
   1.144 +  pruebas de campo, entre una versión del controlador de
   1.145 +  salida-del-árbol  y una versión entregada por un vendedor de alguna
   1.146 +  distribución.
   1.147  \end{itemize}
   1.148  
   1.149 -Now to return to the reasons for ordering groups of patches in this
   1.150 -way.  We would like the lowest patches in the stack to be as stable as
   1.151 -possible, so that we will not need to rework higher patches due to
   1.152 -changes in context.  Putting patches that will never be changed first
   1.153 -in the \sfilename{series} file serves this purpose.
   1.154 -
   1.155 -We would also like the patches that we know we'll need to modify to be
   1.156 -applied on top of a source tree that resembles the upstream tree as
   1.157 -closely as possible.  This is why we keep accepted patches around for
   1.158 -a while.
   1.159 -
   1.160 -The ``backport'' and ``do not ship'' patches float at the end of the
   1.161 -\sfilename{series} file.  The backport patches must be applied on top
   1.162 -of all other patches, and the ``do not ship'' patches might as well
   1.163 -stay out of harm's way.
   1.164 +Ahora volvemos a las razones para ordenar los grupos de parches en
   1.165 +esta manera. Quisiéramos que los parches del fondo de la pila sean tan
   1.166 +estables como sea posible, para no tener que revisar parches más
   1.167 +arriba debido a cambios de contexto. Poner los parches que nunca
   1.168 +cambiarán en el primer lugar del fichero \sfilename{series} sirve a
   1.169 +este propósito.
   1.170 +
   1.171 +También desearíamos que los parches que sabemos que debemos modificar
   1.172 +sean aplicados sobre un árbol de fuentes que se parezca al oficial
   1.173 +tanto como sea posible. Es por esto que mantenemos los parches
   1.174 +aceptados disponibles por una buena cantidad de tiempo.
   1.175 +
   1.176 +Los parches ``backport'' y ``no enviar'' flotan al final del fichero
   1.177 +\sfilename{series}. Los parches de backport deben ser aplicados encima
   1.178 +de todos los otros parches, y los parches ``no enviar'' pueden
   1.179 +perfectamente quedarse fuera del camino.
   1.180  
   1.181  \section{Maintaining the patch series}
   1.182  
   1.183 @@ -293,7 +300,7 @@
   1.184    backports a piece of code to~2.6.9 will have a~\texttt{2.6.9} guard.
   1.185  \end{itemize}
   1.186  This variety of guards gives me considerable flexibility in
   1.187 -qdetermining what kind of source tree I want to end up with.  For most
   1.188 +determining what kind of source tree I want to end up with.  For most
   1.189  situations, the selection of appropriate guards is automated during
   1.190  the build process, but I can manually tune the guards to use for less
   1.191  common circumstances.