€•A      Œsphinx.addnodes”Œdocument”“”)”}”(Œ	rawsource”Œ ”Œchildren”]”(Œtranslations”ŒLanguagesNode”“”)”}”(hhh]”(h Œpending_xref”“”)”}”(hhh]”Œdocutils.nodes”ŒText”“”ŒEnglish”…””}”Œparent”hsbaŒ
attributes”}”(Œids”]”Œclasses”]”Œnames”]”Œdupnames”]”Œbackrefs”]”Œ	refdomain”Œstd”Œreftype”Œdoc”Œ	reftarget”Œ/process/5.Posting”Œmodname”NŒ	classname”NŒrefexplicit”ˆuŒtagname”hhhubh)”}”(hhh]”hŒChinese (Simplified)”…””}”hh2sbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ%/translations/zh_CN/process/5.Posting”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒChinese (Traditional)”…””}”hhFsbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ%/translations/zh_TW/process/5.Posting”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒItalian”…””}”hhZsbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ%/translations/it_IT/process/5.Posting”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒJapanese”…””}”hhnsbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ%/translations/ja_JP/process/5.Posting”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒKorean”…””}”hh‚sbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ%/translations/ko_KR/process/5.Posting”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubeh}”(h]”h ]”h"]”h$]”h&]”Œcurrent_language”ŒSpanish”uh1h
hhŒ	_document”hŒsource”NŒline”NubhŒwarning”“”)”}”(hX?  Si tiene alguna duda sobre la exactitud del contenido de esta
traducciÃ³n, la Ãºnica referencia vÃ¡lida es la documentaciÃ³n oficial en
inglÃ©s.
AdemÃ¡s, por defecto, los enlaces a documentos redirigen a la
documentaciÃ³n en inglÃ©s, incluso si existe una versiÃ³n traducida.
Consulte el Ã­ndice para mÃ¡s informaciÃ³n.”h]”hŒ	paragraph”“”)”}”(hX?  Si tiene alguna duda sobre la exactitud del contenido de esta
traducciÃ³n, la Ãºnica referencia vÃ¡lida es la documentaciÃ³n oficial en
inglÃ©s.
AdemÃ¡s, por defecto, los enlaces a documentos redirigen a la
documentaciÃ³n en inglÃ©s, incluso si existe una versiÃ³n traducida.
Consulte el Ã­ndice para mÃ¡s informaciÃ³n.”h]”hX?  Si tiene alguna duda sobre la exactitud del contenido de esta
traducciÃ³n, la Ãºnica referencia vÃ¡lida es la documentaciÃ³n oficial en
inglÃ©s.
AdemÃ¡s, por defecto, los enlaces a documentos redirigen a la
documentaciÃ³n en inglÃ©s, incluso si existe una versiÃ³n traducida.
Consulte el Ã­ndice para mÃ¡s informaciÃ³n.”…””}”(hh©hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸŒ2Documentation/translations/sp_SP/disclaimer-sp.rst”h Khh£ubah}”(h]”h ]”h"]”h$]”h&]”uh1h¡hhhžhhŸh·h NubhŒ
field_list”“”)”}”(hhh]”(hŒfield”“”)”}”(hhh]”(hŒ
field_name”“”)”}”(hŒOriginal”h]”hŒOriginal”…””}”(hhÊhžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÈhhÅhŸŒR/var/lib/git/docbuild/linux/Documentation/translations/sp_SP/process/5.Posting.rst”h K ubhŒ
field_body”“”)”}”(hŒ#Documentation/process/5.Posting.rst”h]”h¨)”}”(hhÝh]”hŒ#Documentation/process/5.Posting.rst”…””}”(hhßhžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh KhhÛubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙhhÅubeh}”(h]”h ]”h"]”h$]”h&]”uh1hÃhŸhØh KhhÀhžhubhÄ)”}”(hhh]”(hÉ)”}”(hŒ
Translator”h]”hŒ
Translator”…””}”(hhûhžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hÈhhøhŸhØh K ubhÚ)”}”(hŒVCarlos Bilbao <carlos.bilbao.osdev@gmail.com> and Avadhut Naik <avadhut.naik@amd.com>
”h]”h¨)”}”(hŒUCarlos Bilbao <carlos.bilbao.osdev@gmail.com> and Avadhut Naik <avadhut.naik@amd.com>”h]”(hŒCarlos Bilbao <”…””}”(hj  hžhhŸNh NubhŒ	reference”“”)”}”(hŒcarlos.bilbao.osdev@gmail.com”h]”hŒcarlos.bilbao.osdev@gmail.com”…””}”(hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”Œrefuri”Œ$mailto:carlos.bilbao.osdev@gmail.com”uh1j  hj  ubhŒ> and Avadhut Naik <”…””}”(hj  hžhhŸNh Nubj  )”}”(hŒavadhut.naik@amd.com”h]”hŒavadhut.naik@amd.com”…””}”(hj+  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”Œrefuri”Œmailto:avadhut.naik@amd.com”uh1j  hj  ubhŒ>”…””}”(hj  hžhhŸNh Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh Khj	  ubah}”(h]”h ]”h"]”h$]”h&]”uh1hÙhhøubeh}”(h]”h ]”h"]”h$]”h&]”uh1hÃhŸhØh KhhÀhžhubeh}”(h]”h ]”h"]”h$]”h&]”uh1h¾hhhžhhŸhØh KubhŒtarget”“”)”}”(hŒ.. _sp_development_posting:”h]”h}”(h]”h ]”h"]”h$]”h&]”Œrefid”Œsp-development-posting”uh1jW  h KhhhžhhŸhØubhŒsection”“”)”}”(hhh]”(hŒtitle”“”)”}”(hŒPublicaciÃ³n de parches”h]”hŒPublicaciÃ³n de parches”…””}”(hjl  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jj  hjg  hžhhŸhØh K	ubh¨)”}”(hXã  Tarde o temprano, llega el momento en que su trabajo estÃ© listo para ser
presentado a la comunidad para su revisiÃ³n y, eventualmente, su inclusiÃ³n
en el kernel mainline. Como era de esperar, la comunidad de desarrollo del
kernel ha desarrollado un conjunto de convenciones y procedimientos que se
utilizan en la publicaciÃ³n de parches; seguirlos harÃ¡ la vida mucho mÃ¡s
fÃ¡cil para todos los involucrados. Este documento intentarÃ¡ cubrir estas
expectativas con un detalle razonable; tambiÃ©n se puede encontrar mÃ¡s
informaciÃ³n en los archivos.
:ref:`Documentation/translations/sp_SP/process/submitting-patches.rst <sp_submittingpatches>`
and :ref:`Documentation/translations/sp_SP/process/submit-checklist.rst <sp_submitchecklist>`”h]”(hX(  Tarde o temprano, llega el momento en que su trabajo estÃ© listo para ser
presentado a la comunidad para su revisiÃ³n y, eventualmente, su inclusiÃ³n
en el kernel mainline. Como era de esperar, la comunidad de desarrollo del
kernel ha desarrollado un conjunto de convenciones y procedimientos que se
utilizan en la publicaciÃ³n de parches; seguirlos harÃ¡ la vida mucho mÃ¡s
fÃ¡cil para todos los involucrados. Este documento intentarÃ¡ cubrir estas
expectativas con un detalle razonable; tambiÃ©n se puede encontrar mÃ¡s
informaciÃ³n en los archivos.
”…””}”(hjz  hžhhŸNh Nubh)”}”(hŒ]:ref:`Documentation/translations/sp_SP/process/submitting-patches.rst <sp_submittingpatches>`”h]”hŒinline”“”)”}”(hj„  h]”hŒ?Documentation/translations/sp_SP/process/submitting-patches.rst”…””}”(hjˆ  hžhhŸNh Nubah}”(h]”h ]”(Œxref”Œstd”Œstd-ref”eh"]”h$]”h&]”uh1j†  hj‚  ubah}”(h]”h ]”h"]”h$]”h&]”Œrefdoc”Œ$translations/sp_SP/process/5.Posting”Œ	refdomain”j“  Œreftype”Œref”Œrefexplicit”ˆŒrefwarn”ˆŒ	reftarget”Œsp_submittingpatches”uh1hhŸhØh Khjz  ubhŒ
and ”…””}”(hjz  hžhhŸNh Nubh)”}”(hŒY:ref:`Documentation/translations/sp_SP/process/submit-checklist.rst <sp_submitchecklist>`”h]”j‡  )”}”(hj­  h]”hŒ=Documentation/translations/sp_SP/process/submit-checklist.rst”…””}”(hj¯  hžhhŸNh Nubah}”(h]”h ]”(j’  Œstd”Œstd-ref”eh"]”h$]”h&]”uh1j†  hj«  ubah}”(h]”h ]”h"]”h$]”h&]”Œrefdoc”jŸ  Œ	refdomain”j¹  Œreftype”Œref”Œrefexplicit”ˆŒrefwarn”ˆj¥  Œsp_submitchecklist”uh1hhŸhØh Khjz  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh Khjg  hžhubjf  )”}”(hhh]”(jk  )”}”(hŒCuando publicar”h]”hŒCuando publicar”…””}”(hjÔ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jj  hjÑ  hžhhŸhØh Kubh¨)”}”(hX  Hay una tentaciÃ³n constante de evitar publicar parches antes de que
estÃ©n completamente â€œlistosâ€. Para parches simples, eso no es un
problema. Sin embargo, si el trabajo que se estÃ¡ realizando es complejo,
hay mucho que ganar al obtener comentarios de la comunidad antes de que
se complete el trabajo. Por lo tanto, se deberÃ­a considerar publicar
trabajo en progreso, o incluso poner a disposiciÃ³n un Ã¡rbol de git para
que los desarrolladores interesados puedan ponerse al dÃ­a con su trabajo
en cualquier momento.”h]”hX  Hay una tentaciÃ³n constante de evitar publicar parches antes de que
estÃ©n completamente â€œlistosâ€. Para parches simples, eso no es un
problema. Sin embargo, si el trabajo que se estÃ¡ realizando es complejo,
hay mucho que ganar al obtener comentarios de la comunidad antes de que
se complete el trabajo. Por lo tanto, se deberÃ­a considerar publicar
trabajo en progreso, o incluso poner a disposiciÃ³n un Ã¡rbol de git para
que los desarrolladores interesados puedan ponerse al dÃ­a con su trabajo
en cualquier momento.”…””}”(hjâ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh KhjÑ  hžhubh¨)”}”(hX  Al publicar cÃ³digo que aÃºn no se considera listo para su inclusiÃ³n, es
una buena idea decirlo en la propia publicaciÃ³n. AdemÃ¡s, mencione
cualquier trabajo importante que aÃºn falte por hacer y cualquier problema
conocido. Menos personas mirarÃ¡n los parches que se sabe que estÃ¡n a
medias, pero aquellos que lo hagan vendrÃ¡n con la idea de que pueden
ayudarlo a llevar el trabajo en la direcciÃ³n correcta.”h]”hX  Al publicar cÃ³digo que aÃºn no se considera listo para su inclusiÃ³n, es
una buena idea decirlo en la propia publicaciÃ³n. AdemÃ¡s, mencione
cualquier trabajo importante que aÃºn falte por hacer y cualquier problema
conocido. Menos personas mirarÃ¡n los parches que se sabe que estÃ¡n a
medias, pero aquellos que lo hagan vendrÃ¡n con la idea de que pueden
ayudarlo a llevar el trabajo en la direcciÃ³n correcta.”…””}”(hjð  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh K"hjÑ  hžhubeh}”(h]”Œcuando-publicar”ah ]”h"]”Œcuando publicar”ah$]”h&]”uh1je  hjg  hžhhŸhØh Kubjf  )”}”(hhh]”(jk  )”}”(hŒAntes de crear parches”h]”hŒAntes de crear parches”…””}”(hj	  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jj  hj  hžhhŸhØh K*ubh¨)”}”(hŒlSe deben hacer varias cosas antes de considerar enviar parches a la
comunidad de desarrollo. Estas incluyen:”h]”hŒlSe deben hacer varias cosas antes de considerar enviar parches a la
comunidad de desarrollo. Estas incluyen:”…””}”(hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh K,hj  hžhubhŒblock_quote”“”)”}”(hXF  - Pruebe el cÃ³digo en la medida de lo posible. Utilice las herramientas
  de depuraciÃ³n del kernel, asegÃºrese de que el kernel se compilarÃ¡ con
  todas las combinaciones razonables de opciones de configuraciÃ³n, use
  compiladores cruzados para compilar para diferentes arquitecturas, etc.

- AsegÃºrese de que su cÃ³digo cumpla con las directrices de estilo de
  codificaciÃ³n del kernel.

- Â¿Su cambio tiene implicaciones de rendimiento? Si es asÃ­, debe ejecutar
  puntos de referencia que muestren cuÃ¡l es el impacto (o beneficio) de
  su cambio; se debe incluir un resumen de los resultados con el parche.

- AsegÃºrese de que tiene derecho a publicar el cÃ³digo. Si este trabajo
  se realizÃ³ para un empleador, es probable que el empleador tenga
  derecho al trabajo y debe estar de acuerdo con su lanzamiento bajo la
  GPL.
”h]”hŒbullet_list”“”)”}”(hhh]”(hŒ	list_item”“”)”}”(hX  Pruebe el cÃ³digo en la medida de lo posible. Utilice las herramientas
de depuraciÃ³n del kernel, asegÃºrese de que el kernel se compilarÃ¡ con
todas las combinaciones razonables de opciones de configuraciÃ³n, use
compiladores cruzados para compilar para diferentes arquitecturas, etc.
”h]”h¨)”}”(hX  Pruebe el cÃ³digo en la medida de lo posible. Utilice las herramientas
de depuraciÃ³n del kernel, asegÃºrese de que el kernel se compilarÃ¡ con
todas las combinaciones razonables de opciones de configuraciÃ³n, use
compiladores cruzados para compilar para diferentes arquitecturas, etc.”h]”hX  Pruebe el cÃ³digo en la medida de lo posible. Utilice las herramientas
de depuraciÃ³n del kernel, asegÃºrese de que el kernel se compilarÃ¡ con
todas las combinaciones razonables de opciones de configuraciÃ³n, use
compiladores cruzados para compilar para diferentes arquitecturas, etc.”…””}”(hj6  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh K/hj2  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j0  hj-  ubj1  )”}”(hŒ_AsegÃºrese de que su cÃ³digo cumpla con las directrices de estilo de
codificaciÃ³n del kernel.
”h]”h¨)”}”(hŒ^AsegÃºrese de que su cÃ³digo cumpla con las directrices de estilo de
codificaciÃ³n del kernel.”h]”hŒ^AsegÃºrese de que su cÃ³digo cumpla con las directrices de estilo de
codificaciÃ³n del kernel.”…””}”(hjN  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh K4hjJ  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j0  hj-  ubj1  )”}”(hŒØÂ¿Su cambio tiene implicaciones de rendimiento? Si es asÃ­, debe ejecutar
puntos de referencia que muestren cuÃ¡l es el impacto (o beneficio) de
su cambio; se debe incluir un resumen de los resultados con el parche.
”h]”h¨)”}”(hŒ×Â¿Su cambio tiene implicaciones de rendimiento? Si es asÃ­, debe ejecutar
puntos de referencia que muestren cuÃ¡l es el impacto (o beneficio) de
su cambio; se debe incluir un resumen de los resultados con el parche.”h]”hŒ×Â¿Su cambio tiene implicaciones de rendimiento? Si es asÃ­, debe ejecutar
puntos de referencia que muestren cuÃ¡l es el impacto (o beneficio) de
su cambio; se debe incluir un resumen de los resultados con el parche.”…””}”(hjf  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh K7hjb  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j0  hj-  ubj1  )”}”(hŒÔAsegÃºrese de que tiene derecho a publicar el cÃ³digo. Si este trabajo
se realizÃ³ para un empleador, es probable que el empleador tenga
derecho al trabajo y debe estar de acuerdo con su lanzamiento bajo la
GPL.
”h]”h¨)”}”(hŒÓAsegÃºrese de que tiene derecho a publicar el cÃ³digo. Si este trabajo
se realizÃ³ para un empleador, es probable que el empleador tenga
derecho al trabajo y debe estar de acuerdo con su lanzamiento bajo la
GPL.”h]”hŒÓAsegÃºrese de que tiene derecho a publicar el cÃ³digo. Si este trabajo
se realizÃ³ para un empleador, es probable que el empleador tenga
derecho al trabajo y debe estar de acuerdo con su lanzamiento bajo la
GPL.”…””}”(hj~  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh K;hjz  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j0  hj-  ubeh}”(h]”h ]”h"]”h$]”h&]”Œbullet”Œ-”uh1j+  hŸhØh K/hj'  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j%  hŸhØh K/hj  hžhubh¨)”}”(hŒvComo regla general, pensar un poco mÃ¡s antes de publicar el cÃ³digo casi
siempre compensa el esfuerzo en poco tiempo.”h]”hŒvComo regla general, pensar un poco mÃ¡s antes de publicar el cÃ³digo casi
siempre compensa el esfuerzo en poco tiempo.”…””}”(hj   hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh K@hj  hžhubeh}”(h]”Œantes-de-crear-parches”ah ]”h"]”Œantes de crear parches”ah$]”h&]”uh1je  hjg  hžhhŸhØh K*ubjf  )”}”(hhh]”(jk  )”}”(hŒPreparaciÃ³n del parche”h]”hŒPreparaciÃ³n del parche”…””}”(hj¹  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jj  hj¶  hžhhŸhØh KDubh¨)”}”(hŒÍLa preparaciÃ³n de parches para su publicaciÃ³n puede ser una cantidad
sorprendente de trabajo, pero, una vez mÃ¡s, intentar ahorrar tiempo aquÃ­
generalmente no es recomendable, ni siquiera a corto plazo.”h]”hŒÍLa preparaciÃ³n de parches para su publicaciÃ³n puede ser una cantidad
sorprendente de trabajo, pero, una vez mÃ¡s, intentar ahorrar tiempo aquÃ­
generalmente no es recomendable, ni siquiera a corto plazo.”…””}”(hjÇ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh KFhj¶  hžhubh¨)”}”(hXb  Los parches deben prepararse contra una versiÃ³n especÃ­fica del kernel.
Como regla general, un parche debe basarse en el mainline actual que se
encuentra en el Ã¡rbol git de Linus. Al basarse en el mainline, comience
con un punto de lanzamiento bien conocido, una versiÃ³n estable o -rc, en
lugar de bifurcarse fuera del mainline en un punto arbitrario.”h]”hXb  Los parches deben prepararse contra una versiÃ³n especÃ­fica del kernel.
Como regla general, un parche debe basarse en el mainline actual que se
encuentra en el Ã¡rbol git de Linus. Al basarse en el mainline, comience
con un punto de lanzamiento bien conocido, una versiÃ³n estable o -rc, en
lugar de bifurcarse fuera del mainline en un punto arbitrario.”…””}”(hjÕ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh KJhj¶  hžhubh¨)”}”(hXq  Puede ser necesario hacer revisiones contra -mm, linux-next o un Ã¡rbol de
subsistemas para facilitar pruebas y revisiones mÃ¡s amplias. Dependiendo
del Ã¡rea de su parche y de lo que estÃ© sucediendo en otros lugares, basar
un parche en estos otros Ã¡rboles puede requerir una cantidad significativa
de trabajo para resolver conflictos y lidiar con los cambios de API.”h]”hXq  Puede ser necesario hacer revisiones contra -mm, linux-next o un Ã¡rbol de
subsistemas para facilitar pruebas y revisiones mÃ¡s amplias. Dependiendo
del Ã¡rea de su parche y de lo que estÃ© sucediendo en otros lugares, basar
un parche en estos otros Ã¡rboles puede requerir una cantidad significativa
de trabajo para resolver conflictos y lidiar con los cambios de API.”…””}”(hjã  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh KPhj¶  hžhubh¨)”}”(hXa  Solo los cambios mÃ¡s simples deben formatearse como un solo parche; todo
lo demÃ¡s debe hacerse como una serie lÃ³gica de cambios. Dividir parches
es un poco un arte; algunos desarrolladores pasan mucho tiempo averiguando
cÃ³mo hacerlo de la manera que la comunidad espera. Sin embargo, hay
algunas reglas generales que pueden ayudar considerablemente:”h]”hXa  Solo los cambios mÃ¡s simples deben formatearse como un solo parche; todo
lo demÃ¡s debe hacerse como una serie lÃ³gica de cambios. Dividir parches
es un poco un arte; algunos desarrolladores pasan mucho tiempo averiguando
cÃ³mo hacerlo de la manera que la comunidad espera. Sin embargo, hay
algunas reglas generales que pueden ayudar considerablemente:”…””}”(hjñ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh KVhj¶  hžhubj&  )”}”(hX¹	  - La serie de parches que publique casi seguramente no serÃ¡ la serie de
  cambios que se encuentran en su sistema de control de revisiones. En su
  lugar, los cambios que ha realizado deben considerarse en su forma
  final y luego dividirse de manera que tengan sentido. A los
  desarrolladores les interesan los cambios discretos y autÃ³nomos, no el
  camino que tomÃ³ para llegar a esos cambios.

- Cada cambio lÃ³gicamente independiente debe formatearse como un parche
  separado. Estos cambios pueden ser pequeÃ±os (â€œagregar un campo a esta
  estructuraâ€) o grandes (agregar un nuevo controlador significativo,
  por ejemplo), pero deben ser conceptualmente pequeÃ±os y susceptibles
  de una descripciÃ³n de una lÃ­nea. Cada parche debe hacer un cambio
  especifico que pueda ser revisado por sÃ­ mismo y verificado para hacer
  lo que dice que hace.

- Para reafirmar la pauta anterior: no mezcle diferentes tipos de cambios
  en el mismo parche. Si un solo parche corrige un error de seguridad
  crÃ­tico, reorganiza algunas estructuras y reformatea el cÃ³digo, es muy
  probable que se pase por alto y se pierda la soluciÃ³n importante.

- Cada parche debe producir un kernel que se compile y funcione
  correctamente; si su serie de parches se interrumpe en el medio, el
  resultado deberÃ­a seguir siendo un kernel funcional. La aplicaciÃ³n
  parcial de una serie de parches es un escenario comÃºn cuando se
  utiliza la herramienta â€œgit bisectâ€ para encontrar regresiones; si
  el resultado es un kernel roto, harÃ¡ la vida mÃ¡s difÃ­cil para los
  desarrolladores y usuarios que participan en el noble trabajo de
  rastrear problemas.

- Sin embargo, no lo exagere. Un desarrollador una vez publicÃ³ un conjunto
  de ediciones en un solo archivo como 500 parches separados â€“ un acto
  que no lo convirtiÃ³ en la persona mÃ¡s popular en la lista de correo del
  kernel. Un solo parche puede ser razonablemente grande si todavÃ­a
  contiene un solo cambio *lÃ³gico*.

- Puede ser tentador agregar una infraestructura completamente nueva con
  una serie de parches, pero dejar esa infraestructura sin usar hasta el
  parche final de la serie lo habilite todo. Esta tentaciÃ³n debe evitarse
  si es posible; si esa serie agrega regresiones, bisection seÃ±alarÃ¡ el
  ultimo parche como el que causÃ³ el problema, aunque el error real estÃ©
  en otra parte. Siempre que sea posible, un parche que agregue cÃ³digo
  nuevo debe hacer que ese cÃ³digo se active de inmediato.
”h]”j,  )”}”(hhh]”(j1  )”}”(hXƒ  La serie de parches que publique casi seguramente no serÃ¡ la serie de
cambios que se encuentran en su sistema de control de revisiones. En su
lugar, los cambios que ha realizado deben considerarse en su forma
final y luego dividirse de manera que tengan sentido. A los
desarrolladores les interesan los cambios discretos y autÃ³nomos, no el
camino que tomÃ³ para llegar a esos cambios.
”h]”h¨)”}”(hX‚  La serie de parches que publique casi seguramente no serÃ¡ la serie de
cambios que se encuentran en su sistema de control de revisiones. En su
lugar, los cambios que ha realizado deben considerarse en su forma
final y luego dividirse de manera que tengan sentido. A los
desarrolladores les interesan los cambios discretos y autÃ³nomos, no el
camino que tomÃ³ para llegar a esos cambios.”h]”hX‚  La serie de parches que publique casi seguramente no serÃ¡ la serie de
cambios que se encuentran en su sistema de control de revisiones. En su
lugar, los cambios que ha realizado deben considerarse en su forma
final y luego dividirse de manera que tengan sentido. A los
desarrolladores les interesan los cambios discretos y autÃ³nomos, no el
camino que tomÃ³ para llegar a esos cambios.”…””}”(hj
  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh K\hj  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j0  hj  ubj1  )”}”(hX¾  Cada cambio lÃ³gicamente independiente debe formatearse como un parche
separado. Estos cambios pueden ser pequeÃ±os (â€œagregar un campo a esta
estructuraâ€) o grandes (agregar un nuevo controlador significativo,
por ejemplo), pero deben ser conceptualmente pequeÃ±os y susceptibles
de una descripciÃ³n de una lÃ­nea. Cada parche debe hacer un cambio
especifico que pueda ser revisado por sÃ­ mismo y verificado para hacer
lo que dice que hace.
”h]”h¨)”}”(hX½  Cada cambio lÃ³gicamente independiente debe formatearse como un parche
separado. Estos cambios pueden ser pequeÃ±os (â€œagregar un campo a esta
estructuraâ€) o grandes (agregar un nuevo controlador significativo,
por ejemplo), pero deben ser conceptualmente pequeÃ±os y susceptibles
de una descripciÃ³n de una lÃ­nea. Cada parche debe hacer un cambio
especifico que pueda ser revisado por sÃ­ mismo y verificado para hacer
lo que dice que hace.”h]”hX½  Cada cambio lÃ³gicamente independiente debe formatearse como un parche
separado. Estos cambios pueden ser pequeÃ±os (â€œagregar un campo a esta
estructuraâ€) o grandes (agregar un nuevo controlador significativo,
por ejemplo), pero deben ser conceptualmente pequeÃ±os y susceptibles
de una descripciÃ³n de una lÃ­nea. Cada parche debe hacer un cambio
especifico que pueda ser revisado por sÃ­ mismo y verificado para hacer
lo que dice que hace.”…””}”(hj"  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh Kchj  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j0  hj  ubj1  )”}”(hX  Para reafirmar la pauta anterior: no mezcle diferentes tipos de cambios
en el mismo parche. Si un solo parche corrige un error de seguridad
crÃ­tico, reorganiza algunas estructuras y reformatea el cÃ³digo, es muy
probable que se pase por alto y se pierda la soluciÃ³n importante.
”h]”h¨)”}”(hX  Para reafirmar la pauta anterior: no mezcle diferentes tipos de cambios
en el mismo parche. Si un solo parche corrige un error de seguridad
crÃ­tico, reorganiza algunas estructuras y reformatea el cÃ³digo, es muy
probable que se pase por alto y se pierda la soluciÃ³n importante.”h]”hX  Para reafirmar la pauta anterior: no mezcle diferentes tipos de cambios
en el mismo parche. Si un solo parche corrige un error de seguridad
crÃ­tico, reorganiza algunas estructuras y reformatea el cÃ³digo, es muy
probable que se pase por alto y se pierda la soluciÃ³n importante.”…””}”(hj:  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh Kkhj6  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j0  hj  ubj1  )”}”(hXé  Cada parche debe producir un kernel que se compile y funcione
correctamente; si su serie de parches se interrumpe en el medio, el
resultado deberÃ­a seguir siendo un kernel funcional. La aplicaciÃ³n
parcial de una serie de parches es un escenario comÃºn cuando se
utiliza la herramienta â€œgit bisectâ€ para encontrar regresiones; si
el resultado es un kernel roto, harÃ¡ la vida mÃ¡s difÃ­cil para los
desarrolladores y usuarios que participan en el noble trabajo de
rastrear problemas.
”h]”h¨)”}”(hXè  Cada parche debe producir un kernel que se compile y funcione
correctamente; si su serie de parches se interrumpe en el medio, el
resultado deberÃ­a seguir siendo un kernel funcional. La aplicaciÃ³n
parcial de una serie de parches es un escenario comÃºn cuando se
utiliza la herramienta â€œgit bisectâ€ para encontrar regresiones; si
el resultado es un kernel roto, harÃ¡ la vida mÃ¡s difÃ­cil para los
desarrolladores y usuarios que participan en el noble trabajo de
rastrear problemas.”h]”hXè  Cada parche debe producir un kernel que se compile y funcione
correctamente; si su serie de parches se interrumpe en el medio, el
resultado deberÃ­a seguir siendo un kernel funcional. La aplicaciÃ³n
parcial de una serie de parches es un escenario comÃºn cuando se
utiliza la herramienta â€œgit bisectâ€ para encontrar regresiones; si
el resultado es un kernel roto, harÃ¡ la vida mÃ¡s difÃ­cil para los
desarrolladores y usuarios que participan en el noble trabajo de
rastrear problemas.”…””}”(hjR  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh KphjN  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j0  hj  ubj1  )”}”(hXA  Sin embargo, no lo exagere. Un desarrollador una vez publicÃ³ un conjunto
de ediciones en un solo archivo como 500 parches separados â€“ un acto
que no lo convirtiÃ³ en la persona mÃ¡s popular en la lista de correo del
kernel. Un solo parche puede ser razonablemente grande si todavÃ­a
contiene un solo cambio *lÃ³gico*.
”h]”h¨)”}”(hX@  Sin embargo, no lo exagere. Un desarrollador una vez publicÃ³ un conjunto
de ediciones en un solo archivo como 500 parches separados â€“ un acto
que no lo convirtiÃ³ en la persona mÃ¡s popular en la lista de correo del
kernel. Un solo parche puede ser razonablemente grande si todavÃ­a
contiene un solo cambio *lÃ³gico*.”h]”(hX6  Sin embargo, no lo exagere. Un desarrollador una vez publicÃ³ un conjunto
de ediciones en un solo archivo como 500 parches separados â€“ un acto
que no lo convirtiÃ³ en la persona mÃ¡s popular en la lista de correo del
kernel. Un solo parche puede ser razonablemente grande si todavÃ­a
contiene un solo cambio ”…””}”(hjj  hžhhŸNh NubhŒemphasis”“”)”}”(hŒ	*lÃ³gico*”h]”hŒlÃ³gico”…””}”(hjt  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jr  hjj  ubhŒ.”…””}”(hjj  hžhhŸNh Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh Kyhjf  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j0  hj  ubj1  )”}”(hXç  Puede ser tentador agregar una infraestructura completamente nueva con
una serie de parches, pero dejar esa infraestructura sin usar hasta el
parche final de la serie lo habilite todo. Esta tentaciÃ³n debe evitarse
si es posible; si esa serie agrega regresiones, bisection seÃ±alarÃ¡ el
ultimo parche como el que causÃ³ el problema, aunque el error real estÃ©
en otra parte. Siempre que sea posible, un parche que agregue cÃ³digo
nuevo debe hacer que ese cÃ³digo se active de inmediato.
”h]”h¨)”}”(hXæ  Puede ser tentador agregar una infraestructura completamente nueva con
una serie de parches, pero dejar esa infraestructura sin usar hasta el
parche final de la serie lo habilite todo. Esta tentaciÃ³n debe evitarse
si es posible; si esa serie agrega regresiones, bisection seÃ±alarÃ¡ el
ultimo parche como el que causÃ³ el problema, aunque el error real estÃ©
en otra parte. Siempre que sea posible, un parche que agregue cÃ³digo
nuevo debe hacer que ese cÃ³digo se active de inmediato.”h]”hXæ  Puede ser tentador agregar una infraestructura completamente nueva con
una serie de parches, pero dejar esa infraestructura sin usar hasta el
parche final de la serie lo habilite todo. Esta tentaciÃ³n debe evitarse
si es posible; si esa serie agrega regresiones, bisection seÃ±alarÃ¡ el
ultimo parche como el que causÃ³ el problema, aunque el error real estÃ©
en otra parte. Siempre que sea posible, un parche que agregue cÃ³digo
nuevo debe hacer que ese cÃ³digo se active de inmediato.”…””}”(hj–  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh Khj’  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j0  hj  ubeh}”(h]”h ]”h"]”h$]”h&]”j˜  j™  uh1j+  hŸhØh K\hjÿ  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j%  hŸhØh K\hj¶  hžhubh¨)”}”(hŒîTrabajar para crear la serie de parches perfecta puede ser un proceso
frustrante que lleva mucho tiempo y reflexiÃ³n despuÃ©s de que el â€œtrabajo
realâ€ se ha hecho. Sin embargo, cuando se hace correctamente, es un tiempo
bien empleado.”h]”hŒîTrabajar para crear la serie de parches perfecta puede ser un proceso
frustrante que lleva mucho tiempo y reflexiÃ³n despuÃ©s de que el â€œtrabajo
realâ€ se ha hecho. Sin embargo, cuando se hace correctamente, es un tiempo
bien empleado.”…””}”(hj¶  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh K‡hj¶  hžhubeh}”(h]”Œpreparacion-del-parche”ah ]”h"]”ŒpreparaciÃ³n del parche”ah$]”h&]”uh1je  hjg  hžhhŸhØh KDubjf  )”}”(hhh]”(jk  )”}”(hŒ)Formato de parches y registros de cambios”h]”hŒ)Formato de parches y registros de cambios”…””}”(hjÏ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jj  hjÌ  hžhhŸhØh Kubh¨)”}”(hX  AsÃ­ que ahora tiene una serie perfecta de parches para publicar, pero el
trabajo aÃºn no se ha hecho. Cada parche necesita ser formateado en un
mensaje que comunique rÃ¡pida y claramente su propÃ³sito al resto del
mundo. A tal fin, cada parche se compondrÃ¡ de lo siguiente:”h]”hX  AsÃ­ que ahora tiene una serie perfecta de parches para publicar, pero el
trabajo aÃºn no se ha hecho. Cada parche necesita ser formateado en un
mensaje que comunique rÃ¡pida y claramente su propÃ³sito al resto del
mundo. A tal fin, cada parche se compondrÃ¡ de lo siguiente:”…””}”(hjÝ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh KhjÌ  hžhubj&  )”}”(hX  - Una lÃ­nea opcional â€œFromâ€ que nombra al autor del parche. Esta lÃ­nea
  solo es necesaria si pasa el parche de otra persona por correo
  electrÃ³nico, pero nunca estÃ¡ de mÃ¡s agregarla en caso de duda.

- Una descripciÃ³n de una lÃ­nea de lo que hace el parche. Este mensaje
  deberÃ­a ser suficiente para que un lector que lo vea sin otro contexto
  pueda entender el alcance del parche; la lÃ­nea aparecerÃ¡ en los
  registros de cambios de â€œforma cortaâ€. Este mensaje generalmente se
  formatea con el nombre del subsistema relevante primero, seguido del
  propÃ³sito del parche. Por ejemplo:

  ::

       gpio: fix build on CONFIG_GPIO_SYSFS=n

- Una lÃ­nea en blanco seguida de una descripciÃ³n detallada del contenido
  del parche. Esta descripciÃ³n puede ser tan larga como sea necesario;
  deberÃ­a decir quÃ© hace el parche y por quÃ© debe aplicarse al kernel.

- Una o mÃ¡s lÃ­neas de etiquetas, con, como mÃ­nimo, una lÃ­nea
  Signed-off-by: del autor del parche. Las etiquetas se describirÃ¡n con
  mÃ¡s detalle a continuaciÃ³n.
”h]”j,  )”}”(hhh]”(j1  )”}”(hŒÌUna lÃ­nea opcional â€œFromâ€ que nombra al autor del parche. Esta lÃ­nea
solo es necesaria si pasa el parche de otra persona por correo
electrÃ³nico, pero nunca estÃ¡ de mÃ¡s agregarla en caso de duda.
”h]”h¨)”}”(hŒËUna lÃ­nea opcional â€œFromâ€ que nombra al autor del parche. Esta lÃ­nea
solo es necesaria si pasa el parche de otra persona por correo
electrÃ³nico, pero nunca estÃ¡ de mÃ¡s agregarla en caso de duda.”h]”hŒËUna lÃ­nea opcional â€œFromâ€ que nombra al autor del parche. Esta lÃ­nea
solo es necesaria si pasa el parche de otra persona por correo
electrÃ³nico, pero nunca estÃ¡ de mÃ¡s agregarla en caso de duda.”…””}”(hjö  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh K”hjò  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j0  hjï  ubj1  )”}”(hX²  Una descripciÃ³n de una lÃ­nea de lo que hace el parche. Este mensaje
deberÃ­a ser suficiente para que un lector que lo vea sin otro contexto
pueda entender el alcance del parche; la lÃ­nea aparecerÃ¡ en los
registros de cambios de â€œforma cortaâ€. Este mensaje generalmente se
formatea con el nombre del subsistema relevante primero, seguido del
propÃ³sito del parche. Por ejemplo:

::

     gpio: fix build on CONFIG_GPIO_SYSFS=n
”h]”(h¨)”}”(hX€  Una descripciÃ³n de una lÃ­nea de lo que hace el parche. Este mensaje
deberÃ­a ser suficiente para que un lector que lo vea sin otro contexto
pueda entender el alcance del parche; la lÃ­nea aparecerÃ¡ en los
registros de cambios de â€œforma cortaâ€. Este mensaje generalmente se
formatea con el nombre del subsistema relevante primero, seguido del
propÃ³sito del parche. Por ejemplo:”h]”hX€  Una descripciÃ³n de una lÃ­nea de lo que hace el parche. Este mensaje
deberÃ­a ser suficiente para que un lector que lo vea sin otro contexto
pueda entender el alcance del parche; la lÃ­nea aparecerÃ¡ en los
registros de cambios de â€œforma cortaâ€. Este mensaje generalmente se
formatea con el nombre del subsistema relevante primero, seguido del
propÃ³sito del parche. Por ejemplo:”…””}”(hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh K˜hj
  ubhŒliteral_block”“”)”}”(hŒ&gpio: fix build on CONFIG_GPIO_SYSFS=n”h]”hŒ&gpio: fix build on CONFIG_GPIO_SYSFS=n”…””}”hj  sbah}”(h]”h ]”h"]”h$]”h&]”Œ	xml:space”Œpreserve”uh1j  hŸhØh K¡hj
  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j0  hjï  ubj1  )”}”(hŒ×Una lÃ­nea en blanco seguida de una descripciÃ³n detallada del contenido
del parche. Esta descripciÃ³n puede ser tan larga como sea necesario;
deberÃ­a decir quÃ© hace el parche y por quÃ© debe aplicarse al kernel.
”h]”h¨)”}”(hŒÖUna lÃ­nea en blanco seguida de una descripciÃ³n detallada del contenido
del parche. Esta descripciÃ³n puede ser tan larga como sea necesario;
deberÃ­a decir quÃ© hace el parche y por quÃ© debe aplicarse al kernel.”h]”hŒÖUna lÃ­nea en blanco seguida de una descripciÃ³n detallada del contenido
del parche. Esta descripciÃ³n puede ser tan larga como sea necesario;
deberÃ­a decir quÃ© hace el parche y por quÃ© debe aplicarse al kernel.”…””}”(hj8  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh K£hj4  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j0  hjï  ubj1  )”}”(hŒ¤Una o mÃ¡s lÃ­neas de etiquetas, con, como mÃ­nimo, una lÃ­nea
Signed-off-by: del autor del parche. Las etiquetas se describirÃ¡n con
mÃ¡s detalle a continuaciÃ³n.
”h]”h¨)”}”(hŒ£Una o mÃ¡s lÃ­neas de etiquetas, con, como mÃ­nimo, una lÃ­nea
Signed-off-by: del autor del parche. Las etiquetas se describirÃ¡n con
mÃ¡s detalle a continuaciÃ³n.”h]”hŒ£Una o mÃ¡s lÃ­neas de etiquetas, con, como mÃ­nimo, una lÃ­nea
Signed-off-by: del autor del parche. Las etiquetas se describirÃ¡n con
mÃ¡s detalle a continuaciÃ³n.”…””}”(hjP  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh K§hjL  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j0  hjï  ubeh}”(h]”h ]”h"]”h$]”h&]”j˜  j™  uh1j+  hŸhØh K”hjë  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j%  hŸhØh K”hjÌ  hžhubh¨)”}”(hX`  Los elementos de arriba, juntos, forman el registro de cambios para el
parche. Escribir buenos registros de cambios es un arte crucial, pero a
menudo descuidado; vale la pena pasar otro momento discutiendo este tema.
Al escribir un registro de cambios, debe recordar que muchas personas
diferentes leerÃ¡n sus palabras. Estos incluyen a los maintainers y
revisores de subsistemas que necesitan decidir si el parche debe
incluirse, a los distribuidores y otros maintainers que intentan
determinar si un parche debe ser â€œbackportedâ€ a otros kernels, a los
cazadores de errores que se preguntan si el parche es responsable de un
problema que estÃ¡n persiguiendo, a los usuarios que quieren saber cÃ³mo
ha cambiado el kernel, y mÃ¡s. Un buen registro de cambios transmite la
informaciÃ³n necesaria a todas estas personas de la forma mÃ¡s directa y
concisa posible.”h]”hX`  Los elementos de arriba, juntos, forman el registro de cambios para el
parche. Escribir buenos registros de cambios es un arte crucial, pero a
menudo descuidado; vale la pena pasar otro momento discutiendo este tema.
Al escribir un registro de cambios, debe recordar que muchas personas
diferentes leerÃ¡n sus palabras. Estos incluyen a los maintainers y
revisores de subsistemas que necesitan decidir si el parche debe
incluirse, a los distribuidores y otros maintainers que intentan
determinar si un parche debe ser â€œbackportedâ€ a otros kernels, a los
cazadores de errores que se preguntan si el parche es responsable de un
problema que estÃ¡n persiguiendo, a los usuarios que quieren saber cÃ³mo
ha cambiado el kernel, y mÃ¡s. Un buen registro de cambios transmite la
informaciÃ³n necesaria a todas estas personas de la forma mÃ¡s directa y
concisa posible.”…””}”(hjp  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh K«hjÌ  hžhubh¨)”}”(hXÌ  Con ese fin, la lÃ­nea de resumen debe describir los efectos y la
motivaciÃ³n del cambio, asÃ­ como lo mejor posible dada la restricciÃ³n de
una lÃ­nea. La descripciÃ³n detallada puede ampliar esos temas y
proporcionar cualquier informaciÃ³n adicional necesaria. Si el parche
corrige un error, cita el commit que introdujo el error si es posible (y
por favor, proporcione tanto el ID del commit como el tÃ­tulo al citar
commits). Si un problema estÃ¡ asociado con un registro especÃ­fico o la
salida del compilador, incluya esa salida para ayudar a otros usuarios a
buscar una soluciÃ³n al mismo problema. Si el cambio estÃ¡ destinado a
apoyar otros cambios que llegarÃ¡n en un parche posterior, dÃ­galo. Si se
cambian las API internas, detalle esos cambios y cÃ³mo deben responder
otros desarrolladores. En general, cuanto mÃ¡s pueda ponerse en los zapatos
de todos los que leerÃ¡n su registro de cambios, mejor serÃ¡ ese registro de
cambios (y el kernel en su conjunto).”h]”hXÌ  Con ese fin, la lÃ­nea de resumen debe describir los efectos y la
motivaciÃ³n del cambio, asÃ­ como lo mejor posible dada la restricciÃ³n de
una lÃ­nea. La descripciÃ³n detallada puede ampliar esos temas y
proporcionar cualquier informaciÃ³n adicional necesaria. Si el parche
corrige un error, cita el commit que introdujo el error si es posible (y
por favor, proporcione tanto el ID del commit como el tÃ­tulo al citar
commits). Si un problema estÃ¡ asociado con un registro especÃ­fico o la
salida del compilador, incluya esa salida para ayudar a otros usuarios a
buscar una soluciÃ³n al mismo problema. Si el cambio estÃ¡ destinado a
apoyar otros cambios que llegarÃ¡n en un parche posterior, dÃ­galo. Si se
cambian las API internas, detalle esos cambios y cÃ³mo deben responder
otros desarrolladores. En general, cuanto mÃ¡s pueda ponerse en los zapatos
de todos los que leerÃ¡n su registro de cambios, mejor serÃ¡ ese registro de
cambios (y el kernel en su conjunto).”…””}”(hj~  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh K¹hjÌ  hžhubh¨)”}”(hŒ›No hace falta decir que el registro de cambios debe ser el texto utilizado
al realizar el commit en un sistema de control de revisiones. SerÃ¡ seguido
por:”h]”hŒ›No hace falta decir que el registro de cambios debe ser el texto utilizado
al realizar el commit en un sistema de control de revisiones. SerÃ¡ seguido
por:”…””}”(hjŒ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh KÈhjÌ  hžhubj&  )”}”(hŒâ- El parche, en el formato unificado de parche (â€œ-uâ€). Usar la opciÃ³n
  â€œ-pâ€ en diff asociarÃ¡ los nombres de las funciones con los cambios, lo
  que harÃ¡ que el parche resultante sea mÃ¡s fÃ¡cil de leer para otros.
”h]”j,  )”}”(hhh]”j1  )”}”(hŒÜEl parche, en el formato unificado de parche (â€œ-uâ€). Usar la opciÃ³n
â€œ-pâ€ en diff asociarÃ¡ los nombres de las funciones con los cambios, lo
que harÃ¡ que el parche resultante sea mÃ¡s fÃ¡cil de leer para otros.
”h]”h¨)”}”(hŒÛEl parche, en el formato unificado de parche (â€œ-uâ€). Usar la opciÃ³n
â€œ-pâ€ en diff asociarÃ¡ los nombres de las funciones con los cambios, lo
que harÃ¡ que el parche resultante sea mÃ¡s fÃ¡cil de leer para otros.”h]”hŒÛEl parche, en el formato unificado de parche (â€œ-uâ€). Usar la opciÃ³n
â€œ-pâ€ en diff asociarÃ¡ los nombres de las funciones con los cambios, lo
que harÃ¡ que el parche resultante sea mÃ¡s fÃ¡cil de leer para otros.”…””}”(hj¥  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh KÌhj¡  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j0  hjž  ubah}”(h]”h ]”h"]”h$]”h&]”j˜  j™  uh1j+  hŸhØh KÌhjš  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j%  hŸhØh KÌhjÌ  hžhubh¨)”}”(hX'  Debe evitar incluir cambios en archivos irrelevantes (los generados por
el proceso de compilaciÃ³n, por ejemplo, o los archivos de respaldo del
editor) en el parche. El archivo â€œdontdiffâ€ en el directorio de
Documentation puede ayudar en este sentido; pÃ¡selo a diff con la
opciÃ³n â€œ-Xâ€.”h]”hX'  Debe evitar incluir cambios en archivos irrelevantes (los generados por
el proceso de compilaciÃ³n, por ejemplo, o los archivos de respaldo del
editor) en el parche. El archivo â€œdontdiffâ€ en el directorio de
Documentation puede ayudar en este sentido; pÃ¡selo a diff con la
opciÃ³n â€œ-Xâ€.”…””}”(hjÅ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh KÐhjÌ  hžhubh¨)”}”(hX  Las etiquetas ya mencionadas brevemente anteriormente proporcionan
informaciÃ³n sobre cÃ³mo surgiÃ³ el parche. Se describen en detalle en el
documento
:ref:`Documentation/translations/sp_SP/process/submitting-patches.rst <sp_submittingpatches>`;
lo que sigue aquÃ­ es un breve resumen.”h]”(hŒ—Las etiquetas ya mencionadas brevemente anteriormente proporcionan
informaciÃ³n sobre cÃ³mo surgiÃ³ el parche. Se describen en detalle en el
documento
”…””}”(hjÓ  hžhhŸNh Nubh)”}”(hŒ]:ref:`Documentation/translations/sp_SP/process/submitting-patches.rst <sp_submittingpatches>`”h]”j‡  )”}”(hjÝ  h]”hŒ?Documentation/translations/sp_SP/process/submitting-patches.rst”…””}”(hjß  hžhhŸNh Nubah}”(h]”h ]”(j’  Œstd”Œstd-ref”eh"]”h$]”h&]”uh1j†  hjÛ  ubah}”(h]”h ]”h"]”h$]”h&]”Œrefdoc”jŸ  Œ	refdomain”jé  Œreftype”Œref”Œrefexplicit”ˆŒrefwarn”ˆj¥  Œsp_submittingpatches”uh1hhŸhØh KÖhjÓ  ubhŒ);
lo que sigue aquÃ­ es un breve resumen.”…””}”(hjÓ  hžhhŸNh Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh KÖhjÌ  hžhubh¨)”}”(hŒmUna etiqueta se usa para referirse a commits anteriores que introdujeron
problemas corregidos por el parche::”h]”hŒlUna etiqueta se usa para referirse a commits anteriores que introdujeron
problemas corregidos por el parche:”…””}”(hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh KÜhjÌ  hžhubj  )”}”(hŒpFixes: 1f2e3d4c5b6a ("La primera lÃ­nea del commit especificada por los primeros 12 caracteres de su ID SHA-1.")”h]”hŒpFixes: 1f2e3d4c5b6a ("La primera lÃ­nea del commit especificada por los primeros 12 caracteres de su ID SHA-1.")”…””}”hj  sbah}”(h]”h ]”h"]”h$]”h&]”j,  j-  uh1j  hŸhØh KßhjÌ  hžhubh¨)”}”(hŒ×Otra etiqueta se utiliza para vincular pÃ¡ginas web con informaciÃ³n
adicional o detalles, por ejemplo, una discusiÃ³n previa que condujo al
parche o un documento con una especificaciÃ³n implementada por el parche::”h]”hŒÖOtra etiqueta se utiliza para vincular pÃ¡ginas web con informaciÃ³n
adicional o detalles, por ejemplo, una discusiÃ³n previa que condujo al
parche o un documento con una especificaciÃ³n implementada por el parche:”…””}”(hj!  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh KáhjÌ  hžhubj  )”}”(hŒ@Link: https://example.com/somewhere.html  otras cosas opcionales”h]”hŒ@Link: https://example.com/somewhere.html  otras cosas opcionales”…””}”hj/  sbah}”(h]”h ]”h"]”h$]”h&]”j,  j-  uh1j  hŸhØh KåhjÌ  hžhubh¨)”}”(hX+  Muchos maintainers, al aplicar un parche, tambiÃ©n agregan esta etiqueta
para vincular a la Ãºltima publicaciÃ³n de revisiÃ³n pÃºblica del parche; a
menudo, eso se hace automÃ¡ticamente mediante herramientas como b4 o git
hook como el que se describe en
'Documentation/maintainer/configure-git.rst'.”h]”hX/  Muchos maintainers, al aplicar un parche, tambiÃ©n agregan esta etiqueta
para vincular a la Ãºltima publicaciÃ³n de revisiÃ³n pÃºblica del parche; a
menudo, eso se hace automÃ¡ticamente mediante herramientas como b4 o git
hook como el que se describe en
â€˜Documentation/maintainer/configure-git.rstâ€™.”…””}”(hj=  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh KçhjÌ  hžhubh¨)”}”(hŒŽSi la URL apunta a un informe de error pÃºblico que estÃ¡ siendo corregido
por el parche, use la etiqueta â€œCloses:â€ (Cierra) en su lugar::”h]”hŒSi la URL apunta a un informe de error pÃºblico que estÃ¡ siendo corregido
por el parche, use la etiqueta â€œCloses:â€ (Cierra) en su lugar:”…””}”(hjK  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh KíhjÌ  hžhubj  )”}”(hŒ?Closes: https://example.com/issues/1234  otras cosas opcionales”h]”hŒ?Closes: https://example.com/issues/1234  otras cosas opcionales”…””}”hjY  sbah}”(h]”h ]”h"]”h$]”h&]”j,  j-  uh1j  hŸhØh KðhjÌ  hžhubh¨)”}”(hXG  Algunos rastreadores de errores tienen la capacidad de cerrar problemas
automÃ¡ticamente cuando se aplica un commit con tal etiqueta. Algunos bots
que monitorean listas de correo tambiÃ©n pueden rastrear dichas etiquetas
y realizar ciertas acciones. Los rastreadores de errores privados y las
URL no vÃ¡lidas estÃ¡n prohibidos.”h]”hXG  Algunos rastreadores de errores tienen la capacidad de cerrar problemas
automÃ¡ticamente cuando se aplica un commit con tal etiqueta. Algunos bots
que monitorean listas de correo tambiÃ©n pueden rastrear dichas etiquetas
y realizar ciertas acciones. Los rastreadores de errores privados y las
URL no vÃ¡lidas estÃ¡n prohibidos.”…””}”(hjg  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh KòhjÌ  hžhubh¨)”}”(hŒOtro tipo de etiqueta se utiliza para documentar quiÃ©n estuvo involucrado
en el desarrollo del parche. Cada uno de estos utiliza este formato::”h]”hŒOtro tipo de etiqueta se utiliza para documentar quiÃ©n estuvo involucrado
en el desarrollo del parche. Cada uno de estos utiliza este formato:”…””}”(hju  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh KøhjÌ  hžhubj  )”}”(hŒ6tag: Full Name <email address>  otras cosas opcionales”h]”hŒ6tag: Full Name <email address>  otras cosas opcionales”…””}”hjƒ  sbah}”(h]”h ]”h"]”h$]”h&]”j,  j-  uh1j  hŸhØh KûhjÌ  hžhubh¨)”}”(hŒ Las etiquetas de uso comÃºn son:”h]”hŒ Las etiquetas de uso comÃºn son:”…””}”(hj‘  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh KýhjÌ  hžhubj&  )”}”(hX  - Signed-off-by: esta es una certificaciÃ³n del desarrollador de que Ã©l
  o ella tiene el derecho de enviar el parche para su inclusiÃ³n en el
  kernel. Es un acuerdo con el Certificado de Origen del Desarrollador,
  que se encuentra en
  :ref:`Documentation/translations/sp_SP/process/submitting-patches.rst <sp_submittingpatches>`.
  El cÃ³digo sin la firma adecuada no se puede fusionar en el mainline.

- Co-developed-by: indica que el parche fue co-creado por varios
  desarrolladores; se utiliza para atribuir a los coautores (ademÃ¡s del
  autor atribuido por la etiqueta From:) cuando varias personas trabajan
  en un solo parche. Cada Co-developed-by: debe ir seguido inmediatamente
  por un Signedoff-by: del coautor asociado. Los detalles y ejemplos se
  pueden encontrar en
  :ref:`Documentation/translations/sp_SP/process/submitting-patches.rst <sp_submittingpatches>`.

- Acked-by: indica un acuerdo por parte de otro desarrollador (a menudo
  un maintainer del cÃ³digo relevante) de que el parche es apropiado para
  su inclusiÃ³n en el kernel.

- Tested-by: indica que la persona nombrada ha probado el parche y ha
  encontrado que funciona.

- Reviewed-by: el desarrollador nombrado ha revisado el parche para
  verificar que sea correcto; consulte la declaraciÃ³n del revisor en
  :ref:`Documentation/translations/sp_SP/process/submitting-patches.rst <sp_submittingpatches>`
  para obtener mÃ¡s detalles.

- Reported-by: nombra a un usuario que informÃ³ un problema que se
  soluciona con este parche; esta etiqueta se utiliza para dar crÃ©dito
  a las personas (a menudo infravalorada) que prueban nuestro cÃ³digo y
  nos hacen saber cuÃ¡ndo las cosas no funcionan correctamente. Tenga en
  cuenta que esta etiqueta debe ir seguida de una etiqueta Closes: que
  apunte al informe, a menos que el informe no estÃ© disponible en la
  web. La etiqueta Link: se puede usar en lugar de Closes: si el parche
  corrige una parte de los problemas reportados.

- Cc: la persona nombrada recibiÃ³ una copia del parche y tuvo la
  oportunidad de comentar sobre Ã©l.
”h]”j,  )”}”(hhh]”(j1  )”}”(hX‹  Signed-off-by: esta es una certificaciÃ³n del desarrollador de que Ã©l
o ella tiene el derecho de enviar el parche para su inclusiÃ³n en el
kernel. Es un acuerdo con el Certificado de Origen del Desarrollador,
que se encuentra en
:ref:`Documentation/translations/sp_SP/process/submitting-patches.rst <sp_submittingpatches>`.
El cÃ³digo sin la firma adecuada no se puede fusionar en el mainline.
”h]”h¨)”}”(hXŠ  Signed-off-by: esta es una certificaciÃ³n del desarrollador de que Ã©l
o ella tiene el derecho de enviar el parche para su inclusiÃ³n en el
kernel. Es un acuerdo con el Certificado de Origen del Desarrollador,
que se encuentra en
:ref:`Documentation/translations/sp_SP/process/submitting-patches.rst <sp_submittingpatches>`.
El cÃ³digo sin la firma adecuada no se puede fusionar en el mainline.”h]”(hŒæSigned-off-by: esta es una certificaciÃ³n del desarrollador de que Ã©l
o ella tiene el derecho de enviar el parche para su inclusiÃ³n en el
kernel. Es un acuerdo con el Certificado de Origen del Desarrollador,
que se encuentra en
”…””}”(hjª  hžhhŸNh Nubh)”}”(hŒ]:ref:`Documentation/translations/sp_SP/process/submitting-patches.rst <sp_submittingpatches>`”h]”j‡  )”}”(hj´  h]”hŒ?Documentation/translations/sp_SP/process/submitting-patches.rst”…””}”(hj¶  hžhhŸNh Nubah}”(h]”h ]”(j’  Œstd”Œstd-ref”eh"]”h$]”h&]”uh1j†  hj²  ubah}”(h]”h ]”h"]”h$]”h&]”Œrefdoc”jŸ  Œ	refdomain”jÀ  Œreftype”Œref”Œrefexplicit”ˆŒrefwarn”ˆj¥  Œsp_submittingpatches”uh1hhŸhØh Kÿhjª  ubhŒG.
El cÃ³digo sin la firma adecuada no se puede fusionar en el mainline.”…””}”(hjª  hžhhŸNh Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh Kÿhj¦  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j0  hj£  ubj1  )”}”(hXÎ  Co-developed-by: indica que el parche fue co-creado por varios
desarrolladores; se utiliza para atribuir a los coautores (ademÃ¡s del
autor atribuido por la etiqueta From:) cuando varias personas trabajan
en un solo parche. Cada Co-developed-by: debe ir seguido inmediatamente
por un Signedoff-by: del coautor asociado. Los detalles y ejemplos se
pueden encontrar en
:ref:`Documentation/translations/sp_SP/process/submitting-patches.rst <sp_submittingpatches>`.
”h]”h¨)”}”(hXÍ  Co-developed-by: indica que el parche fue co-creado por varios
desarrolladores; se utiliza para atribuir a los coautores (ademÃ¡s del
autor atribuido por la etiqueta From:) cuando varias personas trabajan
en un solo parche. Cada Co-developed-by: debe ir seguido inmediatamente
por un Signedoff-by: del coautor asociado. Los detalles y ejemplos se
pueden encontrar en
:ref:`Documentation/translations/sp_SP/process/submitting-patches.rst <sp_submittingpatches>`.”h]”(hXo  Co-developed-by: indica que el parche fue co-creado por varios
desarrolladores; se utiliza para atribuir a los coautores (ademÃ¡s del
autor atribuido por la etiqueta From:) cuando varias personas trabajan
en un solo parche. Cada Co-developed-by: debe ir seguido inmediatamente
por un Signedoff-by: del coautor asociado. Los detalles y ejemplos se
pueden encontrar en
”…””}”(hjæ  hžhhŸNh Nubh)”}”(hŒ]:ref:`Documentation/translations/sp_SP/process/submitting-patches.rst <sp_submittingpatches>`”h]”j‡  )”}”(hjð  h]”hŒ?Documentation/translations/sp_SP/process/submitting-patches.rst”…””}”(hjò  hžhhŸNh Nubah}”(h]”h ]”(j’  Œstd”Œstd-ref”eh"]”h$]”h&]”uh1j†  hjî  ubah}”(h]”h ]”h"]”h$]”h&]”Œrefdoc”jŸ  Œ	refdomain”jü  Œreftype”Œref”Œrefexplicit”ˆŒrefwarn”ˆj¥  Œsp_submittingpatches”uh1hhŸhØh Mhjæ  ubhŒ.”…””}”(hjæ  hžhhŸNh Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh Mhjâ  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j0  hj£  ubj1  )”}”(hŒªAcked-by: indica un acuerdo por parte de otro desarrollador (a menudo
un maintainer del cÃ³digo relevante) de que el parche es apropiado para
su inclusiÃ³n en el kernel.
”h]”h¨)”}”(hŒ©Acked-by: indica un acuerdo por parte de otro desarrollador (a menudo
un maintainer del cÃ³digo relevante) de que el parche es apropiado para
su inclusiÃ³n en el kernel.”h]”hŒ©Acked-by: indica un acuerdo por parte de otro desarrollador (a menudo
un maintainer del cÃ³digo relevante) de que el parche es apropiado para
su inclusiÃ³n en el kernel.”…””}”(hj"  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh Mhj  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j0  hj£  ubj1  )”}”(hŒ]Tested-by: indica que la persona nombrada ha probado el parche y ha
encontrado que funciona.
”h]”h¨)”}”(hŒ\Tested-by: indica que la persona nombrada ha probado el parche y ha
encontrado que funciona.”h]”hŒ\Tested-by: indica que la persona nombrada ha probado el parche y ha
encontrado que funciona.”…””}”(hj:  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh Mhj6  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j0  hj£  ubj1  )”}”(hX   Reviewed-by: el desarrollador nombrado ha revisado el parche para
verificar que sea correcto; consulte la declaraciÃ³n del revisor en
:ref:`Documentation/translations/sp_SP/process/submitting-patches.rst <sp_submittingpatches>`
para obtener mÃ¡s detalles.
”h]”h¨)”}”(hŒÿReviewed-by: el desarrollador nombrado ha revisado el parche para
verificar que sea correcto; consulte la declaraciÃ³n del revisor en
:ref:`Documentation/translations/sp_SP/process/submitting-patches.rst <sp_submittingpatches>`
para obtener mÃ¡s detalles.”h]”(hŒ†Reviewed-by: el desarrollador nombrado ha revisado el parche para
verificar que sea correcto; consulte la declaraciÃ³n del revisor en
”…””}”(hjR  hžhhŸNh Nubh)”}”(hŒ]:ref:`Documentation/translations/sp_SP/process/submitting-patches.rst <sp_submittingpatches>`”h]”j‡  )”}”(hj\  h]”hŒ?Documentation/translations/sp_SP/process/submitting-patches.rst”…””}”(hj^  hžhhŸNh Nubah}”(h]”h ]”(j’  Œstd”Œstd-ref”eh"]”h$]”h&]”uh1j†  hjZ  ubah}”(h]”h ]”h"]”h$]”h&]”Œrefdoc”jŸ  Œ	refdomain”jh  Œreftype”Œref”Œrefexplicit”ˆŒrefwarn”ˆj¥  Œsp_submittingpatches”uh1hhŸhØh MhjR  ubhŒ
para obtener mÃ¡s detalles.”…””}”(hjR  hžhhŸNh Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh MhjN  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j0  hj£  ubj1  )”}”(hX  Reported-by: nombra a un usuario que informÃ³ un problema que se
soluciona con este parche; esta etiqueta se utiliza para dar crÃ©dito
a las personas (a menudo infravalorada) que prueban nuestro cÃ³digo y
nos hacen saber cuÃ¡ndo las cosas no funcionan correctamente. Tenga en
cuenta que esta etiqueta debe ir seguida de una etiqueta Closes: que
apunte al informe, a menos que el informe no estÃ© disponible en la
web. La etiqueta Link: se puede usar en lugar de Closes: si el parche
corrige una parte de los problemas reportados.
”h]”h¨)”}”(hX  Reported-by: nombra a un usuario que informÃ³ un problema que se
soluciona con este parche; esta etiqueta se utiliza para dar crÃ©dito
a las personas (a menudo infravalorada) que prueban nuestro cÃ³digo y
nos hacen saber cuÃ¡ndo las cosas no funcionan correctamente. Tenga en
cuenta que esta etiqueta debe ir seguida de una etiqueta Closes: que
apunte al informe, a menos que el informe no estÃ© disponible en la
web. La etiqueta Link: se puede usar en lugar de Closes: si el parche
corrige una parte de los problemas reportados.”h]”hX  Reported-by: nombra a un usuario que informÃ³ un problema que se
soluciona con este parche; esta etiqueta se utiliza para dar crÃ©dito
a las personas (a menudo infravalorada) que prueban nuestro cÃ³digo y
nos hacen saber cuÃ¡ndo las cosas no funcionan correctamente. Tenga en
cuenta que esta etiqueta debe ir seguida de una etiqueta Closes: que
apunte al informe, a menos que el informe no estÃ© disponible en la
web. La etiqueta Link: se puede usar en lugar de Closes: si el parche
corrige una parte de los problemas reportados.”…””}”(hjŽ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh MhjŠ  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j0  hj£  ubj1  )”}”(hŒcCc: la persona nombrada recibiÃ³ una copia del parche y tuvo la
oportunidad de comentar sobre Ã©l.
”h]”h¨)”}”(hŒbCc: la persona nombrada recibiÃ³ una copia del parche y tuvo la
oportunidad de comentar sobre Ã©l.”h]”hŒbCc: la persona nombrada recibiÃ³ una copia del parche y tuvo la
oportunidad de comentar sobre Ã©l.”…””}”(hj¦  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh M#hj¢  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j0  hj£  ubeh}”(h]”h ]”h"]”h$]”h&]”j˜  j™  uh1j+  hŸhØh KÿhjŸ  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j%  hŸhØh KÿhjÌ  hžhubh¨)”}”(hŒûTenga cuidado al agregar etiquetas a sus parches, ya que solo Cc: es
apropiado para la adiciÃ³n sin el permiso explÃ­cito de la persona nombrada;
usar Reported-by: estÃ¡ casi bien en su mayorÃ­a, pero pida permiso si el
error fue reportado en privado.”h]”hŒûTenga cuidado al agregar etiquetas a sus parches, ya que solo Cc: es
apropiado para la adiciÃ³n sin el permiso explÃ­cito de la persona nombrada;
usar Reported-by: estÃ¡ casi bien en su mayorÃ­a, pero pida permiso si el
error fue reportado en privado.”…””}”(hjÆ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh M&hjÌ  hžhubeh}”(h]”Œ)formato-de-parches-y-registros-de-cambios”ah ]”h"]”Œ)formato de parches y registros de cambios”ah$]”h&]”uh1je  hjg  hžhhŸhØh Kubjf  )”}”(hhh]”(jk  )”}”(hŒEnviÃ³ del parche”h]”hŒEnviÃ³ del parche”…””}”(hjß  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jj  hjÜ  hžhhŸhØh M,ubh¨)”}”(hŒZAntes de enviar sus parches por correo, hay un par de cosas mÃ¡s de las
que debe ocuparse:”h]”hŒZAntes de enviar sus parches por correo, hay un par de cosas mÃ¡s de las
que debe ocuparse:”…””}”(hjí  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh M.hjÜ  hžhubj&  )”}”(hXê  - Â¿EstÃ¡ seguro de que su correo no corromperÃ¡ los parches? Los parches
  con cambios gratuitos de espacio en blanco o ajuste de lÃ­nea
  realizados por el cliente de correo no se aplicarÃ¡n en el otro
  extremo, y a menudo, no se examinarÃ¡n en detalle. Si tiene alguna
  duda, envÃ­ese el parche por correo y convÃ©nzase de que parece
  intacto.

  :ref:`Documentation/translations/sp_SP/process/email-clients.rst <sp_email_clients>`
  tiene algunos consejos Ãºtiles sobre cÃ³mo hacer que clientes de correo
  especÃ­ficos funcionen para enviar parches.

- Â¿EstÃ¡ seguro de que su parche estÃ¡ libre de errores tontos? Siempre
  debe ejecutar parches a travÃ©s de scripts/checkpatch.pl y abordar las
  quejas que surjan. Por favor, tenga en cuenta que checkpatch.pl, aunque
  es la encarnaciÃ³n de una buena cantidad de pensamiento sobre cÃ³mo
  deberÃ­an ser los parches del kernel, no es mÃ¡s inteligente que usted.
  Si corregir una queja de checkpatch.pl empeorarÃ­a el cÃ³digo, no lo
  haga.
”h]”j,  )”}”(hhh]”(j1  )”}”(hX  Â¿EstÃ¡ seguro de que su correo no corromperÃ¡ los parches? Los parches
con cambios gratuitos de espacio en blanco o ajuste de lÃ­nea
realizados por el cliente de correo no se aplicarÃ¡n en el otro
extremo, y a menudo, no se examinarÃ¡n en detalle. Si tiene alguna
duda, envÃ­ese el parche por correo y convÃ©nzase de que parece
intacto.

:ref:`Documentation/translations/sp_SP/process/email-clients.rst <sp_email_clients>`
tiene algunos consejos Ãºtiles sobre cÃ³mo hacer que clientes de correo
especÃ­ficos funcionen para enviar parches.
”h]”(h¨)”}”(hXQ  Â¿EstÃ¡ seguro de que su correo no corromperÃ¡ los parches? Los parches
con cambios gratuitos de espacio en blanco o ajuste de lÃ­nea
realizados por el cliente de correo no se aplicarÃ¡n en el otro
extremo, y a menudo, no se examinarÃ¡n en detalle. Si tiene alguna
duda, envÃ­ese el parche por correo y convÃ©nzase de que parece
intacto.”h]”hXQ  Â¿EstÃ¡ seguro de que su correo no corromperÃ¡ los parches? Los parches
con cambios gratuitos de espacio en blanco o ajuste de lÃ­nea
realizados por el cliente de correo no se aplicarÃ¡n en el otro
extremo, y a menudo, no se examinarÃ¡n en detalle. Si tiene alguna
duda, envÃ­ese el parche por correo y convÃ©nzase de que parece
intacto.”…””}”(hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh M1hj  ubh¨)”}”(hŒÈ:ref:`Documentation/translations/sp_SP/process/email-clients.rst <sp_email_clients>`
tiene algunos consejos Ãºtiles sobre cÃ³mo hacer que clientes de correo
especÃ­ficos funcionen para enviar parches.”h]”(h)”}”(hŒT:ref:`Documentation/translations/sp_SP/process/email-clients.rst <sp_email_clients>`”h]”j‡  )”}”(hj  h]”hŒ:Documentation/translations/sp_SP/process/email-clients.rst”…””}”(hj  hžhhŸNh Nubah}”(h]”h ]”(j’  Œstd”Œstd-ref”eh"]”h$]”h&]”uh1j†  hj  ubah}”(h]”h ]”h"]”h$]”h&]”Œrefdoc”jŸ  Œ	refdomain”j&  Œreftype”Œref”Œrefexplicit”ˆŒrefwarn”ˆj¥  Œsp_email_clients”uh1hhŸhØh M8hj  ubhŒt
tiene algunos consejos Ãºtiles sobre cÃ³mo hacer que clientes de correo
especÃ­ficos funcionen para enviar parches.”…””}”(hj  hžhhŸNh Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh M8hj  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j0  hjÿ  ubj1  )”}”(hX­  Â¿EstÃ¡ seguro de que su parche estÃ¡ libre de errores tontos? Siempre
debe ejecutar parches a travÃ©s de scripts/checkpatch.pl y abordar las
quejas que surjan. Por favor, tenga en cuenta que checkpatch.pl, aunque
es la encarnaciÃ³n de una buena cantidad de pensamiento sobre cÃ³mo
deberÃ­an ser los parches del kernel, no es mÃ¡s inteligente que usted.
Si corregir una queja de checkpatch.pl empeorarÃ­a el cÃ³digo, no lo
haga.
”h]”h¨)”}”(hX¬  Â¿EstÃ¡ seguro de que su parche estÃ¡ libre de errores tontos? Siempre
debe ejecutar parches a travÃ©s de scripts/checkpatch.pl y abordar las
quejas que surjan. Por favor, tenga en cuenta que checkpatch.pl, aunque
es la encarnaciÃ³n de una buena cantidad de pensamiento sobre cÃ³mo
deberÃ­an ser los parches del kernel, no es mÃ¡s inteligente que usted.
Si corregir una queja de checkpatch.pl empeorarÃ­a el cÃ³digo, no lo
haga.”h]”hX¬  Â¿EstÃ¡ seguro de que su parche estÃ¡ libre de errores tontos? Siempre
debe ejecutar parches a travÃ©s de scripts/checkpatch.pl y abordar las
quejas que surjan. Por favor, tenga en cuenta que checkpatch.pl, aunque
es la encarnaciÃ³n de una buena cantidad de pensamiento sobre cÃ³mo
deberÃ­an ser los parches del kernel, no es mÃ¡s inteligente que usted.
Si corregir una queja de checkpatch.pl empeorarÃ­a el cÃ³digo, no lo
haga.”…””}”(hjL  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh M<hjH  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j0  hjÿ  ubeh}”(h]”h ]”h"]”h$]”h&]”j˜  j™  uh1j+  hŸhØh M1hjû  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j%  hŸhØh M1hjÜ  hžhubh¨)”}”(hX  Los parches siempre deben enviarse como texto sin formato. Por favor, no
los envÃ­e como archivos adjuntos; eso hace que sea mucho mÃ¡s difÃ­cil para
los revisores citar secciones del parche en sus respuestas. En su lugar,
simplemente coloca el parche directamente en su mensaje.”h]”hX  Los parches siempre deben enviarse como texto sin formato. Por favor, no
los envÃ­e como archivos adjuntos; eso hace que sea mucho mÃ¡s difÃ­cil para
los revisores citar secciones del parche en sus respuestas. En su lugar,
simplemente coloca el parche directamente en su mensaje.”…””}”(hjl  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh MDhjÜ  hžhubh¨)”}”(hX`  Al enviar parches por correo, es importante enviar copias a cualquier
persona que pueda estar interesada en ellos. A diferencia de otros
proyectos, el kernel anima a la gente a equivocarse por el lado de enviar
demasiadas copias; no asuma que las personas relevantes verÃ¡n su
publicaciÃ³n en las listas de correo. En particular, las copias deben
ir a:”h]”hX`  Al enviar parches por correo, es importante enviar copias a cualquier
persona que pueda estar interesada en ellos. A diferencia de otros
proyectos, el kernel anima a la gente a equivocarse por el lado de enviar
demasiadas copias; no asuma que las personas relevantes verÃ¡n su
publicaciÃ³n en las listas de correo. En particular, las copias deben
ir a:”…””}”(hjz  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh MIhjÜ  hžhubj&  )”}”(hXü  - El (los) maintainer(s) del (de los) subsistema(s) afectado(s). Como se
  describiÃ³ anteriormente, el archivo MAINTAINERS es el primer lugar para
  buscar a estas personas.

- Otros desarrolladores que han estado trabajando en la misma
  Ã¡rea â€“ especialmente aquellos que podrÃ­an estar trabajando allÃ­ ahora.
  Usar git para ver quiÃ©n mÃ¡s ha modificado los archivos en los que estÃ¡
  trabajando puede ser Ãºtil.

- Si estÃ¡ respondiendo a un informe de error o a una solicitud de
  funciÃ³n, copie tambiÃ©n al autor.

- EnviÃ© una copia a la lista de correo relevante o, si no se aplica nada
  mÃ¡s, a la lista de linux-kernel.

- Si estÃ¡ corrigiendo un error, piense si la correcciÃ³n debe incluirse en
  la prÃ³xima actualizaciÃ³n estable. Si es asÃ­, stable@vger.kernel.org
  deberÃ­a obtener una copia del parche. TambiÃ©n agregue un
  "Cc: stable@vger.kernel.org" a las etiquetas dentro del parche; eso
  harÃ¡ que el equipo estable reciba una notificaciÃ³n cuando su soluciÃ³n
  incluya en el mainline.
”•ù+      h]”j,  )”}”(hhh]”(j1  )”}”(hŒ©El (los) maintainer(s) del (de los) subsistema(s) afectado(s). Como se
describiÃ³ anteriormente, el archivo MAINTAINERS es el primer lugar para
buscar a estas personas.
”h]”h¨)”}”(hŒ¨El (los) maintainer(s) del (de los) subsistema(s) afectado(s). Como se
describiÃ³ anteriormente, el archivo MAINTAINERS es el primer lugar para
buscar a estas personas.”h]”hŒ¨El (los) maintainer(s) del (de los) subsistema(s) afectado(s). Como se
describiÃ³ anteriormente, el archivo MAINTAINERS es el primer lugar para
buscar a estas personas.”…””}”(hj“  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh MPhj  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j0  hjŒ  ubj1  )”}”(hŒîOtros desarrolladores que han estado trabajando en la misma
Ã¡rea â€“ especialmente aquellos que podrÃ­an estar trabajando allÃ­ ahora.
Usar git para ver quiÃ©n mÃ¡s ha modificado los archivos en los que estÃ¡
trabajando puede ser Ãºtil.
”h]”h¨)”}”(hŒíOtros desarrolladores que han estado trabajando en la misma
Ã¡rea â€“ especialmente aquellos que podrÃ­an estar trabajando allÃ­ ahora.
Usar git para ver quiÃ©n mÃ¡s ha modificado los archivos en los que estÃ¡
trabajando puede ser Ãºtil.”h]”hŒíOtros desarrolladores que han estado trabajando en la misma
Ã¡rea â€“ especialmente aquellos que podrÃ­an estar trabajando allÃ­ ahora.
Usar git para ver quiÃ©n mÃ¡s ha modificado los archivos en los que estÃ¡
trabajando puede ser Ãºtil.”…””}”(hj«  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh MThj§  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j0  hjŒ  ubj1  )”}”(hŒdSi estÃ¡ respondiendo a un informe de error o a una solicitud de
funciÃ³n, copie tambiÃ©n al autor.
”h]”h¨)”}”(hŒcSi estÃ¡ respondiendo a un informe de error o a una solicitud de
funciÃ³n, copie tambiÃ©n al autor.”h]”hŒcSi estÃ¡ respondiendo a un informe de error o a una solicitud de
funciÃ³n, copie tambiÃ©n al autor.”…””}”(hjÃ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh MYhj¿  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j0  hjŒ  ubj1  )”}”(hŒjEnviÃ© una copia a la lista de correo relevante o, si no se aplica nada
mÃ¡s, a la lista de linux-kernel.
”h]”h¨)”}”(hŒiEnviÃ© una copia a la lista de correo relevante o, si no se aplica nada
mÃ¡s, a la lista de linux-kernel.”h]”hŒiEnviÃ© una copia a la lista de correo relevante o, si no se aplica nada
mÃ¡s, a la lista de linux-kernel.”…””}”(hjÛ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh M\hj×  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j0  hjŒ  ubj1  )”}”(hXq  Si estÃ¡ corrigiendo un error, piense si la correcciÃ³n debe incluirse en
la prÃ³xima actualizaciÃ³n estable. Si es asÃ­, stable@vger.kernel.org
deberÃ­a obtener una copia del parche. TambiÃ©n agregue un
"Cc: stable@vger.kernel.org" a las etiquetas dentro del parche; eso
harÃ¡ que el equipo estable reciba una notificaciÃ³n cuando su soluciÃ³n
incluya en el mainline.
”h]”h¨)”}”(hXp  Si estÃ¡ corrigiendo un error, piense si la correcciÃ³n debe incluirse en
la prÃ³xima actualizaciÃ³n estable. Si es asÃ­, stable@vger.kernel.org
deberÃ­a obtener una copia del parche. TambiÃ©n agregue un
"Cc: stable@vger.kernel.org" a las etiquetas dentro del parche; eso
harÃ¡ que el equipo estable reciba una notificaciÃ³n cuando su soluciÃ³n
incluya en el mainline.”h]”(hŒzSi estÃ¡ corrigiendo un error, piense si la correcciÃ³n debe incluirse en
la prÃ³xima actualizaciÃ³n estable. Si es asÃ­, ”…””}”(hjó  hžhhŸNh Nubj  )”}”(hŒstable@vger.kernel.org”h]”hŒstable@vger.kernel.org”…””}”(hjû  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”Œrefuri”Œmailto:stable@vger.kernel.org”uh1j  hjó  ubhŒC
deberÃ­a obtener una copia del parche. TambiÃ©n agregue un
â€œCc: ”…””}”(hjó  hžhhŸNh Nubj  )”}”(hŒstable@vger.kernel.org”h]”hŒstable@vger.kernel.org”…””}”(hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”Œrefuri”Œmailto:stable@vger.kernel.org”uh1j  hjó  ubhŒ‹â€ a las etiquetas dentro del parche; eso
harÃ¡ que el equipo estable reciba una notificaciÃ³n cuando su soluciÃ³n
incluya en el mainline.”…””}”(hjó  hžhhŸNh Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh M_hjï  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j0  hjŒ  ubeh}”(h]”h ]”h"]”h$]”h&]”j˜  j™  uh1j+  hŸhØh MPhjˆ  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j%  hŸhØh MPhjÜ  hžhubh¨)”}”(hX	  Al seleccionar destinatarios para un parche, es bueno saber quiÃ©n cree que
eventualmente aceptarÃ¡ el parche y lo fusionarÃ¡. Aunque es posible enviar
parches directamente a Linus Torvalds y hacer que los fusione, las cosas
normalmente no se hacen de esa manera. Linus estÃ¡ ocupado y hay
maintainers de subsistemas que vigilan partes especÃ­ficas del kernel.
Generalmente, querrÃ¡ que ese maintainer fusione sus parches. Andrew Morton
es a menudo el objetivo del parche de Ãºltimo recurso si no hay un
maintainer obvio.”h]”hX	  Al seleccionar destinatarios para un parche, es bueno saber quiÃ©n cree que
eventualmente aceptarÃ¡ el parche y lo fusionarÃ¡. Aunque es posible enviar
parches directamente a Linus Torvalds y hacer que los fusione, las cosas
normalmente no se hacen de esa manera. Linus estÃ¡ ocupado y hay
maintainers de subsistemas que vigilan partes especÃ­ficas del kernel.
Generalmente, querrÃ¡ que ese maintainer fusione sus parches. Andrew Morton
es a menudo el objetivo del parche de Ãºltimo recurso si no hay un
maintainer obvio.”…””}”(hj;  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh MfhjÜ  hžhubh¨)”}”(hŒoLos parches necesitan buenas lÃ­neas de asunto. El formato canÃ³nico de una
lÃ­nea de parche es algo asÃ­ como:”h]”hŒoLos parches necesitan buenas lÃ­neas de asunto. El formato canÃ³nico de una
lÃ­nea de parche es algo asÃ­ como:”…””}”(hjI  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh MohjÜ  hžhubj  )”}”(hŒ;[PATCH nn/mm] subsys: descripciÃ³n en una lÃ­nea del parche”h]”hŒ;[PATCH nn/mm] subsys: descripciÃ³n en una lÃ­nea del parche”…””}”hjW  sbah}”(h]”h ]”h"]”h$]”h&]”j,  j-  uh1j  hŸhØh MthjÜ  hžhubh¨)”}”(hŒædonde â€œnnâ€ es el nÃºmero ordinal del parche, â€œâ€mmâ€ es el nÃºmero total de
parches en la serie, y â€œsubsysâ€ es el nombre del subsistema afectado.
Claramente, nn/mm se puede omitir para un parche Ãºnico e independiente.”h]”hŒædonde â€œnnâ€ es el nÃºmero ordinal del parche, â€œâ€mmâ€ es el nÃºmero total de
parches en la serie, y â€œsubsysâ€ es el nombre del subsistema afectado.
Claramente, nn/mm se puede omitir para un parche Ãºnico e independiente.”…””}”(hje  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh MvhjÜ  hžhubh¨)”}”(hX’  Si tiene una serie significativa de parches, es costumbre enviar una
descripciÃ³n introductoria como parte cero. Sin embargo, esta convenciÃ³n no
se sigue universalmente; si la utiliza, recuerde que la informaciÃ³n en la
introducciÃ³n no se incluye en los registros de cambios del kernel. Por lo
tanto, asegÃºrese de que los parches, en sÃ­ mismos, tengan informaciÃ³n
completa del registro de cambios.”h]”hX’  Si tiene una serie significativa de parches, es costumbre enviar una
descripciÃ³n introductoria como parte cero. Sin embargo, esta convenciÃ³n no
se sigue universalmente; si la utiliza, recuerde que la informaciÃ³n en la
introducciÃ³n no se incluye en los registros de cambios del kernel. Por lo
tanto, asegÃºrese de que los parches, en sÃ­ mismos, tengan informaciÃ³n
completa del registro de cambios.”…””}”(hjs  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh MzhjÜ  hžhubh¨)”}”(hXÓ  En general, la segunda y las siguientes partes de un parche de varias
partes deben enviarse como una respuesta a la primera parte para que todas
se hilen juntas en el extremo receptor. Herramientas como git y quilt
tienen comandos para enviar por correo un conjunto de parches con el
subproceso adecuado. Sin embargo, si tiene una serie larga y estÃ¡ usando
git, por favor evite la opciÃ³n â€“chain-reply-to para evitar crear un
anidamiento excepcionalmente profundo.”h]”hXÓ  En general, la segunda y las siguientes partes de un parche de varias
partes deben enviarse como una respuesta a la primera parte para que todas
se hilen juntas en el extremo receptor. Herramientas como git y quilt
tienen comandos para enviar por correo un conjunto de parches con el
subproceso adecuado. Sin embargo, si tiene una serie larga y estÃ¡ usando
git, por favor evite la opciÃ³n â€“chain-reply-to para evitar crear un
anidamiento excepcionalmente profundo.”…””}”(hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h§hŸhØh MhjÜ  hžhubeh}”(h]”Œenvio-del-parche”ah ]”h"]”ŒenviÃ³ del parche”ah$]”h&]”uh1je  hjg  hžhhŸhØh M,ubeh}”(h]”(Œpublicacion-de-parches”jd  eh ]”h"]”(ŒpublicaciÃ³n de parches”Œsp_development_posting”eh$]”h&]”uh1je  hhhžhhŸhØh K	Œexpect_referenced_by_name”}”j  jY  sŒexpect_referenced_by_id”}”jd  jY  subeh}”(h]”h ]”h"]”h$]”h&]”Œsource”hØuh1hŒcurrent_source”NŒcurrent_line”NŒsettings”Œdocutils.frontend”ŒValues”“”)”}”(jj  NŒ	generator”NŒ	datestamp”NŒsource_link”NŒ
source_url”NŒtoc_backlinks”Œentry”Œfootnote_backlinks”KŒsectnum_xform”KŒstrip_comments”NŒstrip_elements_with_classes”NŒstrip_classes”NŒreport_level”KŒ
halt_level”KŒexit_status_level”KŒdebug”NŒwarning_stream”NŒ	traceback”ˆŒinput_encoding”Œ	utf-8-sig”Œinput_encoding_error_handler”Œstrict”Œoutput_encoding”Œutf-8”Œoutput_encoding_error_handler”jÇ  Œerror_encoding”Œutf-8”Œerror_encoding_error_handler”Œbackslashreplace”Œlanguage_code”Œen”Œrecord_dependencies”NŒconfig”NŒ	id_prefix”hŒauto_id_prefix”Œid”Œdump_settings”NŒdump_internals”NŒdump_transforms”NŒdump_pseudo_xml”NŒexpose_internals”NŒstrict_visitor”NŒ_disable_config”NŒ_source”hØŒ_destination”NŒ_config_files”]”Œ7/var/lib/git/docbuild/linux/Documentation/docutils.conf”aŒfile_insertion_enabled”ˆŒraw_enabled”KŒline_length_limit”M'Œpep_references”NŒpep_base_url”Œhttps://peps.python.org/”Œpep_file_url_template”Œpep-%04d”Œrfc_references”NŒrfc_base_url”Œ&https://datatracker.ietf.org/doc/html/”Œ	tab_width”KŒtrim_footnote_reference_space”‰Œsyntax_highlight”Œlong”Œsmart_quotes”ˆŒsmartquotes_locales”]”Œcharacter_level_inline_markup”‰Œdoctitle_xform”‰Œdocinfo_xform”KŒsectsubtitle_xform”‰Œimage_loading”Œlink”Œembed_stylesheet”‰Œcloak_email_addresses”ˆŒsection_self_link”‰Œenv”NubŒreporter”NŒindirect_targets”]”Œsubstitution_defs”}”Œsubstitution_names”}”Œrefnames”}”Œrefids”}”jd  ]”jY  asŒnameids”}”(j  jd  jœ  j™  j  j   j³  j°  jÉ  jÆ  jÙ  jÖ  j”  j‘  uŒ	nametypes”}”(j  ˆjœ  ‰j  ‰j³  ‰jÉ  ‰jÙ  ‰j”  ‰uh}”(jd  jg  j™  jg  j   jÑ  j°  j  jÆ  j¶  jÖ  jÌ  j‘  jÜ  uŒfootnote_refs”}”Œcitation_refs”}”Œautofootnotes”]”Œautofootnote_refs”]”Œsymbol_footnotes”]”Œsymbol_footnote_refs”]”Œ	footnotes”]”Œ	citations”]”Œautofootnote_start”KŒsymbol_footnote_start”K Œ
id_counter”Œcollections”ŒCounter”“”}”…”R”Œparse_messages”]”Œtransform_messages”]”hŒsystem_message”“”)”}”(hhh]”h¨)”}”(hhh]”hŒ<Hyperlink target "sp-development-posting" is not referenced.”…””}”hj1	  sbah}”(h]”h ]”h"]”h$]”h&]”uh1h§hj.	  ubah}”(h]”h ]”h"]”h$]”h&]”Œlevel”KŒtype”ŒINFO”Œsource”hØŒline”Kuh1j,	  ubaŒtransformer”NŒinclude_log”]”Œ6Documentation/translations/sp_SP/process/5.Posting.rst”(NNNNt”†”aŒ
decoration”Nhžhub.