From nobody Sun Dec 14 20:28:52 2025 Received: from mail-ot1-f43.google.com (mail-ot1-f43.google.com [209.85.210.43]) (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 DE01A13D619; Fri, 29 Nov 2024 15:59:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.43 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732895943; cv=none; b=M27xKsMj5Szf6uCRl3ngZyp8Uuj/40cgHR9Kbk1AGYEa46bKPAJuXKynR09QjIaFjBg1n1NBX6NDsJMAAU0sSFkRiupA+HwRroues2JnR7vQy29gv146+2IYjU5LjPqdGiBYckFswTYA6tjmM7l90dR8f/6XeddnhJC03qeuGTY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732895943; c=relaxed/simple; bh=Fy/M2E538vc9eRpfXKALjrJRV+gP0+14bDrv6TrmK0I=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=KW+Wf5puSOSzUd6XM4IlUIQ+CQD7wRrMXS9fK+5kuMimz2LS5U4Z8cR5zx9nXzvK3HiY/McGjXhSDB0GphfWr9MJ4xm+QivJFdJt0n/H1TLYSV8OSVBlEXSooFBtqgAL9+/oCAn0YM0S+K5w8FFoQZa4XkCyGJa/+s8kaSmj76M= 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=ddzl/TVU; arc=none smtp.client-ip=209.85.210.43 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="ddzl/TVU" Received: by mail-ot1-f43.google.com with SMTP id 46e09a7af769-71d5984e56fso838084a34.3; Fri, 29 Nov 2024 07:59:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1732895941; x=1733500741; 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=Sn9lfr8ePtR9WA1qAJtFEJLICpFE6nvqUuxa8WmTw4Q=; b=ddzl/TVUxyzVOLD54yrMUOWP49Q06bY8Syg373lFsgd5NG9CchGUnv8P+4PJ6a9jQt u6BftErIS7MKGTrXAsj/yyavVSwKavBp03A4391P8EolVjwK6nsCgstGH1+jl5AJgv1c Fureusm+ZEr0QmDWW3+4npWXrsrd6PRJoKve5NuHm38OtjNvEC2QN2eUrwPFXxNxgH1j pmDNQZv5nQ3K84P2/FpL2UU1wqKzhV3J8o+rpHpTFiAtYUUpZ1V6y9a0j3TrZbkiADUC mReGnF23KisxtZSH7z07cxc1E1BRSXibGDsr9VelwaPiGoSgY/qwGn+9x+USdhvFkx9o gttg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732895941; x=1733500741; 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=Sn9lfr8ePtR9WA1qAJtFEJLICpFE6nvqUuxa8WmTw4Q=; b=i9NxhqLM5vTgyxQPI/5EzQvC2LH+QaQkwKnvb4pxMvNMoeI8JDmTNJ3LEcjYbxTh/e U3MDah4mxwjOQT76dydsjBmGgJSwfOL2sp4Pl3tBc1tXEDP+k89/oYuAr6aA9X9C6ig8 m0qkNCezxOiuiCo/Hg0rEYFfQaZiO5PtmJzuKs1nH5wAx1zjH3wlnHWRl1WiIaQ+Ib2l XKUnwL6qo5EPhrZV8lQqn0J9ROY9pr0LOrw3+EeQ0wNZzTKvuklcOZjkwKwc6AOEy81b vySKICXcGedNX1EpoSHwDqb92x8fMHTHfJqKZe1ni/7WRqS2RqEC+7kdz/NmATpgOal+ Ayww== X-Forwarded-Encrypted: i=1; AJvYcCW9Rn8vK3XXimK1aVr3maBbyryRArmiGamRwyPHRPhQYV3trwuIh80Qq/mLe2X5V+HHblKvu7YO1m2X2Jw=@vger.kernel.org X-Gm-Message-State: AOJu0YwWzpDj9AvCemnZTXz4crj6TQtoeUBDoxcgunsGNStNdHMdLexX +90UK+LJpzhwAPz1INlE77nftMM8QylmArcBW7YDK6LWqYMEwxsQ30skrQ== X-Gm-Gg: ASbGncsYxBAvfyeyZQDg01eks08MSe+qwSdXVCb4p44VNiOm5EXYzPXbSp9Qa1P1i/F hfK+BXGBAfynx0t5P2dMysAgHke16S8j715d9lJvel/XkMvHoeNRJdVP9BKPmiC7csCFj0mC8r/ NwR1+rYoBDazZ9kGi77Hmliuj9+a6Wx00k+0++VQZsvGKTz2wxNNIki+WF0ADN+0czdukE0QXkW GvxMNhgyKjNWyV2YVjxG+lhLtKpcB7/h6FPJcbYNhJtOJwl5fZT4123zRCSx5P7E5Ir3EQBkZ5t X-Google-Smtp-Source: AGHT+IHIkXjv6XWZH93Poj83mh/hHHNNPXC44BupbJE2oKJDQf7iqxic/mpI3Un09SKVRJ+cNLHKnA== X-Received: by 2002:a05:6830:25d0:b0:718:9bac:58a5 with SMTP id 46e09a7af769-71d65c94f10mr6392281a34.11.1732895940776; Fri, 29 Nov 2024 07:59:00 -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.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 29 Nov 2024 07:59:00 -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 4/7] docs/sp_SP: Add translation of process/6.Followthrough.rst Date: Fri, 29 Nov 2024 09:58:44 -0600 Message-ID: <20241129155851.1023884-5-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 Translate Documentation/process/6.Followthrough.rst into Spanish. Co-developed-by: Avadhut Naik Signed-off-by: Avadhut Naik Signed-off-by: Carlos Bilbao --- .../sp_SP/process/6.Followthrough.rst | 223 +++++++++++++++++- .../sp_SP/process/development-process.rst | 1 + 2 files changed, 222 insertions(+), 2 deletions(-) diff --git a/Documentation/translations/sp_SP/process/6.Followthrough.rst b= /Documentation/translations/sp_SP/process/6.Followthrough.rst index f0acf9082bb3..083898af46f5 100644 --- a/Documentation/translations/sp_SP/process/6.Followthrough.rst +++ b/Documentation/translations/sp_SP/process/6.Followthrough.rst @@ -1,11 +1,230 @@ .. include:: ../disclaimer-sp.rst =20 :Original: Documentation/process/6.Followthrough.rst +:Translator: Carlos Bilbao and Avadhut Nai= k =20 .. _sp_development_followthrough: =20 Seguimiento =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 -.. warning:: - TODO a=C3=BAn no traducido +Llegados a este punto, ha seguido las directrices dadas hasta ahora, lo que +sumado a sus propias habilidades de ingenier=C3=ADa, ha resultado en una s= erie +de parches perfectos. Uno de los mayores errores que incluso los +desarrolladores de kernel experimentados pueden cometer es concluir que su +trabajo ya est=C3=A1 hecho. En verdad, publicar parches indica una transic= i=C3=B3n a +la siguiente etapa del proceso, con, posiblemente, bastante trabajo a=C3= =BAn por +hacer. + +Es raro un parche que sea tan bueno en su primera publicaci=C3=B3n que no = haya +espacio para la mejora. El proceso de desarrollo del kernel reconoce este +hecho y, como resultado, est=C3=A1 muy orientado hacia la mejora del c=C3= =B3digo +publicado. Y usted, como autor de ese c=C3=B3digo, se espera que trabaje c= on la +comunidad del kernel para asegurarse de que su c=C3=B3digo est=C3=A9 a la = altura de +los est=C3=A1ndares de calidad del kernel. No participar en este proceso e= s muy +probable que impida la inclusi=C3=B3n de sus parches en la l=C3=ADnea prin= cipal. + +Trabajando con revisores +------------------------ + +Un parche de cualquier importancia resultar=C3=A1 en una serie de comentar= ios de +otros desarrolladores a medida que revisan el c=C3=B3digo. Trabajar con los +revisores puede ser, para muchos desarrolladores, la parte m=C3=A1s intimi= dante +del proceso de desarrollo del kernel. Sin embargo, la vida puede ser mucho +m=C3=A1s f=C3=A1cil si tiene en cuenta algunas cosas: + +- Si ha explicado bien su parche, los revisores entender=C3=A1n su valor y= por + qu=C3=A9 se tom=C3=B3 la molestia de escribirlo. Pero ese valor no les i= mpedir=C3=A1 + hacer una pregunta fundamental: =C2=BFc=C3=B3mo ser=C3=A1 mantener un ke= rnel con este + c=C3=B3digo en =C3=A9l cinco o diez a=C3=B1os despu=C3=A9s? Muchos de lo= s cambios que se le + pueden pedir que haga, desde ajustes de estilo de codificaci=C3=B3n hasta + reescrituras sustanciales, provienen de la comprensi=C3=B3n de que Linux + seguir=C3=A1 existiendo y en desarrollo dentro de una d=C3=A9cada. + +- La revisi=C3=B3n de c=C3=B3digo es un trabajo arduo y es una ocupaci=C3= =B3n + relativamente ingrata; la gente recuerda qui=C3=A9n escribi=C3=B3 el c= =C3=B3digo del + kernel, pero hay poca fama duradera para aquellos que lo revisaron. As= =C3=AD + que los revisores pueden ponerse de mal humor, especialmente cuando ven + los mismos errores repetirse una y otra vez. Si recibe una revisi=C3=B3n= que + parece enojada, insultante o abiertamente ofensiva, resista el impulso de + responder de la misma manera. La revisi=C3=B3n de c=C3=B3digo se trata d= el c=C3=B3digo, + no de las personas, y los revisores de c=C3=B3digo no lo est=C3=A1n atac= ando + personalmente. + +- De manera similar, los revisores de c=C3=B3digo no est=C3=A1n tratando d= e promover + las agendas de sus empleadores a expensas de la suya. Los desarrolladores + del kernel a menudo esperan estar trabajando en el kernel dentro de + varios a=C3=B1os, pero entienden que su empleador podr=C3=ADa cambiar. + Verdaderamente, casi sin excepci=C3=B3n, est=C3=A1n trabajando hacia la = creaci=C3=B3n + del mejor kernel posible; no est=C3=A1n tratando de causar incomodidad a= los + competidores de sus empleadores. + +- Est=C3=A9 preparado para solicitudes aparentemente rid=C3=ADculas de cam= bios en el + estilo de codificaci=C3=B3n y solicitudes para factorizar parte de su c= =C3=B3digo + en partes compartidas del kernel. Una de las tareas que realizan los + maintainers es mantener las cosas con una apariencia uniforme. A veces, = esto significa que el truco ingenioso en su driver para sortear un problema= necesita convertirse en una caracter=C3=ADstica generalizada del kernel li= sta para la pr=C3=B3xima vez. + +En resumen, cuando los revisores le env=C3=ADan comentarios, necesita pres= tar +atenci=C3=B3n a las observaciones t=C3=A9cnicas que est=C3=A1n haciendo. N= o permita que su +forma de expresarse o su propio orgullo le impidan hacerlo. Cuando reciba +comentarios de revisi=C3=B3n sobre un parche, t=C3=B3mese el tiempo para e= ntender lo +que el revisor est=C3=A1 tratando de decir. Si es posible, arregle las cos= as que +el revisor le est=C3=A1 pidiendo que corrija. Y responda al revisor: +agrad=C3=A9zcales y describa c=C3=B3mo responder=C3=A1 a sus preguntas. + +Tenga en cuenta que no tiene que estar de acuerdo con cada cambio sugerido +por los revisores. Si cree que el revisor ha malinterpretado su c=C3=B3dig= o, +explique lo que realmente est=C3=A1 sucediendo. Si tiene una objeci=C3=B3n= t=C3=A9cnica a +un cambio sugerido, descr=C3=ADbalo y justifique su soluci=C3=B3n al probl= ema. Si sus +explicaciones tienen sentido, el revisor las aceptar=C3=A1. Sin embargo, s= i su +explicaci=C3=B3n no resulta persuasiva, especialmente si otros comienzan a= estar +de acuerdo con el revisor, t=C3=B3mese un tiempo para reflexionar nuevamen= te +sobre las cosas. Puede ser f=C3=A1cil quedar cegado por su propia soluci= =C3=B3n a un +problema hasta el punto de no darse cuenta de que algo est=C3=A1 +fundamentalmente mal o, quiz=C3=A1s, ni siquiera est=C3=A1 resolviendo el = problema +correcto. + +Andrew Morton ha sugerido que cada comentario de revisi=C3=B3n que no resu= lte en +un cambio de c=C3=B3digo deber=C3=ADa resultar en un comentario adicional = en el +c=C3=B3digo; eso puede ayudar a los revisores futuros a evitar las pregunt= as que +surgieron la primera vez. + +Un error fatal es ignorar los comentarios de revisi=C3=B3n con la esperanz= a de +que desaparezcan. No desaparecer=C3=A1n. Si vuelve a publicar c=C3=B3digo = sin haber +respondido a los comentarios que recibi=C3=B3 la vez anterior, es probable= que +descubra que sus parches no van a ninguna parte. + +Hablando de volver a publicar c=C3=B3digo: tenga en cuenta que los revisor= es no +recordar=C3=A1n todos los detalles del c=C3=B3digo que public=C3=B3 la vez= anterior. As=C3=AD +que siempre es una buena idea recordarles sobre problemas planteados +anteriormente y c=C3=B3mo los manej=C3=B3; el registro de cambios del parc= he es un +buen lugar para este tipo de informaci=C3=B3n. Los revisores no deber=C3= =ADan tener +que buscar en los archivos de la lista para familiarizarse con lo que se +dijo la =C3=BAltima vez; si les ayuda a tener un buen comienzo, estar=C3= =A1n de mejor +humor cuando revisiten su c=C3=B3digo. + +=C2=BFQu=C3=A9 sucede si ha intentado hacer todo bien y las cosas a=C3=BAn= no van a +ninguna parte? La mayor=C3=ADa de los desacuerdos t=C3=A9cnicos pueden res= olverse +mediante discusi=C3=B3n, pero hay momentos en los que alguien simplemente = tiene +que tomar una decisi=C3=B3n. Si realmente cree que esta decisi=C3=B3n est= =C3=A1 en su +contra de manera incorrecta, siempre puede intentar apelar a una autoridad +superior. En el momento de escribir esto, esa autoridad superior tiende a +ser Andrew Morton. Andrew tiene un gran respeto en la comunidad de +desarrollo del kernel; a menudo puede desbloquear una situaci=C3=B3n que p= arece +estar irremediablemente bloqueada. Sin embargo, apelar a Andrew no debe +hacerse a la ligera, y no antes de que se hayan explorado todas las dem=C3= =A1s +alternativas. Y tenga en cuenta, por supuesto, que =C3=A9l puede no estar = de +acuerdo con usted tampoco. + +=C2=BFQu=C3=A9 pasa despu=C3=A9s? +-------------------- + +Si un parche se considera algo bueno para agregar al kernel, y una vez que +se hayan resuelto la mayor=C3=ADa de los problemas de revisi=C3=B3n, el si= guiente +paso suele ser la entrada en el =C3=A1rbol del mantenedor de un subsistema= . C=C3=B3mo +funciona eso var=C3=ADa de un subsistema a otro; cada mantenedor tiene su = propia +forma de hacer las cosas. En particular, puede haber m=C3=A1s de un =C3=A1= rbol, uno, +quiz=C3=A1s, dedicado a los parches planificados para la pr=C3=B3xima vent= ana de +fusi=C3=B3n y otro para trabajos a m=C3=A1s largo plazo. + +Para los parches que se aplican a =C3=A1reas para las que no hay un =C3=A1= rbol de +subsistema obvio (parches de gesti=C3=B3n de memoria, por ejemplo), el =C3= =A1rbol +predeterminado suele ser -mm. Los parches que afectan a m=C3=BAltiples +subsistemas tambi=C3=A9n pueden terminar pasando por el =C3=A1rbol -mm. + +La inclusi=C3=B3n en un =C3=A1rbol de subsistema puede dar mayor visibilid= ad a un +parche. Ahora, otros desarrolladores que trabajan con ese =C3=A1rbol recib= ir=C3=A1n +el parche por defecto. Los =C3=A1rboles de subsistemas t=C3=ADpicamente al= imentan +linux-next tambi=C3=A9n, haciendo que su contenido sea visible para la com= unidad +de desarrollo en su conjunto. En este punto, hay una buena probabilidad de +que reciba m=C3=A1s comentarios de un nuevo conjunto de revisores; estos +comentarios necesitan ser respondidos como en la ronda anterior. + +Lo que tambi=C3=A9n puede suceder en este punto, dependiendo de la natural= eza de +su parche, es que aparezcan conflictos con el trabajo que est=C3=A1n reali= zando +otros. En el peor de los casos, conflictos pesados de parches pueden +resultar en que algunos trabajos se pongan en espera para que los parches +restantes puedan ser ajustados y fusionados. Otras veces, la resoluci=C3= =B3n de +conflictos involucrar=C3=A1 trabajar con otros desarrolladores y, posiblem= ente, +mover algunos parches entre =C3=A1rboles para asegurarse de que todo se ap= lique +sin problemas. Este trabajo puede ser un dolor, pero cuente sus +bendiciones: antes de la llegada del =C3=A1rbol linux-next, estos conflict= os a +menudo solo surg=C3=ADan durante la ventana de fusi=C3=B3n y ten=C3=ADan q= ue ser abordados +de prisa. Ahora pueden resolverse con calma, antes de que se abra la +ventana de fusi=C3=B3n (merge window). + +Alg=C3=BAn d=C3=ADa, si todo va bien, iniciar=C3=A1 sesi=C3=B3n y ver=C3= =A1 que su parche ha sido +incluido en el kernel principal. =C2=A1Felicidades! Una vez que la celebra= ci=C3=B3n +termine (y se hayas agregado al archivo MAINTAINERS), vale la pena +recordar un peque=C3=B1o hecho importante: el trabajo a=C3=BAn no est=C3= =A1 hecho. La +inclusi=C3=B3n trae sus propios desaf=C3=ADos. + +Para empezar, la visibilidad de su parche ha aumentado una vez m=C3=A1s. P= uede +haber una nueva ronda de comentarios de desarrolladores que no estaban al +tanto del parche antes. Puede ser tentador ignorarlos, ya que ya no hay +cuesti=C3=B3n de que su c=C3=B3digo sea fusionado. Sin embargo, resista esa +tentaci=C3=B3n; a=C3=BAn necesita ser receptivo a los desarrolladores que = tienen +preguntas o sugerencias. + +M=C3=A1s importante a=C3=BAn, la inclusi=C3=B3n en la l=C3=ADnea principal= pone su c=C3=B3digo en +manos de un grupo mucho m=C3=A1s grande de probadores. Incluso si ha contr= ibuido +un driver para hardware que a=C3=BAn no est=C3=A1 disponible, se sorprende= r=C3=A1 de +cu=C3=A1ntas personas construir=C3=A1n su c=C3=B3digo en sus kernels. Y, p= or supuesto, +donde hay probadores, habr=C3=A1 informes de errores. + +El peor tipo de informes de errores son las regresiones. Si su parche causa +una regresi=C3=B3n, encontrar=C3=A1 un n=C3=BAmero inc=C3=B3modo de ojos s= obre usted; las +regresiones pueden dar lugar a mucho malestar en la comunidad y pueden +hacer que algunos desarrolladores comiencen a preguntarse si su parche +realmente deber=C3=ADa haber sido fusionado en primer lugar. As=C3=AD que = est=C3=A9 atento +a los comentarios sobre problemas y, si es posible, corrija los errores de +inmediato. + +Despu=C3=A9s de haber abordado cualquier regresi=C3=B3n, puede haber otros= errores +ordinarios que resolver. El per=C3=ADodo de estabilizaci=C3=B3n es su mejor +oportunidad para corregir estos errores y garantizar que el debut de su +c=C3=B3digo en una versi=C3=B3n del kernel principal sea lo m=C3=A1s s=C3= =B3lido posible. As=C3=AD +que, por favor, responda a los informes de errores y solucione los +problemas si es posible. Para eso es el per=C3=ADodo de estabilizaci=C3=B3= n; puede +comenzar a crear parches nuevos y geniales una vez que se hayan resuelto +los problemas de los antiguos. + +Y no olvide que hay otros hitos que tambi=C3=A9n pueden generar informes de +errores: la pr=C3=B3xima versi=C3=B3n estable del kernel principal, cuando +distribuidores prominentes adopten una versi=C3=B3n del kernel que conteng= a su +parche, etc. Continuar respondiendo a estos informes es una cuesti=C3=B3n = de +orgullo b=C3=A1sico en su trabajo. Sin embargo, si eso no es suficiente +motivaci=C3=B3n, tambi=C3=A9n vale la pena considerar que la comunidad de = desarrollo +recuerda a los desarrolladores que pierden inter=C3=A9s en su c=C3=B3digo = despu=C3=A9s de +que se fusiona. La pr=C3=B3xima vez que publique un parche, lo evaluar=C3= =A1n con la +suposici=C3=B3n de que no estar=C3=A1 disponible para mantenerlo despu=C3= =A9s. + +Otras cosas que pueden suceder +------------------------------- + +Un d=C3=ADa, puede que abra su cliente de correo y vea que alguien le ha e= nviado +un parche para su c=C3=B3digo. Esa es una de las ventajas de tener su c=C3= =B3digo +disponible p=C3=BAblicamente, despu=C3=A9s de todo. Si est=C3=A1 de acuerd= o con el parche, puede reenviarlo al maintainer del subsistema (aseg=C3=BAr= ese de incluir una +l=C3=ADnea From: adecuada para que la atribuci=C3=B3n sea correcta, y a=C3= =B1ada su propia +firma), o enviar una respuesta Acked-by: y dejar que el autor original lo +env=C3=ADe hacia arriba. + +Si no est=C3=A1 de acuerdo con el parche, env=C3=ADe una respuesta educada= explicando +por qu=C3=A9. Si es posible, d=C3=ADgale al autor qu=C3=A9 cambios deben h= acerse para que +considere el parche aceptable. Existe una cierta resistencia a incluir +parches que son rechazados por el autor y el maintainer del c=C3=B3digo, p= ero +esto tiene un l=C3=ADmite. Si se interpreta que bloque buen trabajo, esos +parches eventualmente lo eludir=C3=A1n y se incorporar=C3=A1n al kernel de= todos +modos. En el kernel de Linux, nadie tiene poder de veto absoluto sobre +ning=C3=BAn c=C3=B3digo. Excepto quiz=C3=A1s Linus. + +En muy raras ocasiones, puede encontrar algo completamente diferente: otro +desarrollador publica una soluci=C3=B3n distinta a su problema. En ese pun= to, es +probable que uno de los dos parches no se incluya, y "el m=C3=ADo fue el +primero" no se considera un argumento t=C3=A9cnico convincente. Si el parc= he de +otra persona desplaza al suyo y se incorpora al kernel, realmente solo hay +una manera de responder: alegrarse de que su problema se haya resuelto y +continuar con su trabajo. Que su trabajo sea desplazado de esta manera +puede ser doloroso y desalentador, pero la comunidad recordar=C3=A1 su rea= cci=C3=B3n +mucho despu=C3=A9s de que hayan olvidado de qui=C3=A9n era el parche que r= ealmente se +incluy=C3=B3. diff --git a/Documentation/translations/sp_SP/process/development-process.r= st b/Documentation/translations/sp_SP/process/development-process.rst index fa078a18c1a7..c977d047a792 100644 --- a/Documentation/translations/sp_SP/process/development-process.rst +++ b/Documentation/translations/sp_SP/process/development-process.rst @@ -28,3 +28,4 @@ para entenderla. 3.Early-stage 4.Coding 5.Posting + 6.Followthrough --=20 2.43.0