From nobody Sun Dec 14 20:28:52 2025 Received: from mail-ot1-f53.google.com (mail-ot1-f53.google.com [209.85.210.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9F74D1547FF; Fri, 29 Nov 2024 15:59:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.53 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732895942; cv=none; b=ZVxDw1i4Bt0KiaMNYy12FqqwXLu4e9r7+sgFDd4uAgL+JAyEIFK1clnpwOzQxONlbExBxhmKgDP0lZc3zECUiudoQuLfBy8ph3vLOIqWgEUnJ8XFnYiipiSdjgvEAVqQZROsiaOpWNclSjm7p44jDTNGmOA4+0jSLFa9cHubFM0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732895942; c=relaxed/simple; bh=NkRH/nCEAwZBq0GsFxUHM8W07UD0cWEPAw9V8E1cKmE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=GHF76P9a77HgwUv/kCaf/p7LYAwjfkcGnEUqOGWRN/9tG+xHrzQe631dJXiU7usu+xQttyFZvlB8Alc2Fg5yYtrjnFajn5wvV5MuPiT06zsbeAExmMShxsYeEOPGVwQnORVDCjyHquXaWp+eKlJ3HbEYB10Q+QCosiZvmlDO8dE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=ZjFXEHjh; arc=none smtp.client-ip=209.85.210.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="ZjFXEHjh" Received: by mail-ot1-f53.google.com with SMTP id 46e09a7af769-71d579bb207so766926a34.2; Fri, 29 Nov 2024 07:59:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1732895940; x=1733500740; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=isbZ4tT6S+nqvZREZim9rIia4ZQyD95Anv4/kZ2I3bo=; b=ZjFXEHjh6BLdNxBO+KjYX0OnU5iBU3vZjvs7AOU/POkkRGZyvTz3f/Vtizi1r3PhrG Z87F5W6Oi6haMdl5z/MPFLz0cwpfChiqDQ1byWaefSxMCVxOsWN9dYJx19NCy2iqCUhw abZoJYBSb0DU7l3TWvQLR1GgoVTrhITKwhbhoFy2dlMx2U7D+Q0Dv7FAzDJmVqJJjuj2 zfd6eHVfUJiUV5ogeqaQLIBE4zbCPzRc+7LWlJSZtbqONCrUfkr598DIU6d1h3aN5xpF rataYDMkFBVAD7tcHOh6O2WQDch7VTefE5O1h8SSq5X2NXcgokhJWuYiUOPVs6SYJZDz yhng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732895940; x=1733500740; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=isbZ4tT6S+nqvZREZim9rIia4ZQyD95Anv4/kZ2I3bo=; b=V5WAlb/jwa1w/F1MXDjrkq2JxEZDO2NDTy09ZMXYkt9/09ypVGQE7MggJNMlsUGxPD CwR7FnnGGGrdS2C8iq9XCrO7GOLY8adzWsddSP7k9kt1rZFG3UOpM8+3/WNPudBe52W6 mi2pJx+PFntn2HizjTYOMtbwtaculy8LzKlnnN8qu4TaInnsxiGgrLXj1cEDH1pEtewS PPlP02VNsiCY2pHLfcGKno7xwP0BcTVW5arKcuBc4LUmeDSsIRirpVbXmiV8RaL835vK s2UAW9LE0/8f3xbOJOkNGzcfZTJb/Ppd6mmS3Fc2ZFexORclELTxFJmLAC+YhQ63FkHU 2Eeg== X-Forwarded-Encrypted: i=1; AJvYcCWwUp0A/qrDsYoStj5qJGSrQLFMmnZfa+qYHLYs1CBm/elfWDXLdZn6vqSoDFnAhNv7kzDyIs5UAbFOoIo=@vger.kernel.org X-Gm-Message-State: AOJu0YyWvuPct6wHhhg0Nuq27hFfJQQ1102DCpDOEchQanm0ynIhAAP8 FWQh92j61BvasNBBrvkIle0Gqz+2edt/6h2NQse5lY38t6sUeD9W2aAYKg== X-Gm-Gg: ASbGncu4kvsSS3+Pd6qLDYfCQ4DTBOHOCEZCCsUj2TRzQJ13plyLuYbkDPX+0i89F69 EcmsCYZY5gkrHwIbPxo2DWe3pot0awZXKOqFo3lU7qIn4A+N2INA2QP8+nshB9QFdigPJvk2TsL Z2t7k+9gUtaMYWE2w9LPXPtFLrXixwrRyReBaqFwdti1TIGn6iRNyWAMAIsdKLGiCZC2/Tbwivl n+z3xqdqIUM4tf5RpB1eL9IfUpCSj22gD7WG3waRYZos8jTFN9fSH/ewOo2d5pUn5U9w8KMBRNE X-Google-Smtp-Source: AGHT+IFA7OOOCd9snq71zpXwBTEwLyd2JS9MSlzix+mOxpnYXN4r4eO+5LA/Zr3aVSqQYhkl1tRlDQ== X-Received: by 2002:a05:6830:6a14:b0:71d:429c:e818 with SMTP id 46e09a7af769-71d65ce855cmr9861227a34.20.1732895939284; Fri, 29 Nov 2024 07:58:59 -0800 (PST) Received: from pipaware.tx.rr.com ([2603:8080:7400:36da:dff5:4180:2562:4c1e]) by smtp.gmail.com with ESMTPSA id 46e09a7af769-71d725f2251sm794385a34.68.2024.11.29.07.58.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 29 Nov 2024 07:58:58 -0800 (PST) From: Carlos Bilbao To: corbet@lwn.net, avadhut.naik@amd.com, bilbao@vt.edu Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, Carlos Bilbao Subject: [PATCH 3/7] docs/sp_SP: Add translation of process/5.Posting.rst Date: Fri, 29 Nov 2024 09:58:43 -0600 Message-ID: <20241129155851.1023884-4-carlos.bilbao.osdev@gmail.com> X-Mailer: git-send-email 2.43.5 In-Reply-To: <20241129155851.1023884-1-carlos.bilbao.osdev@gmail.com> References: <20241129155851.1023884-1-carlos.bilbao.osdev@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: Avadhut Naik Translate Documentation/process/5.Posting.rst into Spanish. Co-developed-by: Carlos Bilbao Signed-off-by: Carlos Bilbao Signed-off-by: Avadhut Naik Signed-off-by: Carlos Bilbao --- .../translations/sp_SP/process/5.Posting.rst | 388 +++++++++++++++++- .../sp_SP/process/development-process.rst | 1 + 2 files changed, 385 insertions(+), 4 deletions(-) diff --git a/Documentation/translations/sp_SP/process/5.Posting.rst b/Docum= entation/translations/sp_SP/process/5.Posting.rst index 50a3bc5998a8..9e2ac9fdd63d 100644 --- a/Documentation/translations/sp_SP/process/5.Posting.rst +++ b/Documentation/translations/sp_SP/process/5.Posting.rst @@ -1,11 +1,391 @@ .. include:: ../disclaimer-sp.rst =20 :Original: Documentation/process/5.Posting.rst +:Translator: Carlos Bilbao and Avadhut Nai= k =20 .. _sp_development_posting: =20 -Publicar parches -=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +Publicaci=C3=B3n de parches +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 -.. warning:: - TODO a=C3=BAn no traducido +Tarde o temprano, llega el momento en que su trabajo est=C3=A9 listo para = ser +presentado a la comunidad para su revisi=C3=B3n y, eventualmente, su inclu= si=C3=B3n +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=C3=B3n de parches; seguirlos har=C3=A1 la vida mu= cho m=C3=A1s +f=C3=A1cil para todos los involucrados. Este documento intentar=C3=A1 cubr= ir estas +expectativas con un detalle razonable; tambi=C3=A9n se puede encontrar m= =C3=A1s +informaci=C3=B3n en los archivos. +:ref:`Documentation/translations/sp_SP/process/submitting-patches.rst ` +and :ref:`Documentation/translations/sp_SP/process/submit-checklist.rst ` + +Cuando publicar +--------------- + +Hay una tentaci=C3=B3n constante de evitar publicar parches antes de que +est=C3=A9n completamente =E2=80=9Clistos=E2=80=9D. Para parches simples, e= so no es un +problema. Sin embargo, si el trabajo que se est=C3=A1 realizando es comple= jo, +hay mucho que ganar al obtener comentarios de la comunidad antes de que +se complete el trabajo. Por lo tanto, se deber=C3=ADa considerar publicar +trabajo en progreso, o incluso poner a disposici=C3=B3n un =C3=A1rbol de g= it para +que los desarrolladores interesados puedan ponerse al d=C3=ADa con su trab= ajo +en cualquier momento. + +Al publicar c=C3=B3digo que a=C3=BAn no se considera listo para su inclusi= =C3=B3n, es +una buena idea decirlo en la propia publicaci=C3=B3n. Adem=C3=A1s, mencione +cualquier trabajo importante que a=C3=BAn falte por hacer y cualquier prob= lema +conocido. Menos personas mirar=C3=A1n los parches que se sabe que est=C3= =A1n a +medias, pero aquellos que lo hagan vendr=C3=A1n con la idea de que pueden +ayudarlo a llevar el trabajo en la direcci=C3=B3n correcta. + +Antes de crear parches +---------------------- + +Se deben hacer varias cosas antes de considerar enviar parches a la +comunidad de desarrollo. Estas incluyen: + + - Pruebe el c=C3=B3digo en la medida de lo posible. Utilice las herramien= tas + de depuraci=C3=B3n del kernel, aseg=C3=BArese de que el kernel se compi= lar=C3=A1 con + todas las combinaciones razonables de opciones de configuraci=C3=B3n, u= se + compiladores cruzados para compilar para diferentes arquitecturas, etc. + + - Aseg=C3=BArese de que su c=C3=B3digo cumpla con las directrices de esti= lo de + codificaci=C3=B3n del kernel. + + - =C2=BFSu cambio tiene implicaciones de rendimiento? Si es as=C3=AD, deb= e ejecutar + puntos de referencia que muestren cu=C3=A1l es el impacto (o beneficio)= de + su cambio; se debe incluir un resumen de los resultados con el parche. + + - Aseg=C3=BArese de que tiene derecho a publicar el c=C3=B3digo. Si este = trabajo + se realiz=C3=B3 para un empleador, es probable que el empleador tenga + derecho al trabajo y debe estar de acuerdo con su lanzamiento bajo la + GPL. + +Como regla general, pensar un poco m=C3=A1s antes de publicar el c=C3=B3di= go casi +siempre compensa el esfuerzo en poco tiempo. + +Preparaci=C3=B3n del parche +---------------------- + +La preparaci=C3=B3n de parches para su publicaci=C3=B3n puede ser una cant= idad +sorprendente de trabajo, pero, una vez m=C3=A1s, intentar ahorrar tiempo a= qu=C3=AD +generalmente no es recomendable, ni siquiera a corto plazo. + +Los parches deben prepararse contra una versi=C3=B3n espec=C3=ADfica del k= ernel. +Como regla general, un parche debe basarse en el mainline actual que se +encuentra en el =C3=A1rbol git de Linus. Al basarse en el mainline, comien= ce +con un punto de lanzamiento bien conocido, una versi=C3=B3n estable o -rc,= en +lugar de bifurcarse fuera del mainline en un punto arbitrario. + +Puede ser necesario hacer revisiones contra -mm, linux-next o un =C3=A1rbo= l de +subsistemas para facilitar pruebas y revisiones m=C3=A1s amplias. Dependie= ndo +del =C3=A1rea de su parche y de lo que est=C3=A9 sucediendo en otros lugar= es, basar +un parche en estos otros =C3=A1rboles puede requerir una cantidad signific= ativa +de trabajo para resolver conflictos y lidiar con los cambios de API. + +Solo los cambios m=C3=A1s simples deben formatearse como un solo parche; t= odo +lo dem=C3=A1s debe hacerse como una serie l=C3=B3gica de cambios. Dividir = parches +es un poco un arte; algunos desarrolladores pasan mucho tiempo averiguando +c=C3=B3mo hacerlo de la manera que la comunidad espera. Sin embargo, hay +algunas reglas generales que pueden ayudar considerablemente: + + - La serie de parches que publique casi seguramente no ser=C3=A1 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=C3=B3nomos, n= o el + camino que tom=C3=B3 para llegar a esos cambios. + + - Cada cambio l=C3=B3gicamente independiente debe formatearse como un par= che + separado. Estos cambios pueden ser peque=C3=B1os (=E2=80=9Cagregar un c= ampo a esta + estructura=E2=80=9D) o grandes (agregar un nuevo controlador significat= ivo, + por ejemplo), pero deben ser conceptualmente peque=C3=B1os y susceptibl= es + de una descripci=C3=B3n de una l=C3=ADnea. Cada parche debe hacer un ca= mbio + especifico que pueda ser revisado por s=C3=AD mismo y verificado para h= acer + 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=C3=ADtico, reorganiza algunas estructuras y reformatea el c=C3=B3dig= o, es muy + probable que se pase por alto y se pierda la soluci=C3=B3n 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=C3=ADa seguir siendo un kernel funcional. La aplicaci= =C3=B3n + parcial de una serie de parches es un escenario com=C3=BAn cuando se + utiliza la herramienta =E2=80=9Cgit bisect=E2=80=9D para encontrar regr= esiones; si + el resultado es un kernel roto, har=C3=A1 la vida m=C3=A1s dif=C3=ADcil= para los + desarrolladores y usuarios que participan en el noble trabajo de + rastrear problemas. + + - Sin embargo, no lo exagere. Un desarrollador una vez public=C3=B3 un co= njunto + de ediciones en un solo archivo como 500 parches separados =E2=80=93 un= acto + que no lo convirti=C3=B3 en la persona m=C3=A1s popular en la lista de = correo del + kernel. Un solo parche puede ser razonablemente grande si todav=C3=ADa + contiene un solo cambio *l=C3=B3gico*. + + - 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=C3=B3n debe evi= tarse + si es posible; si esa serie agrega regresiones, bisection se=C3=B1alar= =C3=A1 el + ultimo parche como el que caus=C3=B3 el problema, aunque el error real = est=C3=A9 + en otra parte. Siempre que sea posible, un parche que agregue c=C3=B3di= go + nuevo debe hacer que ese c=C3=B3digo se active de inmediato. + +Trabajar para crear la serie de parches perfecta puede ser un proceso +frustrante que lleva mucho tiempo y reflexi=C3=B3n despu=C3=A9s de que el = =E2=80=9Ctrabajo +real=E2=80=9D se ha hecho. Sin embargo, cuando se hace correctamente, es u= n tiempo +bien empleado. + +Formato de parches y registros de cambios +----------------------------------------- + +As=C3=AD que ahora tiene una serie perfecta de parches para publicar, pero= el +trabajo a=C3=BAn no se ha hecho. Cada parche necesita ser formateado en un +mensaje que comunique r=C3=A1pida y claramente su prop=C3=B3sito al resto = del +mundo. A tal fin, cada parche se compondr=C3=A1 de lo siguiente: + + - Una l=C3=ADnea opcional =E2=80=9CFrom=E2=80=9D que nombra al autor del = parche. Esta l=C3=ADnea + solo es necesaria si pasa el parche de otra persona por correo + electr=C3=B3nico, pero nunca est=C3=A1 de m=C3=A1s agregarla en caso de= duda. + + - Una descripci=C3=B3n de una l=C3=ADnea de lo que hace el parche. Este m= ensaje + deber=C3=ADa ser suficiente para que un lector que lo vea sin otro cont= exto + pueda entender el alcance del parche; la l=C3=ADnea aparecer=C3=A1 en l= os + registros de cambios de =E2=80=9Cforma corta=E2=80=9D. Este mensaje gen= eralmente se + formatea con el nombre del subsistema relevante primero, seguido del + prop=C3=B3sito del parche. Por ejemplo: + + :: + + gpio: fix build on CONFIG_GPIO_SYSFS=3Dn + + - Una l=C3=ADnea en blanco seguida de una descripci=C3=B3n detallada del = contenido + del parche. Esta descripci=C3=B3n puede ser tan larga como sea necesari= o; + deber=C3=ADa decir qu=C3=A9 hace el parche y por qu=C3=A9 debe aplicars= e al kernel. + + - Una o m=C3=A1s l=C3=ADneas de etiquetas, con, como m=C3=ADnimo, una l= =C3=ADnea + Signed-off-by: del autor del parche. Las etiquetas se describir=C3=A1n = con + m=C3=A1s detalle a continuaci=C3=B3n. + +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=C3=A1n 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 =E2=80=9Cbackported=E2=80=9D a otros kern= els, a los +cazadores de errores que se preguntan si el parche es responsable de un +problema que est=C3=A1n persiguiendo, a los usuarios que quieren saber c= =C3=B3mo +ha cambiado el kernel, y m=C3=A1s. Un buen registro de cambios transmite la +informaci=C3=B3n necesaria a todas estas personas de la forma m=C3=A1s dir= ecta y +concisa posible. + +Con ese fin, la l=C3=ADnea de resumen debe describir los efectos y la +motivaci=C3=B3n del cambio, as=C3=AD como lo mejor posible dada la restric= ci=C3=B3n de +una l=C3=ADnea. La descripci=C3=B3n detallada puede ampliar esos temas y +proporcionar cualquier informaci=C3=B3n 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=C3=ADtulo al citar +commits). Si un problema est=C3=A1 asociado con un registro espec=C3=ADfic= o o la +salida del compilador, incluya esa salida para ayudar a otros usuarios a +buscar una soluci=C3=B3n al mismo problema. Si el cambio est=C3=A1 destina= do a +apoyar otros cambios que llegar=C3=A1n en un parche posterior, d=C3=ADgalo= . Si se +cambian las API internas, detalle esos cambios y c=C3=B3mo deben responder +otros desarrolladores. En general, cuanto m=C3=A1s pueda ponerse en los za= patos +de todos los que leer=C3=A1n su registro de cambios, mejor ser=C3=A1 ese r= egistro de +cambios (y el kernel en su conjunto). + +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=C3=A1 se= guido +por: + + - El parche, en el formato unificado de parche (=E2=80=9C-u=E2=80=9D). Us= ar la opci=C3=B3n + =E2=80=9C-p=E2=80=9D en diff asociar=C3=A1 los nombres de las funciones= con los cambios, lo + que har=C3=A1 que el parche resultante sea m=C3=A1s f=C3=A1cil de leer = para otros. + +Debe evitar incluir cambios en archivos irrelevantes (los generados por +el proceso de compilaci=C3=B3n, por ejemplo, o los archivos de respaldo del +editor) en el parche. El archivo =E2=80=9Cdontdiff=E2=80=9D en el director= io de +Documentation puede ayudar en este sentido; p=C3=A1selo a diff con la +opci=C3=B3n =E2=80=9C-X=E2=80=9D. + +Las etiquetas ya mencionadas brevemente anteriormente proporcionan +informaci=C3=B3n sobre c=C3=B3mo surgi=C3=B3 el parche. Se describen en de= talle en el +documento +:ref:`Documentation/translations/sp_SP/process/submitting-patches.rst `; +lo que sigue aqu=C3=AD es un breve resumen. + +Una etiqueta se usa para referirse a commits anteriores que introdujeron +problemas corregidos por el parche:: + + Fixes: 1f2e3d4c5b6a ("La primera l=C3=ADnea del commit especificada por l= os primeros 12 caracteres de su ID SHA-1.") + +Otra etiqueta se utiliza para vincular p=C3=A1ginas web con informaci=C3= =B3n +adicional o detalles, por ejemplo, una discusi=C3=B3n previa que condujo al +parche o un documento con una especificaci=C3=B3n implementada por el parc= he:: + + Link: https://example.com/somewhere.html otras cosas opcionales + +Muchos maintainers, al aplicar un parche, tambi=C3=A9n agregan esta etique= ta +para vincular a la =C3=BAltima publicaci=C3=B3n de revisi=C3=B3n p=C3=BAbl= ica del parche; a +menudo, eso se hace autom=C3=A1ticamente mediante herramientas como b4 o g= it +hook como el que se describe en +'Documentation/maintainer/configure-git.rst'. + +Si la URL apunta a un informe de error p=C3=BAblico que est=C3=A1 siendo c= orregido +por el parche, use la etiqueta =E2=80=9CCloses:=E2=80=9D (Cierra) en su lu= gar:: + + Closes: https://example.com/issues/1234 otras cosas opcionales + +Algunos rastreadores de errores tienen la capacidad de cerrar problemas +autom=C3=A1ticamente cuando se aplica un commit con tal etiqueta. Algunos = bots +que monitorean listas de correo tambi=C3=A9n pueden rastrear dichas etique= tas +y realizar ciertas acciones. Los rastreadores de errores privados y las +URL no v=C3=A1lidas est=C3=A1n prohibidos. + +Otro tipo de etiqueta se utiliza para documentar qui=C3=A9n estuvo involuc= rado +en el desarrollo del parche. Cada uno de estos utiliza este formato:: + + tag: Full Name otras cosas opcionales + +Las etiquetas de uso com=C3=BAn son: + + - Signed-off-by: esta es una certificaci=C3=B3n del desarrollador de que = =C3=A9l + o ella tiene el derecho de enviar el parche para su inclusi=C3=B3n 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=C3=B3digo sin la firma adecuada no se puede fusionar en el mainlin= e. + + - Co-developed-by: indica que el parche fue co-creado por varios + desarrolladores; se utiliza para atribuir a los coautores (adem=C3=A1s = 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=C3=B3digo relevante) de que el parche es apropiado = para + su inclusi=C3=B3n 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=C3=B3n del revisor en + :ref:`Documentation/translations/sp_SP/process/submitting-patches.rst <= sp_submittingpatches>` + para obtener m=C3=A1s detalles. + + - Reported-by: nombra a un usuario que inform=C3=B3 un problema que se + soluciona con este parche; esta etiqueta se utiliza para dar cr=C3=A9di= to + a las personas (a menudo infravalorada) que prueban nuestro c=C3=B3digo= y + nos hacen saber cu=C3=A1ndo 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=C3=A9 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=C3=B3 una copia del parche y tuvo la + oportunidad de comentar sobre =C3=A9l. + +Tenga cuidado al agregar etiquetas a sus parches, ya que solo Cc: es +apropiado para la adici=C3=B3n sin el permiso expl=C3=ADcito de la persona= nombrada; +usar Reported-by: est=C3=A1 casi bien en su mayor=C3=ADa, pero pida permis= o si el +error fue reportado en privado. + +Envi=C3=B3 del parche +---------------- + +Antes de enviar sus parches por correo, hay un par de cosas m=C3=A1s de las +que debe ocuparse: + + - =C2=BFEst=C3=A1 seguro de que su correo no corromper=C3=A1 los parches?= Los parches + con cambios gratuitos de espacio en blanco o ajuste de l=C3=ADnea + realizados por el cliente de correo no se aplicar=C3=A1n en el otro + extremo, y a menudo, no se examinar=C3=A1n en detalle. Si tiene alguna + duda, env=C3=ADese el parche por correo y conv=C3=A9nzase de que parece + intacto. + + :ref:`Documentation/translations/sp_SP/process/email-clients.rst ` + tiene algunos consejos =C3=BAtiles sobre c=C3=B3mo hacer que clientes d= e correo + espec=C3=ADficos funcionen para enviar parches. + + - =C2=BFEst=C3=A1 seguro de que su parche est=C3=A1 libre de errores tont= os? Siempre + debe ejecutar parches a trav=C3=A9s de scripts/checkpatch.pl y abordar = las + quejas que surjan. Por favor, tenga en cuenta que checkpatch.pl, aunque + es la encarnaci=C3=B3n de una buena cantidad de pensamiento sobre c=C3= =B3mo + deber=C3=ADan ser los parches del kernel, no es m=C3=A1s inteligente qu= e usted. + Si corregir una queja de checkpatch.pl empeorar=C3=ADa el c=C3=B3digo, = no lo + haga. + +Los parches siempre deben enviarse como texto sin formato. Por favor, no +los env=C3=ADe como archivos adjuntos; eso hace que sea mucho m=C3=A1s dif= =C3=ADcil para +los revisores citar secciones del parche en sus respuestas. En su lugar, +simplemente coloca el parche directamente en su mensaje. + +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=C3=A1n su +publicaci=C3=B3n en las listas de correo. En particular, las copias deben +ir a: + + - El (los) maintainer(s) del (de los) subsistema(s) afectado(s). Como se + describi=C3=B3 anteriormente, el archivo MAINTAINERS es el primer lugar= para + buscar a estas personas. + + - Otros desarrolladores que han estado trabajando en la misma + =C3=A1rea =E2=80=93 especialmente aquellos que podr=C3=ADan estar traba= jando all=C3=AD ahora. + Usar git para ver qui=C3=A9n m=C3=A1s ha modificado los archivos en los= que est=C3=A1 + trabajando puede ser =C3=BAtil. + + - Si est=C3=A1 respondiendo a un informe de error o a una solicitud de + funci=C3=B3n, copie tambi=C3=A9n al autor. + + - Envi=C3=A9 una copia a la lista de correo relevante o, si no se aplica = nada + m=C3=A1s, a la lista de linux-kernel. + + - Si est=C3=A1 corrigiendo un error, piense si la correcci=C3=B3n debe in= cluirse en + la pr=C3=B3xima actualizaci=C3=B3n estable. Si es as=C3=AD, stable@vger= .kernel.org + deber=C3=ADa obtener una copia del parche. Tambi=C3=A9n agregue un + "Cc: stable@vger.kernel.org" a las etiquetas dentro del parche; eso + har=C3=A1 que el equipo estable reciba una notificaci=C3=B3n cuando su = soluci=C3=B3n + incluya en el mainline. + +Al seleccionar destinatarios para un parche, es bueno saber qui=C3=A9n cre= e que +eventualmente aceptar=C3=A1 el parche y lo fusionar=C3=A1. Aunque es posib= le enviar +parches directamente a Linus Torvalds y hacer que los fusione, las cosas +normalmente no se hacen de esa manera. Linus est=C3=A1 ocupado y hay +maintainers de subsistemas que vigilan partes espec=C3=ADficas del kernel. +Generalmente, querr=C3=A1 que ese maintainer fusione sus parches. Andrew M= orton +es a menudo el objetivo del parche de =C3=BAltimo recurso si no hay un +maintainer obvio. + +Los parches necesitan buenas l=C3=ADneas de asunto. El formato can=C3=B3ni= co de una +l=C3=ADnea de parche es algo as=C3=AD como: + +:: + + [PATCH nn/mm] subsys: descripci=C3=B3n en una l=C3=ADnea del parche + +donde =E2=80=9Cnn=E2=80=9D es el n=C3=BAmero ordinal del parche, =E2=80=9C= =E2=80=9Dmm=E2=80=9D es el n=C3=BAmero total de +parches en la serie, y =E2=80=9Csubsys=E2=80=9D es el nombre del subsistem= a afectado. +Claramente, nn/mm se puede omitir para un parche =C3=BAnico e independient= e. + +Si tiene una serie significativa de parches, es costumbre enviar una +descripci=C3=B3n introductoria como parte cero. Sin embargo, esta convenci= =C3=B3n no +se sigue universalmente; si la utiliza, recuerde que la informaci=C3=B3n e= n la +introducci=C3=B3n no se incluye en los registros de cambios del kernel. Po= r lo +tanto, aseg=C3=BArese de que los parches, en s=C3=AD mismos, tengan inform= aci=C3=B3n +completa del registro de cambios. + +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=C3=A1 usa= ndo +git, por favor evite la opci=C3=B3n =E2=80=93chain-reply-to para evitar cr= ear un +anidamiento excepcionalmente profundo. diff --git a/Documentation/translations/sp_SP/process/development-process.r= st b/Documentation/translations/sp_SP/process/development-process.rst index 62ee4b2e109e..fa078a18c1a7 100644 --- a/Documentation/translations/sp_SP/process/development-process.rst +++ b/Documentation/translations/sp_SP/process/development-process.rst @@ -27,3 +27,4 @@ para entenderla. 2.Process 3.Early-stage 4.Coding + 5.Posting --=20 2.43.0