hgbook
changeset 494:f89480678965
translated section 13.7
author | Javier Rojas <jerojasro@devnull.li> |
---|---|
date | Wed Jan 07 23:19:40 2009 -0500 (2009-01-07) |
parents | b7b6a085056e |
children | dfa2890d9b30 |
files | es/Leame.1st es/mq-collab.tex |
line diff
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.