1.1 --- a/es/Leame.1st	Wed Jan 07 22:27:30 2009 -0500
     1.2 +++ b/es/Leame.1st	Wed Jan 07 23:19:40 2009 -0500
     1.3 @@ -109,7 +109,7 @@
     1.4  || mq.tex          || Igor Támara   ||    100%    || 06/12/2008 ||  13/12/2008 ||
     1.5  || hgext.tex       || Igor Támara   ||    100%    || 13/12/2008 ||  16/12/2008 ||
     1.6  || template.tex    || Igor Támara   ||    100%    || 27/12/2008 ||  01/01/2009 ||
     1.7 -|| mq-collab.tex   || Javier Rojas  ||     20%    || 04/01/2009 ||             ||
     1.8 +|| mq-collab.tex   || Javier Rojas  ||     48%    || 04/01/2009 ||             ||
     1.9  || mq-ref.tex      || Igor Támara   ||     30%    || 06/01/2009 ||             ||
    1.10  || cmdref.tex      || Igor Támara   ||    100%    || 01/01/2009 ||  01/01/2009 ||
    1.11  || license.tex     || Igor Támara   ||    100%    || 16/12/2008 ||  16/12/2008 ||

     2.1 --- a/es/mq-collab.tex	Wed Jan 07 22:27:30 2009 -0500
     2.2 +++ b/es/mq-collab.tex	Wed Jan 07 23:19:40 2009 -0500
     2.3 @@ -183,92 +183,99 @@
     2.4  tienen precedencia sobre los guardias positivos.
     2.5  \interaction{mq.guards.qselect.foobar}
     2.6  
     2.7 -\section{MQ's rules for applying patches}
     2.8 -
     2.9 -The rules that MQ uses when deciding whether to apply a patch
    2.10 -are as follows.
    2.11 +\section{Reglas de MQ para aplicar parches}
    2.12 +
    2.13 +Las reglas que MQ usa para decidir si debe aplicar un parche son las
    2.14 +siguientes.
    2.15  \begin{itemize}
    2.16 -\item A patch that has no guards is always applied.
    2.17 -\item If the patch has any negative guard that matches any currently
    2.18 -  selected guard, the patch is skipped.
    2.19 -\item If the patch has any positive guard that matches any currently
    2.20 -  selected guard, the patch is applied.
    2.21 -\item If the patch has positive or negative guards, but none matches
    2.22 -  any currently selected guard, the patch is skipped.
    2.23 +\item Un parche sin guardias es aplicado siempre.
    2.24 +\item Si el parche tiene algún guardia negativo que corresponda con
    2.25 +  cualquiera de los guardias seleccionados, se salta el parche.
    2.26 +\item Si el parche tiene algún guardia positivo que corresponda con
    2.27 +  cualquiera de los guardias seleccionados, se aplica el parche.
    2.28 +\item Si el parche tiene guardias positivos o negativos, pero ninguno
    2.29 +  corresponde con cualquiera de los guardias seleccionados, se salta
    2.30 +  el parche.
    2.31  \end{itemize}
    2.32  
    2.33 -\section{Trimming the work environment}
    2.34 -
    2.35 -In working on the device driver I mentioned earlier, I don't apply the
    2.36 -patches to a normal Linux kernel tree.  Instead, I use a repository
    2.37 -that contains only a snapshot of the source files and headers that are
    2.38 -relevant to Infiniband development.  This repository is~1\% the size
    2.39 -of a kernel repository, so it's easier to work with.
    2.40 -
    2.41 -I then choose a ``base'' version on top of which the patches are
    2.42 -applied.  This is a snapshot of the Linux kernel tree as of a revision
    2.43 -of my choosing.  When I take the snapshot, I record the changeset ID
    2.44 -from the kernel repository in the commit message.  Since the snapshot
    2.45 -preserves the ``shape'' and content of the relevant parts of the
    2.46 -kernel tree, I can apply my patches on top of either my tiny
    2.47 -repository or a normal kernel tree.
    2.48 -
    2.49 -Normally, the base tree atop which the patches apply should be a
    2.50 -snapshot of a very recent upstream tree.  This best facilitates the
    2.51 -development of patches that can easily be submitted upstream with few
    2.52 -or no modifications.
    2.53 -
    2.54 -\section{Dividing up the \sfilename{series} file}
    2.55 -
    2.56 -I categorise the patches in the \sfilename{series} file into a number
    2.57 -of logical groups.  Each section of like patches begins with a block
    2.58 -of comments that describes the purpose of the patches that follow.
    2.59 -
    2.60 -The sequence of patch groups that I maintain follows.  The ordering of
    2.61 -these groups is important; I'll describe why after I introduce the
    2.62 -groups.
    2.63 +\section{Podar el entorno de trabajo}
    2.64 +
    2.65 +En el trabajo del controlador de dispositivo que mencioné
    2.66 +anteriormente, yo no aplico los parches a un árbol normal del kernel
    2.67 +de Linux. En cambio, uso un repositorio que sólo contiene una
    2.68 +instantánea de los ficheros fuente y de cabecera que son relevantes
    2.69 +para el desarrollo de Infiniband. Este repositorio tiene un~1\% del
    2.70 +tamaño del repositorio del kernel, por lo que es más fácil trabajar
    2.71 +con él.
    2.72 +
    2.73 +Luego escojo una versión ``base'' sobre la cual son aplicados los
    2.74 +parches. Es una instantánea del árbol del kernel de Linux en una
    2.75 +revisión de mi elección. Cuando tomo la instantánea, almaceno el ID de
    2.76 +conjunto de cambios en el mensaje de consignación. Ya que la
    2.77 +instantánea preserva la ``forma'' y el contenido de las partes
    2.78 +relevantes del árbol del kernel, puedo aplicar mis parches sobre mi
    2.79 +pequeño repositorio o sobre un árbol normal del kernel.
    2.80 +
    2.81 +Normalmente, el árbol base sobre el que se aplican los parches debería
    2.82 +ser una instantánea de un árbol de desarrollo muy reciente. Esto
    2.83 +facilita mucho el desarrollo de parches que puedan ser enviados al
    2.84 +árbol oficial con pocas o ninguna modificación.
    2.85 +
    2.86 +\section{Dividir el fichero \sfilename{series}}
    2.87 +
    2.88 +Yo categorizo los parches en el fichero \sfilename{series} en una
    2.89 +serie de grupos lógicos. Cada sección de parches similares empieza con
    2.90 +un bloque de comentarios que describen el propósito de los parches que
    2.91 +le siguen.
    2.92 +
    2.93 +La secuencia de grupos de parches que mantengo se muestra a
    2.94 +continuación. El orden de los grupos es importante; explicaré porqué
    2.95 +luego de que presente los grupos.
    2.96  \begin{itemize}
    2.97 -\item The ``accepted'' group.  Patches that the development team has
    2.98 -  submitted to the maintainer of the Infiniband subsystem, and which
    2.99 -  he has accepted, but which are not present in the snapshot that the
   2.100 -  tiny repository is based on.  These are ``read only'' patches,
   2.101 -  present only to transform the tree into a similar state as it is in
   2.102 -  the upstream maintainer's repository.
   2.103 -\item The ``rework'' group.  Patches that I have submitted, but that
   2.104 -  the upstream maintainer has requested modifications to before he
   2.105 -  will accept them.
   2.106 -\item The ``pending'' group.  Patches that I have not yet submitted to
   2.107 -  the upstream maintainer, but which we have finished working on.
   2.108 -  These will be ``read only'' for a while.  If the upstream maintainer
   2.109 -  accepts them upon submission, I'll move them to the end of the
   2.110 -  ``accepted'' group.  If he requests that I modify any, I'll move
   2.111 -  them to the beginning of the ``rework'' group.
   2.112 -\item The ``in progress'' group.  Patches that are actively being
   2.113 -  developed, and should not be submitted anywhere yet.
   2.114 -\item The ``backport'' group.  Patches that adapt the source tree to
   2.115 -  older versions of the kernel tree.
   2.116 -\item The ``do not ship'' group.  Patches that for some reason should
   2.117 -  never be submitted upstream.  For example, one such patch might
   2.118 -  change embedded driver identification strings to make it easier to
   2.119 -  distinguish, in the field, between an out-of-tree version of the
   2.120 -  driver and a version shipped by a distribution vendor.
   2.121 +\item El grupo ``aceptado''. Son parches que el equipo de desarrollo
   2.122 +  ha enviado al mantenedor del subsistema Infiniband, y que él ha
   2.123 +  aceptado, pero que no están presentes en la instantánea en la cual
   2.124 +  está basada el repositorio pequeño. Estos son parches de
   2.125 +  ``sólo lectura'', presentes únicamente para transformar el árbol en
   2.126 +  un estado similar al del repositorio del mantenedor oficial.
   2.127 +\item El grupo ``revisar''. Parches que yo he enviado, pero sobre los
   2.128 +  que que el mantenedor oficial ha solicitado modificaciones antes de
   2.129 +  aceptarlos.
   2.130 +\item El grupo ``pendiente''. Parches que no he enviado al mantenedor
   2.131 +  oficial, pero que ya están terminados. Estos parches serán de
   2.132 +  ``sólo lectura'' por un buen tiempo. Si el mantenedor oficial los
   2.133 +  acepta cuando los envíe, los moveré al final del grupo ``aceptado''.
   2.134 +  Si él solicita que modificaciones en alguno de ellos, los moveré al
   2.135 +  principio del grupo ``revisar''.
   2.136 +\item El grupo ``en proceso''. Parches que están siendo activamente
   2.137 +  desarrollados, y no deberían ser enviados a ninguna parte aún.
   2.138 +\item El grupo ``backport''. Parches que adaptan el árbol de fuentes a
   2.139 +    versiones antiguas del árbol del kernel.
   2.140 +\item El grupo ``no enviar''. Parches que por alguna razón nunca deben
   2.141 +  ser enviados al mantenedor oficial del kernel. Por ejemplo, alguno
   2.142 +  de esos parches podría cambiar las cadenas de identificación
   2.143 +  embebidas del controlador para hacer más fácil la distinción, en
   2.144 +  pruebas de campo, entre una versión del controlador de
   2.145 +  salida-del-árbol  y una versión entregada por un vendedor de alguna
   2.146 +  distribución.
   2.147  \end{itemize}
   2.148  
   2.149 -Now to return to the reasons for ordering groups of patches in this
   2.150 -way.  We would like the lowest patches in the stack to be as stable as
   2.151 -possible, so that we will not need to rework higher patches due to
   2.152 -changes in context.  Putting patches that will never be changed first
   2.153 -in the \sfilename{series} file serves this purpose.
   2.154 -
   2.155 -We would also like the patches that we know we'll need to modify to be
   2.156 -applied on top of a source tree that resembles the upstream tree as
   2.157 -closely as possible.  This is why we keep accepted patches around for
   2.158 -a while.
   2.159 -
   2.160 -The ``backport'' and ``do not ship'' patches float at the end of the
   2.161 -\sfilename{series} file.  The backport patches must be applied on top
   2.162 -of all other patches, and the ``do not ship'' patches might as well
   2.163 -stay out of harm's way.
   2.164 +Ahora volvemos a las razones para ordenar los grupos de parches en
   2.165 +esta manera. Quisiéramos que los parches del fondo de la pila sean tan
   2.166 +estables como sea posible, para no tener que revisar parches más
   2.167 +arriba debido a cambios de contexto. Poner los parches que nunca
   2.168 +cambiarán en el primer lugar del fichero \sfilename{series} sirve a
   2.169 +este propósito.
   2.170 +
   2.171 +También desearíamos que los parches que sabemos que debemos modificar
   2.172 +sean aplicados sobre un árbol de fuentes que se parezca al oficial
   2.173 +tanto como sea posible. Es por esto que mantenemos los parches
   2.174 +aceptados disponibles por una buena cantidad de tiempo.
   2.175 +
   2.176 +Los parches ``backport'' y ``no enviar'' flotan al final del fichero
   2.177 +\sfilename{series}. Los parches de backport deben ser aplicados encima
   2.178 +de todos los otros parches, y los parches ``no enviar'' pueden
   2.179 +perfectamente quedarse fuera del camino.
   2.180  
   2.181  \section{Maintaining the patch series}
   2.182  
   2.183 @@ -293,7 +300,7 @@
   2.184    backports a piece of code to~2.6.9 will have a~\texttt{2.6.9} guard.
   2.185  \end{itemize}
   2.186  This variety of guards gives me considerable flexibility in
   2.187 -qdetermining what kind of source tree I want to end up with.  For most
   2.188 +determining what kind of source tree I want to end up with.  For most
   2.189  situations, the selection of appropriate guards is automated during
   2.190  the build process, but I can manually tune the guards to use for less
   2.191  common circumstances.