From nobody Sun Dec 14 12:51:50 2025 Received: from mail-ot1-f49.google.com (mail-ot1-f49.google.com [209.85.210.49]) (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 8BF87145B1D; Fri, 29 Nov 2024 15:58:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.49 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732895939; cv=none; b=d8JhyMmwqStxbsXA1gjt4/ig/EkqUCMj5vcpBMfrFvWHvtPK3cD070atm3G7oOpYZICmeq05Y2CY16/Vhby9csgGsuMQaTgyw23SydCrUelIRef6xPGrtcajaAuXUnJ41ZISOOx4Wc8FQXgQyibl9sVuKWiEiTvtTRuldv4Uie8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732895939; c=relaxed/simple; bh=38Iee4iP+AnwM/xmqSDKY0prqlEZMbMh88emZus4XxI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=TQsETkiX1mhLXsOLocuBg0cQ6DIolD+U9pxDcXiX+/rLSU3Zt97qDyPTgv1OcM2OVTH+dtJP/LkaxkAj4y86qYgp8ajX5IJTRJQZlg1yxwa28IqARUy24qSsVj+QlBYwqAUMoRSnaCPSDyk31JH8uLCit3wEumHjX04x04tYW0g= 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=Ml5FmBIS; arc=none smtp.client-ip=209.85.210.49 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="Ml5FmBIS" Received: by mail-ot1-f49.google.com with SMTP id 46e09a7af769-71d4c462ab1so771190a34.0; Fri, 29 Nov 2024 07:58:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1732895936; x=1733500736; 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=Z6CigXbvq9WM0qV1TtLzdk3QQaXrv+YjmLAcWjiR0k4=; b=Ml5FmBISwp8xa9NoW2JJuT6CcwhNnIOOCdk7c93E2VWQ8IwMPkfF+nbeswLax1y0LC EqPJWTssCJuQocVXXCBD8MoOqxt6WXESGPJSZpAxvskcJiXhOI541eakH/f4UsdBZ4gp PEsI8e1iYznyeglnUDHsY6IPuzCFTm5dMKls7vLlCi+awjNiYjEJilh5Ki3PIx08HON8 xLrszywVbhnIgQgbs9w6nn5Aj8Dwq/DxpFguE4ylgqH1uebPUJt9KSFvNsbl3H8B2qkD CFrY/hfBZetWKG6bl3sE86ZybhBl+/CCPRI0Y4j1Z+czj73kMt9u0BjQhn+kiC6Y8IbV gd4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732895936; x=1733500736; 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=Z6CigXbvq9WM0qV1TtLzdk3QQaXrv+YjmLAcWjiR0k4=; b=VEhj/vPJiD6IMNkQVlaAwG4s6Cp9no7WkFyccioIwiPeuRKLk+2qnCY9HeNGliDzgN HLUH646ZniljdpZR+9QY67qr5TalZOO5cRoRvn7oOAUq4BZWEXZa33Ch8xCLQuLqww4m 9cmU1oC4kbxAAt4tSsx3zNhEqxzLQYh7kslakPpr6sOZ7mCawfhbEvvwpaSb366RyV98 XgS/7gNR9i10LjENdRoGAIf06FyywlSoXCVr0jx/SlHWBoVakaQ2Bak/uAYtn62HbqEH SbOxhMqj53nSmhORfLmz1hLesJ5IJ4+syoDcDvR8FmfFiFpYit3Z4NiNGvhXCjeB4KV3 L1Vg== X-Forwarded-Encrypted: i=1; AJvYcCVKYI+uG6D3fC+SR/iwPXKW5vFmfGj3z3dfUNsL/xvOB+yOMFpMkMrbtwDPv9wp7wFpBbbRVnZKZ+VagOs=@vger.kernel.org X-Gm-Message-State: AOJu0YyvpKpHS4eAiX8kdXISucdoFgz18ItMhjkB5QekJmlevxsd7ahD mfEmXXsF1Hvm678PwFZ85MsdyHdljzaZrKk9bxniOxUQSdGXmd1DEhL7FA== X-Gm-Gg: ASbGncslEaf3pnNaXhvlRmyUiXJIFbKdmZkxtUbptoDalTfnv/OEZQ/6rO1ZedPfF0E gYm0vUHWH4jUFKrHp0RN1gBp+iLD+4pE00tpG71Z18uLAcOri3AQvfV6kGUrEGAJxVfcWKo0KGu g55TtfGSuQZJRNBthTNBDNGrjpEjnH5d0A5CH6PxkRJ4Wgj8SLXVG++rhvpxwzuaRg1xTGXh33A G+IUtjY+C4VL6AtrD5UvECDOszjKJ3A4y3s9S0sTRgGNG8GxKzhW4oxflDbPitSWsBfdo7d5n+v X-Google-Smtp-Source: AGHT+IGi+g/J+ETyJb7BSsmDZuPh9QPdLLbvsw4oIZeoRH/MMcp+IAgcppcuYqJYcvAf0sqTlKe7fQ== X-Received: by 2002:a05:6830:34a8:b0:71d:4385:6662 with SMTP id 46e09a7af769-71d65d0556emr10507644a34.27.1732895936204; Fri, 29 Nov 2024 07:58:56 -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.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 29 Nov 2024 07:58:55 -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 1/7] docs/sp_SP: Add translation of process/3.Early-stage.rst Date: Fri, 29 Nov 2024 09:58:41 -0600 Message-ID: <20241129155851.1023884-2-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/3.Early-stage.rst into Spanish. Co-developed-by: Avadhut Naik Signed-off-by: Avadhut Naik Signed-off-by: Carlos Bilbao --- .../sp_SP/process/3.Early-stage.rst | 234 +++++++++++++++++- .../sp_SP/process/development-process.rst | 1 + 2 files changed, 233 insertions(+), 2 deletions(-) diff --git a/Documentation/translations/sp_SP/process/3.Early-stage.rst b/D= ocumentation/translations/sp_SP/process/3.Early-stage.rst index 71cfb3fb0fda..bb3c630c7fd4 100644 --- a/Documentation/translations/sp_SP/process/3.Early-stage.rst +++ b/Documentation/translations/sp_SP/process/3.Early-stage.rst @@ -1,11 +1,241 @@ .. include:: ../disclaimer-sp.rst =20 :Original: Documentation/process/3.Early-stage.rst +:Translator: Carlos Bilbao and Avadhut Nai= k =20 .. _sp_development_early_stage: =20 Planificaci=C3=B3n en etapa inicial =3D=3D=3D=3D=3D=3D=3D=3D=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 +Cuando uno se sienta a planear un proyecto de desarrollo del kernel Linux, +puede ser tentador lanzarse directamente a escribir c=C3=B3digo. Sin embar= go, +como ocurre con cualquier proyecto significativo, gran parte del trabajo +que conduce al =C3=A9xito es mejor realizarlo antes de escribir la primera= l=C3=ADnea +de c=C3=B3digo. Dedicar tiempo a la planificaci=C3=B3n y comunicaci=C3=B3n= temprana puede +ahorrar mucho m=C3=A1s tiempo en adelante. + +Especificar el problema +----------------------- + +Como en cualquier proyecto de ingenier=C3=ADa, una mejora exitosa del kern= el +comienza con una descripci=C3=B3n clara del problema a resolver. En algunos +casos, este paso es sencillo: cuando se necesita un driver para un hardware +espec=C3=ADfico, por ejemplo. En otros, sin embargo, es tentador confundir= el +problema real con la soluci=C3=B3n propuesta, lo que puede generar dificul= tades. + +Consideremos un ejemplo: hace algunos a=C3=B1os, los desarrolladores que +trabajaban con audio en Linux buscaban una forma de ejecutar aplicaciones +sin interrupciones u otros artefactos causados por la latencia excesiva en +el sistema. La soluci=C3=B3n a la que llegaron fue un m=C3=B3dulo del kern= el +destinado a integrarse en el marco del M=C3=B3dulo de Seguridad de Linux (= LSM, +por sus siglas en ingl=C3=A9s); este m=C3=B3dulo pod=C3=ADa configurarse p= ara dar acceso a +aplicaciones espec=C3=ADficas al planificador en tiempo real. Este m=C3=B3= dulo fue +implementado y enviado a la lista de correo del kernel de Linux, donde +inmediatamente encontr=C3=B3 problemas. + +Para los desarrolladores de audio, este m=C3=B3dulo de seguridad era sufic= iente +para resolver su problema inmediato. Sin embargo, para la comunidad m=C3= =A1s +amplia del kernel, se ve=C3=ADa como un uso indebido del marco LSM (que no= est=C3=A1 +dise=C3=B1ado para otorgar privilegios a procesos que de otro modo no los +tendr=C3=ADan) y como un riesgo para la estabilidad del sistema. Sus soluc= iones +preferidas implicaban el acceso a la programaci=C3=B3n en tiempo real a tr= av=C3=A9s +del mecanismo de rlimit a corto plazo, y trabajo continuo para reducir la +latencia a largo plazo. + +La comunidad de audio, sin embargo, no pod=C3=ADa ver m=C3=A1s all=C3=A1 d= e la soluci=C3=B3n +particular que hab=C3=ADan implementado; no estaban dispuestos a aceptar +alternativas. El desacuerdo resultante dej=C3=B3 a esos desarrolladores +desilusionados con todo el proceso de desarrollo del kernel; uno de ellos +volvi=C3=B3 a una lista de audio y public=C3=B3 esto (traducido): + + "Hay un buen n=C3=BAmero de desarrolladores muy competentes del kernel de= Linux, pero tienden a ser opacados por una multitud de arrogantes necios. = Intentar comunicar los requisitos de los usuarios a estas personas es una p= =C3=A9rdida de tiempo. Son demasiado 'inteligentes' como para escuchar a si= mples mortales". + +Siendo el texto original: + + There are a number of very good Linux kernel developers, but they + tend to get outshouted by a large crowd of arrogant fools. Trying + to communicate user requirements to these people is a waste of + time. They are much too "intelligent" to listen to lesser mortals. + +(https://lwn.net/Articles/131776/). + +La realidad de la situaci=C3=B3n era diferente; los desarrolladores del ke= rnel +estaban mucho m=C3=A1s preocupados por la estabilidad del sistema, el +mantenimiento a largo plazo y encontrar la soluci=C3=B3n correcta al probl= ema +que por un m=C3=B3dulo espec=C3=ADfico. La moraleja de la historia es cent= rarse en el +problema, no en una soluci=C3=B3n espec=C3=ADfica, y discutirlo con la com= unidad de +desarrollo antes de invertir en la creaci=C3=B3n de un cuerpo de c=C3=B3di= go. + +Por lo tanto, al contemplar un proyecto de desarrollo del kernel, se deben +obtener respuestas a un conjunto corto de preguntas: + +- =C2=BFCu=C3=A1l es exactamente el problema que necesita ser resuelto? + +- =C2=BFQui=C3=A9nes son los usuarios afectados por este problema? =C2=BFQ= u=C3=A9 casos de uso + deber=C3=ADa abordar la soluci=C3=B3n? + +- =C2=BFEn qu=C3=A9 aspectos el kernel actual no logra abordar ese problem= a? + +Solo entonces tiene sentido comenzar a considerar posibles soluciones. + +Discusi=C3=B3n temprana +------------------ + +Al planificar un proyecto de desarrollo del kernel, tiene mucho sentido +realizar discusiones con la comunidad antes de lanzarse a la +implementaci=C3=B3n. La comunicaci=C3=B3n temprana puede ahorrar tiempo y = problemas +de varias maneras: + +- Es posible que el problema ya est=C3=A9 siendo abordado por el kernel de + maneras que no haya comprendido. El kernel de Linux es grande y tiene + una serie de caracter=C3=ADsticas y capacidades que no son inmediatamente + obvias. No todas las capacidades del kernel est=C3=A1n documentadas tan = bien + como uno quisiera, y es f=C3=A1cil pasar cosas por alto. El autor de este + texto ha visto la publicaci=C3=B3n de un driver completo que duplicaba u= no + existente del que el nuevo autor no ten=C3=ADa conocimiento. El c=C3=B3d= igo que + reinventa ruedas existentes no solo es desperdicio; tampoco ser=C3=A1 ac= eptado + en el kernel principal. + +- Puede haber elementos de la soluci=C3=B3n propuesta que no ser=C3=A1n ac= eptables + para su inclusi=C3=B3n en el kernel principal. Es mejor descubrir proble= mas + como este antes de escribir el c=C3=B3digo. + +- Es completamente posible que otros desarrolladores ya hayan pensado en el + problema; pueden tener ideas para una mejor soluci=C3=B3n y estar dispue= stos a + ayudar en la creaci=C3=B3n de esa soluci=C3=B3n. + +A=C3=B1os de experiencia con la comunidad de desarrollo del kernel han ens= e=C3=B1ado +una lecci=C3=B3n clara: el c=C3=B3digo del kernel que se dise=C3=B1a y des= arrolla a +puertas cerradas invariablemente tiene problemas que solo se revelan cuando +el c=C3=B3digo se libera a la comunidad. A veces, estos problemas son grav= es, +requiriendo meses o a=C3=B1os de esfuerzo antes de que el c=C3=B3digo pued= a cumplir +con los est=C3=A1ndares de la comunidad del kernel. Algunos ejemplos inclu= yen: + +- La pila de red Devicescape fue dise=C3=B1ada e implementada para sistema= s de + un solo procesador. No pudo fusionarse en la rama principal hasta que se + hizo adecuada para sistemas multiprocesador. Adaptar el bloqueo y otros + aspectos en el c=C3=B3digo es una tarea dif=C3=ADcil; como resultado, la= fusi=C3=B3n de + este c=C3=B3digo (ahora llamado mac80211) se retras=C3=B3 m=C3=A1s de un= a=C3=B1o. + +- El sistema de archivos Reiser4 inclu=C3=ADa una serie de capacidades que= , en + opini=C3=B3n de los desarrolladores principales del kernel, deber=C3=ADa= n haberse + implementado en la capa de sistemas de archivos virtuales. Tambi=C3=A9n + inclu=C3=ADa funciones que no pod=C3=ADan implementarse f=C3=A1cilmente = sin exponer el + sistema a bloqueos causados por los usuarios. La revelaci=C3=B3n tard=C3= =ADa de + estos problemas, y la negativa a abordar algunos de ellos, ha mantenido a + Reiser4 fuera del kernel principal. + +- El m=C3=B3dulo de seguridad AppArmor hac=C3=ADa uso de estructuras de da= tos + internas del sistema de archivos virtual de maneras que se consideraban + inseguras y poco fiables. Esta preocupaci=C3=B3n (entre otras) mantuvo a + AppArmor fuera de la rama principal durante a=C3=B1os. + +En cada uno de estos casos, se podr=C3=ADa haber evitado mucho dolor y tra= bajo +adicional con algunas discusiones tempranas con los desarrolladores del +kernel. + +=C2=BFCon qui=C3=A9n hablar? +------------------- + +Cuando los desarrolladores deciden hacer p=C3=BAblicas sus ideas, la sigui= ente +pregunta ser=C3=A1: =C2=BFd=C3=B3nde empezar? La respuesta es encontrar la= lista de correo +adecuada y el maintainer correcto. Para las listas de correo, la mejor +opci=C3=B3n es buscar en el archivo MAINTAINERS un lugar relevante para +publicar. Si existe una lista de subsistema adecuada, es preferible +publicarla all=C3=AD en lugar de en linux-kernel; es m=C3=A1s probable que= llegues a +desarrolladores con experiencia en el subsistema relevante y el ambiente +puede ser m=C3=A1s propicio. + +Encontrar a los maintainers puede ser un poco m=C3=A1s dif=C3=ADcil. Nueva= mente, el +archivo MAINTAINERS es el lugar para empezar. Sin embargo, ese archivo +tiende a no estar siempre actualizado, y no todos los subsistemas est=C3= =A1n +representados all=C3=AD. La persona listada en el archivo MAINTAINERS pued= e, de +hecho, no ser la persona que est=C3=A1 actuando en ese rol actualmente. Po= r lo +tanto, cuando haya dudas sobre a qui=C3=A9n contactar, un truco =C3=BAtil = es usar git +(y "git log" en particular) para ver qui=C3=A9n est=C3=A1 activo actualmen= te en el +subsistema de inter=C3=A9s. Mira qui=C3=A9n est=C3=A1 escribiendo parches = y qui=C3=A9n, si +alguien, est=C3=A1 adjuntando l=C3=ADneas de Signed-off-by a esos parches.= Esas son +las personas que estar=C3=A1n mejor posicionadas para ayudar con un nuevo +proyecto de desarrollo. + +La tarea de encontrar al maintainer correcto es lo suficientemente +desafiante como para que los desarrolladores del kernel hayan a=C3=B1adido= un +script para facilitar el proceso: + +:: + + .../scripts/get_maintainer.pl + +Este script devolver=C3=A1 los maintainers actuales de un archivo o direct= orio +dado cuando se le pase la opci=C3=B3n "-f". Si se le pasa un parche en la = l=C3=ADnea +de comandos, listar=C3=A1 a los maintainers que probablemente deber=C3=ADa= n recibir +copias del parche. Esta es la manera preferida (a diferencia de la opci=C3= =B3n +"-f") de obtener la lista de personas a las que hay que enviar las copias +de sus parches. Hay varias opciones que regulan cu=C3=A1n agresivamente +get_maintainer.pl buscar=C3=A1 maintainers; por favor, ten cuidado al usar= las +opciones m=C3=A1s agresivas, ya que podr=C3=ADas terminar incluyendo desar= rolladores +que no tienen ning=C3=BAn inter=C3=A9s real en el c=C3=B3digo que est=C3= =A1s modificando. + +Si todo lo dem=C3=A1s falla, hablar con Andrew Morton puede ser una forma +efectiva de encontrar a un maintainer para un c=C3=B3digo espec=C3=ADfico. + +=C2=BFCu=C3=A1ndo publicar? +------------------ + +Si es posible, publicar sus planes en las primeras etapas solo puede ser +=C3=BAtil. Describa el problema que se est=C3=A1 resolviendo y cualquier p= lan que se +haya hecho sobre c=C3=B3mo se llevar=C3=A1 a cabo la implementaci=C3=B3n. = Cualquier +informaci=C3=B3n que puedas proporcionar puede ayudar a la comunidad de +desarrollo a ofrecer comentarios =C3=BAtiles sobre el proyecto. + +Una cosa desalentadora que puede suceder en esta etapa no es una reacci=C3= =B3n +hostil, sino, en cambio, poca o ninguna reacci=C3=B3n en absoluto. La tris= te +realidad es que (1) los desarrolladores del kernel tienden a estar +ocupados, (2) no hay escasez de personas con grandes planes y poco c=C3=B3= digo +(o incluso perspectivas de c=C3=B3digo) para respaldarlos, y (3) nadie est= =C3=A1 +obligado a revisar o comentar las ideas publicadas por otros. Adem=C3=A1s,= los +dise=C3=B1os de alto nivel a menudo esconden problemas que solo se revelan +cuando alguien realmente intenta implementar esos dise=C3=B1os; por esa ra= z=C3=B3n, +los desarrolladores del kernel prefieren ver el c=C3=B3digo. + +Si una publicaci=C3=B3n de solicitud de comentarios genera pocos comentari= os, no +asuma que significa que no hay inter=C3=A9s en el proyecto. Desafortunadam= ente, +tampoco puedes asumir que no hay problemas con tu idea. Lo mejor que puede +hacer en esta situaci=C3=B3n es seguir adelante, manteniendo informada a +comunidad a medida que avanza. + +Obtener respaldo oficial +------------------------ + +Si su trabajo se est=C3=A1 realizando en un entorno corporativo =E2=80=94 = como ocurre +con la mayor=C3=ADa del trabajo en el kernel de Linux =E2=80=94 es obvio q= ue debe tener +permiso de los jefes debidamente autorizados antes de poder publicar los +planes o el c=C3=B3digo de su empresa en una lista de correo p=C3=BAblica.= La +publicaci=C3=B3n de c=C3=B3digo que no ha sido autorizado para su liberaci= =C3=B3n bajo una +licencia compatible con la GPL puede ser especialmente problem=C3=A1tica; = cuanto +antes la gerencia y el personal legal de una empresa lleguen a un acuerdo +sobre la publicaci=C3=B3n de un proyecto de desarrollo del kernel, mejor s= er=C3=A1 +para todos los involucrados. + +Algunos lectores pueden estar pensando en este momento que su trabajo en el +kernel est=C3=A1 destinado a respaldar un producto que a=C3=BAn no ha sido= reconocido +oficialmente. Revelar los planes de su empleador en una lista de correo +p=C3=BAblica puede no ser una opci=C3=B3n viable. En casos como este, vale= la pena +considerar si realmente es necesario mantener el secreto; a menudo no hay +una necesidad real de mantener los planes de desarrollo en secreto. + +Dicho esto, tambi=C3=A9n hay casos en los que una empresa leg=C3=ADtimamen= te no puede +revelar sus planes al inicio del proceso de desarrollo. Las empresas con +desarrolladores experimentados en el kernel pueden optar por proceder de +manera abierta, bajo el supuesto de que podr=C3=A1n evitar problemas grave= s de +integraci=C3=B3n m=C3=A1s adelante. Para las empresas sin ese tipo de expe= riencia +interna, la mejor opci=C3=B3n suele ser contratar a un desarrollador exter= no +para que revise los planes bajo un acuerdo de confidencialidad (NDA). La +Linux Foundation opera un programa de NDA dise=C3=B1ado para ayudar en est= e tipo +de situaciones; se puede encontrar m=C3=A1s informaci=C3=B3n en: + + https://www.linuxfoundation.org/nda/ + +Este tipo de revisi=C3=B3n suele ser suficiente para evitar problemas grav= es m=C3=A1s +adelante sin necesidad de revelar p=C3=BAblicamente el proyecto. diff --git a/Documentation/translations/sp_SP/process/development-process.r= st b/Documentation/translations/sp_SP/process/development-process.rst index 40d74086f22e..8a967e569772 100644 --- a/Documentation/translations/sp_SP/process/development-process.rst +++ b/Documentation/translations/sp_SP/process/development-process.rst @@ -25,3 +25,4 @@ para entenderla. =20 1.Intro 2.Process + 3.Early-stage --=20 2.43.0 From nobody Sun Dec 14 12:51:50 2025 Received: from mail-ot1-f49.google.com (mail-ot1-f49.google.com [209.85.210.49]) (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 49A4914A4CC; Fri, 29 Nov 2024 15:58:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.49 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732895941; cv=none; b=Lg5A/6EuEEtk65bdERJEDbMkiIF5fMYG27E9SzSUubTa5WpqAtzXFOFIAbBpD7P7IEN88RTlHlkUMYiOXejcpp3IKUXR24XBji+qRMu4bUTY0Cp/efHUQBxZHKyupRM4ffblZcYZQNpRg+UzHzuDICyj52E+L8c6rGmmPFHWfmk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732895941; c=relaxed/simple; bh=FN/kgNPUhuXmSgJzmYJC6RBkOk0pUs0foA9dAASqRcg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=c3YAd6qvYo6VEmmYXrTmIq4vYX/AT8HEvgJ8uMc1ui3uMPvr9bM8IPnhd86IoWeUXvbgmuwBHnE6UzOVKCT1Cl+ngSUXv8U8Ft4oauHhACWhMv4guoViWis1BWR6bPNzEVvHRxyEUqinruxL9Jx3kbOuqx6Z9rcPTl+rlirxNMw= 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=akHnVTSW; arc=none smtp.client-ip=209.85.210.49 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="akHnVTSW" Received: by mail-ot1-f49.google.com with SMTP id 46e09a7af769-71d41932d32so778716a34.0; Fri, 29 Nov 2024 07:58:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1732895938; x=1733500738; 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=5wJIg/sxtDsSUo2Smlt0dgu9NBkc52JfvgQN+3tMwkU=; b=akHnVTSWljKhXZZdq6lri1lti3F0S85yIbKKIjLna99Wjsevy+QZoFgbWWeme//HYw hdsYeDjPTSvHMqNEcGTogNFgO8wNdfgp1r6w8FhDDYfDwCB81udzVUhOAMX2gjPZrOa3 guG3vCBoCWBq9zdeqSGzmy+aVePDpGejB31a1/Y/paVC3vvKDgIChDI5LskYa1JVa1AM GOeTTQGjnDkVIbkMEdb45V0TE9dnWkVOiucRbAG5pYWBjQ2j1nG/icqBppe6PICnJfP+ hKgI86CebZ5a/hTHfVCWzn0/EpJll8GbSTth3lMWlIffxQ89BldzkbvZ6V5Gf+anWwF+ qbrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732895938; x=1733500738; 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=5wJIg/sxtDsSUo2Smlt0dgu9NBkc52JfvgQN+3tMwkU=; b=nBDy1pWTS5BhboFJf3a4LmzeRuJbkedjc46FAhWNgkcwiQ8mpZxXKtrZ7gzZL0phV/ zFMj7rvEfw2/f7HK70I89sU+FMkbiWbIO6GRJ8MkAes/ix9HgVmFKDo0EGxThffjy7Bp XM3o0pMXv9qDIEInHz/7NErT18CUlf8mGG0+t5r871YWcgRLM3MGBsbDkyTlmynfsOuP UrBKqoTzP1p4N9NR6WMWQcOwGumHNgbSOLEinsz7C/oA021N+ouwisG7IU8rTxRfvxZt 1t77Ex7OgbXT1XiZHE0VuHik0IyxWpAa1UtNRrhLHhEKIcJ1jbj9jttEiO1DCI4gVMNR ZNpw== X-Forwarded-Encrypted: i=1; AJvYcCUWhiKwyz3nJGKxbvRI3pFXeVcMeYEw9M/8B2C/pVHyHEXmWCn3bJrCi5tpiYypl7TDv6pQ4yqk/cPhfco=@vger.kernel.org X-Gm-Message-State: AOJu0YzGgdgP3DVPTx+uNBA4zvxbaIBFyRXGmBErkSap4vjFFv2I93d/ sp18+4t7hhdDR+Qb1OBCv3oyaNpzcguWuIhgWxhqwPmX1Ot+IPR4 X-Gm-Gg: ASbGncs4XAvAhvkPOI9sDamonp9MS6SDCNxlOvH3NdxyLa2nVG29fUYjncTam9SDFvi pfU+8Wsxdw3sF3NjASQUgaRdclOljw216pCPwDh5n0JY2fiYoFcAUTIopI0BJfh3kZ/hq+2+6me sJYrYnt1ZEZy1dhea80XS7Qczj9GjfBIUTPickEImVB9zH0icdBgQn21ymqWxTnmhR8xaJSOK2j yIwj3tLhlwIp9bIWxu9s288tNj8yDl6IUC2yKaPaK8DeHWE9KN0D8oXdK7oArU9WdRqQ2xFU5Zh X-Google-Smtp-Source: AGHT+IE2VcF/MSwNHS6hN8HzVuhroZFj9OBsXvwDuziygvANH4/lTvjHkaVRJBLDQdldAtq5y9YW8Q== X-Received: by 2002:a05:6830:349a:b0:71d:53b7:6433 with SMTP id 46e09a7af769-71d65a93f2fmr11541443a34.0.1732895937878; Fri, 29 Nov 2024 07:58:57 -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.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 29 Nov 2024 07:58:57 -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 2/7] docs/sp_SP: Add translation of process/4.Coding.rst Date: Fri, 29 Nov 2024 09:58:42 -0600 Message-ID: <20241129155851.1023884-3-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/4.Coding.rst into Spanish. Co-developed-by: Avadhut Naik Signed-off-by: Avadhut Naik Signed-off-by: Carlos Bilbao --- .../translations/sp_SP/process/4.Coding.rst | 463 +++++++++++++++++- .../sp_SP/process/development-process.rst | 1 + 2 files changed, 462 insertions(+), 2 deletions(-) diff --git a/Documentation/translations/sp_SP/process/4.Coding.rst b/Docume= ntation/translations/sp_SP/process/4.Coding.rst index d9436e039b4b..7cc347c34354 100644 --- a/Documentation/translations/sp_SP/process/4.Coding.rst +++ b/Documentation/translations/sp_SP/process/4.Coding.rst @@ -1,11 +1,470 @@ .. include:: ../disclaimer-sp.rst =20 :Original: Documentation/process/4.Coding.rst +:Translator: Carlos Bilbao and Avadhut Nai= k =20 .. _sp_development_coding: =20 Conseguir el c=C3=B3digo correcto =3D=3D=3D=3D=3D=3D=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 +Si bien hay mucho que decir a favor de un proceso de dise=C3=B1o s=C3=B3li= do y +orientado a la comunidad, la prueba de cualquier proyecto de desarrollo del +kernel est=C3=A1 en el c=C3=B3digo resultante. Es el c=C3=B3digo lo que se= r=C3=A1 examinado por +otros desarrolladores y lo que ser=C3=A1 incluido (o no) en el =C3=A1rbol = principal. +Por lo tanto, es la calidad de este c=C3=B3digo lo que determinar=C3=A1 el= =C3=A9xito +final del proyecto. + +Esta secci=C3=B3n examinar=C3=A1 el proceso de programaci=C3=B3n. Comenzar= emos observando +algunas de las maneras en que los desarrolladores del kernel pueden cometer +errores. Luego, el enfoque se dirigir=C3=A1 hacia hacer las cosas bien y l= as +herramientas que pueden ayudar en dicha b=C3=BAsqueda. + +Problemas +--------- + +Estilo de programaci=C3=B3n +********************** + +El kernel ha tenido durante mucho tiempo un estilo de programaci=C3=B3n +est=C3=A1ndar, descrito en la documentaci=C3=B3n del kernel en +`Documentation/process/coding-style.rst`. Durante gran parte de ese tiempo, +las pol=C3=ADticas descritas en ese archivo se tomaban como, en el mejor d= e los +casos, orientativas. Como resultado, hay una cantidad considerable de +c=C3=B3digo en el kernel que no cumple con las pautas de estilo de program= aci=C3=B3n. +La presencia de ese c=C3=B3digo lleva a dos peligros independientes para l= os +desarrolladores del kernel. + +El primero de estos es creer que los est=C3=A1ndares de programaci=C3=B3n = del kernel +no importan y no se aplican. La realidad es que agregar nuevo c=C3=B3digo = al +kernel es muy dif=C3=ADcil si ese c=C3=B3digo no est=C3=A1 escrito de acue= rdo con el +est=C3=A1ndar; muchos desarrolladores solicitar=C3=A1n que el c=C3=B3digo = sea reformateado +antes de revisarlo. Una base de c=C3=B3digo tan grande como el kernel requ= iere +cierta uniformidad para que los desarrolladores puedan comprender +r=C3=A1pidamente cualquier parte de =C3=A9l. As=C3=AD que ya no hay lugar = para el c=C3=B3digo +con formato extra=C3=B1o. + +Ocasionalmente, el estilo de programaci=C3=B3n del kernel entrar=C3=A1 en = conflicto +con el estilo obligatorio de un empleador. En tales casos, el estilo del +kernel tendr=C3=A1 que prevalecer antes de que el c=C3=B3digo pueda ser fu= sionado. +Incluir c=C3=B3digo en el kernel significa renunciar a cierto grado de con= trol +de varias maneras, incluida la forma en que se formatea el c=C3=B3digo. + +La otra trampa es asumir que el c=C3=B3digo que ya est=C3=A1 en el kernel = necesita +urgentemente correcciones de estilo de programaci=C3=B3n. Los desarrollado= res +pueden comenzar a generar parches de reformateo como una forma de +familiarizarse con el proceso o como una forma de incluir su nombre en los +registros de cambios del kernel, o ambos. Pero las correcciones puramente +de estilo de programaci=C3=B3n son vistas como ruido por la comunidad de +desarrollo; tienden a recibir una recepci=C3=B3n adversa. Por lo tanto, es= te +tipo de parche es mejor evitarlo. Es natural corregir el estilo de una +parte del c=C3=B3digo mientras se trabaja en =C3=A9l por otras razones, pe= ro los +cambios de estilo de programaci=C3=B3n no deben hacerse por s=C3=AD mismos. + +El documento de estilo de programaci=C3=B3n tampoco debe leerse como una l= ey +absoluta que nunca puede transgredirse. Si hay una buena raz=C3=B3n para i= r en +contra del estilo (una l=C3=ADnea que se vuelve mucho menos legible si se = divide +para ajustarse al l=C3=ADmite de 80 columnas, por ejemplo), perfecto. + +Tenga en cuenta que tambi=C3=A9n puedes usar la herramienta `clang-format`= para +ayudarle con estas reglas, para reformatear r=C3=A1pidamente partes de su = c=C3=B3digo +autom=C3=A1ticamente y para revisar archivos completos a fin de detectar e= rrores +de estilo de programaci=C3=B3n, errores tipogr=C3=A1ficos y posibles mejor= as. Tambi=C3=A9n +es =C3=BAtil para ordenar `#includes`, alinear variables/macros, reformate= ar +texto y otras tareas similares. Consulte el archivo +`Documentation/dev-tools/clang-format.rst` para m=C3=A1s detalles. + +Algunas configuraciones b=C3=A1sicas del editor, como la indentaci=C3=B3n = y los +finales de l=C3=ADnea, se configurar=C3=A1n autom=C3=A1ticamente si utiliz= as un editor +compatible con EditorConfig. Consulte el sitio web oficial de EditorConfig +para obtener m=C3=A1s informaci=C3=B3n: https://editorconfig.org/ + +Capas de abstracci=C3=B3n +******************** + +Los profesores de ciencias de la computaci=C3=B3n ense=C3=B1an a los estud= iantes a +hacer un uso extensivo de capas de abstracci=C3=B3n en nombre de la +flexibilidad y el ocultamiento de la informaci=C3=B3n. Sin duda, el kernel= hace +un uso extensivo de la abstracci=C3=B3n; ning=C3=BAn proyecto que involucr= e varios +millones de l=C3=ADneas de c=C3=B3digo podr=C3=ADa sobrevivir de otra mane= ra. Pero la +experiencia ha demostrado que una abstracci=C3=B3n excesiva o prematura pu= ede +ser tan perjudicial como la optimizaci=C3=B3n prematura. La abstracci=C3= =B3n debe +usarse en la medida necesaria y ya. + +A un nivel simple, considere una funci=C3=B3n que tiene un argumento que s= iempre +se pasa como cero por todos los que la invocan. Uno podr=C3=ADa mantener e= se +argumento por si alguien eventualmente necesita usar la flexibilidad +adicional que proporciona. Sin embargo, para entonces, es probable que el +c=C3=B3digo que implementa este argumento adicional se haya roto de alguna +manera sutil que nunca se not=C3=B3, porque nunca se ha utilizado. O, cuan= do +surge la necesidad de flexibilidad adicional, no lo hace de una manera que +coincida con la expectativa temprana del programador. Los desarrolladores +del kernel rutinariamente enviar=C3=A1n parches para eliminar argumentos no +utilizados; en general, no deber=C3=ADan a=C3=B1adirse en primer lugar. + +Las capas de abstracci=C3=B3n que ocultan el acceso al hardware, a menudo = para +permitir que la mayor parte de un controlador se utilice con varios +sistemas operativos, son especialmente mal vistas. Dichas capas oscurecen +el c=C3=B3digo y pueden imponer una penalizaci=C3=B3n en el rendimiento; no +pertenecen al kernel de Linux. + +Por otro lado, si se encuentra copiando cantidades significativas de c=C3= =B3digo +de otro subsistema del kernel, es hora de preguntar si, de hecho, tendr=C3= =ADa +sentido extraer parte de ese c=C3=B3digo en una biblioteca separada o +implementar esa funcionalidad a un nivel superior. No tiene sentido +replicar el mismo c=C3=B3digo en todo el kernel. + +Uso de #ifdef y del preprocesador en general +******************************************** + +El preprocesador de C tiene una tentaci=C3=B3n poderosa para algunos +programadores de C, quienes lo ven como una forma de programar +eficientemente una gran cantidad de flexibilidad en un archivo fuente. Pero +el preprocesador no es C, y el uso intensivo de =C3=A9l da como resultado = un +c=C3=B3digo mucho m=C3=A1s dif=C3=ADcil de leer para otros y m=C3=A1s dif= =C3=ADcil de verificar por +el compilador para su correcci=C3=B3n. El uso intensivo del preprocesador = es +asi siempre un signo de un c=C3=B3digo que necesita algo de limpieza. + +La compilaci=C3=B3n condicional con `#ifdef` es, de hecho, una caracter=C3= =ADstica +poderosa, y se usa dentro del kernel. Pero hay poco deseo de ver c=C3=B3di= go que +st=C3=A9 salpicado liberalmente con bloques `#ifdef`. Como regla general, = el uso +de `#ifdef` debe limitarse a los archivos de encabezado siempre que sea +posible. El c=C3=B3digo condicionalmente compilado puede confinarse a func= iones +que, si el c=C3=B3digo no va a estar presente, simplemente se convierten en +vac=C3=ADas. El compilador luego optimizar=C3=A1 silenciosamente la llamad= a a la +funci=C3=B3n vac=C3=ADa. El resultado es un c=C3=B3digo mucho m=C3=A1s lim= pio y f=C3=A1cil de +seguir. + +Las macros del preprocesador de C presentan varios peligros, incluida la +posible evaluaci=C3=B3n m=C3=BAltiple de expresiones con efectos secundari= os y la +falta de seguridad de tipos. Si te sientes tentado a definir una macro, +considera crear una funci=C3=B3n en l=C3=ADnea en su lugar. El c=C3=B3digo= resultante ser=C3=A1 +el mismo, pero las funciones en l=C3=ADnea son m=C3=A1s f=C3=A1ciles de le= er, no eval=C3=BAan +sus argumentos varias veces y permiten que el compilador realice +comprobaciones de tipo en los argumentos y el valor de retorno. + +Funciones en l=C3=ADnea +****************** + +Las funciones en l=C3=ADnea presentan su propio peligro, sin embargo. Los +programadores pueden enamorarse de la eficiencia percibida al evitar una +llamada a funci=C3=B3n y llenar un archivo fuente con funciones en l=C3=AD= nea. Esas +funciones, sin embargo, pueden en realidad reducir el rendimiento. Dado que +su c=C3=B3digo se replica en cada sitio de llamada, terminan hinchando el = tama=C3=B1o +del kernel compilado. Eso, a su vez, crea presi=C3=B3n en las cach=C3=A9s = de memoria +del procesador, lo que puede ralentizar la ejecuci=C3=B3n de manera dr=C3= =A1stica +Las funciones en l=C3=ADnea, como regla, deben ser bastante peque=C3=B1as y +relativamente raras. El costo de una llamada a funci=C3=B3n, despu=C3=A9s = de todo, no +es tan alto; la creaci=C3=B3n de un gran n=C3=BAmero de funciones en l=C3= =ADnea es un +ejemplo cl=C3=A1sico de optimizaci=C3=B3n prematura. + +En general, los programadores del kernel ignoran los efectos de cach=C3=A9= bajo +su propio riesgo. El cl=C3=A1sico intercambio de tiempo/espacio que se ens= e=C3=B1a en +las clases de estructuras de datos iniciales a menudo no se aplica al +hardware contempor=C3=A1neo. El espacio *es* tiempo, en el sentido de que = un +programa m=C3=A1s grande se ejecutar=C3=A1 m=C3=A1s lentamente que uno m= =C3=A1s compacto. + +Los compiladores m=C3=A1s recientes toman un papel cada vez m=C3=A1s activ= o al +decidir si una funci=C3=B3n dada debe realmente ser en l=C3=ADnea o no. Po= r lo tanto, +la colocaci=C3=B3n liberal de palabras clave "inline" puede no solo ser +excesiva; tambi=C3=A9n podr=C3=ADa ser irrelevante. + +Bloqueo +******* + +En mayo de 2006, la pila de red "Devicescape" fue, con gran fanfarria, +lanzada bajo la licencia GPL y puesta a disposici=C3=B3n para su inclusi= =C3=B3n en el +kernel principal. Esta donaci=C3=B3n fue una noticia bienvenida; el soport= e para +redes inal=C3=A1mbricas en Linux se consideraba, en el mejor de los casos, +deficiente, y la pila de Devicescape ofrec=C3=ADa la promesa de solucionar= esa +situaci=C3=B3n. Sin embargo, este c=C3=B3digo no fue incluido en el kernel= principal +hasta junio de 2007 (versi=C3=B3n 2.6.22). =C2=BFQu=C3=A9 sucedi=C3=B3? + +Este c=C3=B3digo mostr=C3=B3 varios signos de haber sido desarrollado a pu= ertas +cerradas en una empresa. Pero un problema importante en particular fue que +no estaba dise=C3=B1ado para funcionar en sistemas multiprocesador. Antes = de que +esta pila de red (ahora llamada mac80211) pudiera fusionarse, se tuvo que +implementar un esquema de bloqueo en ella. + +Hubo un tiempo en que se pod=C3=ADa desarrollar c=C3=B3digo para el kernel= de Linux +sin pensar en los problemas de concurrencia que presentan los sistemas +multiprocesador. Ahora, sin embargo, este documento se est=C3=A1 escribien= do en +una computadora port=C3=A1til con dos n=C3=BAcleos. Incluso en sistemas de= un solo +procesador, el trabajo que se est=C3=A1 realizando para mejorar la capacid= ad de +respuesta aumentar=C3=A1 el nivel de concurrencia dentro del kernel. Los d= =C3=ADas en +que se pod=C3=ADa escribir c=C3=B3digo para el kernel sin pensar en el blo= queo han +quedado atr=C3=A1s. + +Cualquier recurso (estructuras de datos, registros de hardware, etc.) que +pueda ser accedido concurrentemente por m=C3=A1s de un hilo debe estar pro= tegido +por un bloqueo. El nuevo c=C3=B3digo debe escribirse teniendo en cuenta es= te +requisito; implementar el bloqueo despu=C3=A9s de que el c=C3=B3digo ya ha= sido +desarrollado es una tarea mucho m=C3=A1s dif=C3=ADcil. Los desarrolladores= del kernel +deben tomarse el tiempo para comprender bien los primitivos de bloqueo +disponibles para elegir la herramienta adecuada para el trabajo. El c=C3= =B3digo +que muestre una falta de atenci=C3=B3n a la concurrencia tendr=C3=A1 un ca= mino +dif=C3=ADcil para ser incluido en el kernel principal. + +Regresiones +*********** + +Un =C3=BAltimo peligro que vale la pena mencionar es el siguiente: puede s= er +tentador realizar un cambio (que puede traer grandes mejoras) que cause un +problema para los usuarios existentes. Este tipo de cambio se llama una +"regresi=C3=B3n", y las regresiones se han vuelto muy mal recibidas en el = kernel +principal. Con pocas excepciones, los cambios que causan regresiones ser= =C3=A1n +revertidos si la regresi=C3=B3n no se puede solucionar de manera oportuna.= Es +mucho mejor evitar la regresi=C3=B3n desde el principio. + +A menudo se argumenta que una regresi=C3=B3n puede justificarse si hace qu= e las +cosas funcionen para m=C3=A1s personas de las que crea problemas. =C2=BFPo= r qu=C3=A9 no +hacer un cambio si trae nueva funcionalidad a diez sistemas por cada uno +que rompe? La mejor respuesta a esta pregunta fue expresada por Linus en +julio de 2007 (traducido): + +:: + + Entonces, no arreglamos errores introduciendo nuevos problemas. Eso + lleva a la locura, y nadie sabe si realmente se avanza. =C2=BFEs dos pasos + adelante, uno atr=C3=A1s, o un paso adelante y dos atr=C3=A1s? + +(https://lwn.net/Articles/243460/). + +Un tipo de regresi=C3=B3n especialmente mal recibido es cualquier tipo de = cambio +en la ABI del espacio de usuario. Una vez que se ha exportado una interfaz +al espacio de usuario, debe ser soportada indefinidamente. Este hecho hace +que la creaci=C3=B3n de interfaces para el espacio de usuario sea +particularmente desafiante: dado que no pueden cambiarse de manera +incompatible, deben hacerse bien desde el principio. Por esta raz=C3=B3n, +siempre se requiere una gran cantidad de reflexi=C3=B3n, documentaci=C3=B3= n clara y +una amplia revisi=C3=B3n para las interfaces del espacio de usuario. + +Herramientas de verificaci=C3=B3n de c=C3=B3digo +************************************** + +Por ahora, al menos, escribir c=C3=B3digo libre de errores sigue siendo un= ideal +que pocos de nosotros podemos alcanzar. Sin embargo, lo que podemos esperar +hacer es detectar y corregir tantos de esos errores como sea posible antes +de que nuestro c=C3=B3digo se integre en el kernel principal. Con ese fin,= los +desarrolladores del kernel han reunido una impresionante variedad de +herramientas que pueden detectar una amplia variedad de problemas oscuros +de manera automatizada. Cualquier problema detectado por el ordenador es +un problema que no afectar=C3=A1 a un usuario m=C3=A1s adelante, por lo qu= e es l=C3=B3gico +que las herramientas automatizadas se utilicen siempre que sea posible. + +El primer paso es simplemente prestar atenci=C3=B3n a las advertencias +producidas por el compilador. Las versiones contempor=C3=A1neas de gcc pue= den +detectar (y advertir sobre) una gran cantidad de errores potenciales. Con +bastante frecuencia, estas advertencias apuntan a problemas reales. El +c=C3=B3digo enviado para revisi=C3=B3n no deber=C3=ADa, por regla general,= producir +ninguna advertencia del compilador. Al silenciar las advertencias, tenga +cuidado de comprender la causa real e intente evitar "correcciones" que +hagan desaparecer la advertencia sin abordar su causa. + +Tenga en cuenta que no todas las advertencias del compilador est=C3=A1n +habilitadas de forma predeterminada. Compile el kernel con +"make KCFLAGS=3D-W" para obtener el conjunto completo. + +El kernel proporciona varias opciones de configuraci=C3=B3n que activan +funciones de depuraci=C3=B3n; la mayor=C3=ADa de estas se encuentran en el= submen=C3=BA +"kernel hacking". Varias de estas opciones deben estar activadas para +cualquier kernel utilizado para desarrollo o pruebas. En particular, +deber=C3=ADa activar: + + - FRAME_WARN para obtener advertencias sobre marcos de pila m=C3=A1s gran= des + que una cantidad determinada. La salida generada puede ser extensa, pero + no es necesario preocuparse por las advertencias de otras partes del + kernel. + + - DEBUG_OBJECTS agregar=C3=A1 c=C3=B3digo para rastrear la vida =C3=BAtil= de varios + objetos creados por el kernel y advertir cuando se realicen cosas fuera + de orden. Si est=C3=A1 agregando un subsistema que crea (y exporta) obj= etos + complejos propios, considere agregar soporte para la infraestructura de + depuraci=C3=B3n de objetos. + + - DEBUG_SLAB puede encontrar una variedad de errores en la asignaci=C3=B3= n y + uso de memoria; debe usarse en la mayor=C3=ADa de los kernels de desarr= ollo. + + - DEBUG_SPINLOCK, DEBUG_ATOMIC_SLEEP y DEBUG_MUTEXES encontrar=C3=A1n una= serie + de errores comunes de bloqueo. + +Hay bastantes otras opciones de depuraci=C3=B3n, algunas de las cuales se +discutir=C3=A1n m=C3=A1s adelante. Algunas de ellas tienen un impacto sign= ificativo +en el rendimiento y no deben usarse todo el tiempo. Pero dedicar tiempo a +aprender las opciones disponibles probablemente ser=C3=A1 recompensado muc= has +veces en poco tiempo. + +Una de las herramientas de depuraci=C3=B3n m=C3=A1s pesadas es el verifica= dor de +bloqueos, o "lockdep". Esta herramienta rastrear=C3=A1 la adquisici=C3=B3n= y +liberaci=C3=B3n de cada bloqueo (spinlock o mutex) en el sistema, el orden= en +que se adquieren los bloqueos en relaci=C3=B3n entre s=C3=AD, el entorno a= ctual de +interrupci=C3=B3n, y m=C3=A1s. Luego, puede asegurarse de que los bloqueos= siempre se +adquieran en el mismo orden, que las mismas suposiciones de interrupci=C3= =B3n se +apliquen en todas las situaciones, y as=C3=AD sucesivamente. En otras pala= bras, +lockdep puede encontrar varios escenarios en los que el sistema podr=C3=AD= a, en +raras ocasiones, bloquearse. Este tipo de problema puede ser doloroso +(tanto para desarrolladores como para usuarios) en un sistema desplegado; +lockdep permite encontrarlos de manera automatizada con anticipaci=C3=B3n.= El +c=C3=B3digo con cualquier tipo de bloqueo no trivial debe ejecutarse con l= ockdep +habilitado antes de ser enviado para su inclusi=C3=B3n. + +Como programador diligente del kernel, sin duda alguna, verificar=C3=A1 el +estado de retorno de cualquier operaci=C3=B3n (como una asignaci=C3=B3n de= memoria) +que pueda fallar. Sin embargo, el hecho es que las rutas de recuperaci=C3= =B3n de +fallos resultantes probablemente no hayan sido probadas en absoluto. El +c=C3=B3digo no probado tiende a ser c=C3=B3digo roto; podr=C3=ADa tener mu= cha m=C3=A1s +confianza en su c=C3=B3digo si todas esas rutas de manejo de errores se hu= bieran +ejercitado algunas veces. + +El kernel proporciona un marco de inyecci=C3=B3n de fallos que puede hacer +precisamente eso, especialmente donde est=C3=A1n involucradas las asignaci= ones +de memoria. Con la inyecci=C3=B3n de fallos habilitada, un porcentaje +configurable de las asignaciones de memoria fallar=C3=A1n; estas fallas pu= eden +restringirse a un rango espec=C3=ADfico de c=C3=B3digo. Ejecutar con la in= yecci=C3=B3n de +fallos habilitada permite al programador ver c=C3=B3mo responde el c=C3=B3= digo cuando +las cosas van mal. Consulte +Documentation/fault-injection/fault-injection.rst para obtener m=C3=A1s +informaci=C3=B3n sobre c=C3=B3mo utilizar esta funcionalidad. + +Otros tipos de errores se pueden encontrar con la herramienta de an=C3=A1l= isis +est=C3=A1tico "sparse". Con sparse, el programador puede recibir advertenc= ias +sobre confusiones entre direcciones del espacio de usuario y del kernel, +mezcla de cantidades big-endian y little-endian, el paso de valores enteros +donde se espera un conjunto de banderas de bits, y as=C3=AD sucesivamente. +Sparse debe instalarse por separado (puede encontrarse en +https://sparse.wiki.kernel.org/index.php/Main_Page si su distribuci=C3=B3n= no lo +empaqueta); luego, puede ejecutarse en el c=C3=B3digo agregando "C=3D1" a = su +comando make. + +La herramienta "Coccinelle" (http://coccinelle.lip6.fr/) puede encontrar +una amplia variedad de posibles problemas de codificaci=C3=B3n; tambi=C3= =A9n puede +proponer correcciones para esos problemas. Bastantes "parches sem=C3=A1nti= cos" +para el kernel se han empaquetado en el directorio scripts/coccinelle; +ejecutar "make coccicheck" ejecutar=C3=A1 esos parches sem=C3=A1nticos e i= nformar=C3=A1 +sobre cualquier problema encontrado. Consulte: +ref:`Documentation/dev-tools/coccinelle.rst ` para +obtener m=C3=A1s informaci=C3=B3n. + +Otros tipos de errores de portabilidad se encuentran mejor compilando su +c=C3=B3digo para otras arquitecturas. Si no tiene un sistema S/390 o una p= laca +de desarrollo Blackfin a mano, a=C3=BAn puede realizar el paso de compilac= i=C3=B3n. +Un gran conjunto de compiladores cruzados para sistemas x86 se puede +encontrar en + + https://www.kernel.org/pub/tools/crosstool/ + +Muchos sistemas de compilaci=C3=B3n disponibles comercialmente tambi=C3=A9= n se pueden +utilizar para compilar c=C3=B3digo de kernel para una amplia gama de +arquitecturas. + +Los desarrolladores del kernel son afortunados: tienen acceso a una +variedad de herramientas de verificaci=C3=B3n de c=C3=B3digo de la que los +desarrolladores de la mayor=C3=ADa de los otros sistemas pueden estar celo= sos. +Pero todas esas herramientas no servir=C3=A1n de nada si no las usa. El +resultado final de ignorar estas herramientas es simple: alguien m=C3=A1s = puede +notificarle de un problema en su c=C3=B3digo a trav=C3=A9s de un "oportuno" +comentario en la lista de correo o, peor a=C3=BAn, el c=C3=B3digo problem= =C3=A1tico podr=C3=ADa +ser eliminado. Es mucho m=C3=A1s f=C3=A1cil usar estas herramientas en pri= mer lugar. + +Documentaci=C3=B3n +************* + +La documentaci=C3=B3n a menudo ha sido m=C3=A1s la excepci=C3=B3n que la r= egla en el +desarrollo del kernel. Aun as=C3=AD, una documentaci=C3=B3n adecuada ayuda= r=C3=A1 a +facilitar la integraci=C3=B3n de nuevo c=C3=B3digo en el kernel, har=C3=A1= la vida m=C3=A1s +f=C3=A1cil a otros desarrolladores, y ser=C3=A1 =C3=BAtil para sus usuario= s. En muchos +casos, la inclusi=C3=B3n de documentaci=C3=B3n se ha vuelto esencialmente +obligatoria. + +La primera pieza de documentaci=C3=B3n para cualquier parche es su changel= og +asociado. Las entradas de registro deben describir el problema que se est= =C3=A1 +esolviendo, la forma de la soluci=C3=B3n, las personas que trabajaron en el +parche, cualquier efecto relevante en el rendimiento, y cualquier otra cosa +que pueda ser necesaria para entender el parche. Aseg=C3=BArese de que el +changelog diga *por qu=C3=A9* el parche vale la pena ser aplicado; un +sorprendente n=C3=BAmero de desarrolladores no proporciona esa informaci= =C3=B3n. + +Cualquier c=C3=B3digo que agregue una nueva interfaz para el espacio de us= uario, +incluidos los nuevos archivos de sysfs o /proc, debe incluir documentaci= =C3=B3n +de esa interfaz que permita a los desarrolladores del espacio de usuario +saber con qu=C3=A9 est=C3=A1n trabajando. Consulte `Documentation/ABI/READ= ME` para +una descripci=C3=B3n de c=C3=B3mo debe formatearse esta documentaci=C3=B3n= y qu=C3=A9 +informaci=C3=B3n debe proporcionarse. + +El archivo +:ref:`Documentation/admin-guide/kernel-parameters.rst ` +describe todos los par=C3=A1metros de arranque del kernel. Cualquier parch= e que +agregue nuevos par=C3=A1metros debe agregar las entradas correspondientes = a este +archivo. + +Cualquier nueva opci=C3=B3n de configuraci=C3=B3n debe ir acompa=C3=B1ada = de un texto de +ayuda que explique claramente las opciones y cu=C3=A1ndo el usuario podr= =C3=ADa +querer seleccionarlas. + +La informaci=C3=B3n de la API interna para muchos subsistemas est=C3=A1 do= cumentada +mediante comentarios especialmente formateados; estos comentarios pueden +extraerse y formatearse de diversas maneras mediante el script +"kernel-doc". Si est=C3=A1 trabajando dentro de un subsistema que tiene +comentarios de kerneldoc, debe mantenerlos y agregarlos seg=C3=BAn corresp= onda +para las funciones disponibles externamente. Incluso en =C3=A1reas que no = han +sido tan documentadas, no hay ning=C3=BAn inconveniente en agregar comenta= rios +de kerneldoc para el futuro; de hecho, esta puede ser una actividad =C3=BA= til +para desarrolladores de kernel principiantes. El formato de estos +comentarios, junto con alguna informaci=C3=B3n sobre c=C3=B3mo crear plant= illas de +kerneldoc, se puede encontrar en +:ref:`Documentation/doc-guide/ `. + +Cualquiera que lea una cantidad significativa de c=C3=B3digo existente del +kernel notar=C3=A1 que, a menudo, los comentarios son notables por su ause= ncia. +Una vez m=C3=A1s, las expectativas para el nuevo c=C3=B3digo son m=C3=A1s = altas que en el +pasado; integrar c=C3=B3digo sin comentarios ser=C3=A1 m=C3=A1s dif=C3=ADc= il. Dicho esto, hay +poco deseo de tener c=C3=B3digo excesivamente comentado. El c=C3=B3digo en= s=C3=AD debe +ser legible, con comentarios que expliquen los aspectos m=C3=A1s sutiles. + +Ciertas cosas siempre deben comentarse. El uso de barreras de memoria debe +ir acompa=C3=B1ado de una l=C3=ADnea que explique por qu=C3=A9 la barrera = es necesaria. +Las reglas de bloqueo para las estructuras de datos generalmente necesitan +explicarse en alg=C3=BAn lugar. Las estructuras de datos importantes en ge= neral +necesitan documentaci=C3=B3n completa. Las dependencias no obvias entre +fragmentos de c=C3=B3digo separados deben se=C3=B1alarse. Cualquier cosa q= ue pueda +tentar a un maintainer de c=C3=B3digo a hacer una "limpieza" incorrecta ne= cesita +un comentario que explique por qu=C3=A9 se hace de esa manera. Y as=C3=AD +sucesivamente. + +Cambios en la API interna +************************* + +La interfaz binaria proporcionada por el kernel al espacio de usuario no se +puede romper, excepto en las circunstancias m=C3=A1s graves. Las interface= s de +programaci=C3=B3n internas del kernel, en cambio, son altamente fluidas y = pueden +cambiarse cuando surge la necesidad. Si usted se encuentra teniendo que +hacer un rodeo alrededor de una API del kernel, o simplemente no utilizando +una funcionalidad espec=C3=ADfica porque no cumple con sus necesidades, eso +puede ser una se=C3=B1al de que la API necesita cambiar. Como desarrollado= r del +kernel, usted est=C3=A1 autorizado a hacer esos cambios. + +Hay, por supuesto, algunas condiciones. Los cambios en la API se pueden +hacer, pero necesitan estar bien justificados. Entonces, cualquier parche +que realice un cambio en la API interna debe ir acompa=C3=B1ado de una +descripci=C3=B3n de cu=C3=A1l es el cambio y por qu=C3=A9 es necesario. Es= te tipo de +cambio tambi=C3=A9n debe desglosarse en un parche separado, en lugar de es= tar +enterrado dentro de un parche m=C3=A1s grande. + +La otra condici=C3=B3n es que un desarrollador que cambia una API interna +generalmente est=C3=A1 encargado de la tarea de corregir cualquier c=C3=B3= digo dentro +del =C3=A1rbol del kernel que se vea afectado por el cambio. Para una func= i=C3=B3n +ampliamente utilizada, este deber puede llevar a literalmente cientos o +miles de cambios, muchos de los cuales probablemente entren en conflicto +con el trabajo que otros desarrolladores est=C3=A1n realizando. No hace fa= lta +decir que esto puede ser un trabajo grande, por lo que es mejor asegurarse +de que la justificaci=C3=B3n sea s=C3=B3lida. Tenga en cuenta que la herra= mienta +Coccinelle puede ayudar con los cambios de API a gran escala. + +Cuando se realice un cambio incompatible en la API, siempre que sea +posible, se debe asegurar que el c=C3=B3digo que no ha sido actualizado sea +detectado por el compilador. Esto le ayudar=C3=A1 a estar seguro de que ha +encontrado todos los usos en el =C3=A1rbol de esa interfaz. Tambi=C3=A9n a= lertar=C3=A1 a +los desarrolladores de c=C3=B3digo fuera del =C3=A1rbol de que hay un camb= io al que +necesitan responder. Apoyar el c=C3=B3digo fuera del =C3=A1rbol no es algo= de lo que +los desarrolladores del kernel deban preocuparse, pero tampoco tenemos que +dificultarles la vida m=C3=A1s de lo necesario. diff --git a/Documentation/translations/sp_SP/process/development-process.r= st b/Documentation/translations/sp_SP/process/development-process.rst index 8a967e569772..62ee4b2e109e 100644 --- a/Documentation/translations/sp_SP/process/development-process.rst +++ b/Documentation/translations/sp_SP/process/development-process.rst @@ -26,3 +26,4 @@ para entenderla. 1.Intro 2.Process 3.Early-stage + 4.Coding --=20 2.43.0 From nobody Sun Dec 14 12:51:50 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 From nobody Sun Dec 14 12:51:50 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 From nobody Sun Dec 14 12:51:50 2025 Received: from mail-oo1-f41.google.com (mail-oo1-f41.google.com [209.85.161.41]) (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 5241819CC1C; Fri, 29 Nov 2024 15:59:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.161.41 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732895945; cv=none; b=T1eMMNjbEhYe27w1c/p/ON8xyTdr59tCy5J78OY2TFu/9U6ssmL3t6etO+pqLZbgQzhV6rzO6aKWV1UE8JR45OgCLWeC2FUGvHR9zXKGgzbp8wVUXIAge6s3D9rhpEK0PYmvYl2RgRm2n7ZUrB5tMNxeta2FORTDo4gQIM9YoUE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732895945; c=relaxed/simple; bh=tjg83BcvLm72RhXJ8aW40wzUz9Z+AXKuF8XiSPp7iRo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=NOUdxm4T43M3kw8heJQ1zRIm7lQYuo66YTsQBB83V0f4CHjra3iKBNzgvxbJ1RBZDQ1V9AQdOYp80yvNgt0AE909wnHYw6wpjGrWbzGdKHNKHlKZZmsd84uwF2oqPsH/x+jPRNKZlpzDf1PhJVO1Raf/KqSVt3r5pVaO9u1RtrE= 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=LNAKcAA4; arc=none smtp.client-ip=209.85.161.41 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="LNAKcAA4" Received: by mail-oo1-f41.google.com with SMTP id 006d021491bc7-5f1d2487b95so711725eaf.0; Fri, 29 Nov 2024 07:59:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1732895942; x=1733500742; 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=kxstQK7lyLA1KAwlanh+JmMhzwB3UYAIFtRwg9zsVYQ=; b=LNAKcAA4Q8Vs8GTHJb/i8fkF5jDLyO+odBzMnOSYViRYWM9hX3fAWJ6QEBevturULd gAlou/LpkIp/surOsqcTqYS+pzJtLVU+WbHMKzMz3/0zfFM/iDZo0NiUCl+RWn2cdR+9 VDyMTGaf2pC1q4RAwyM1Ofw6+hwWfsXZ4dUz5vkmKEO7+M+dTd8/3rkNiaQ2U6o2L1j8 T99vtOTSVQ0CdwgR5kjcSlErebKFUGSwJOvqHwqS5oOdL3gWSGAmVlPlo4kYchw90FDN 6XJRlerBflc6VM06EgbYgiacesUDUma3DMQBEiwfXcTB5nnvymeh6rDC5GCeNIjsQhte R7Mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732895942; x=1733500742; 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=kxstQK7lyLA1KAwlanh+JmMhzwB3UYAIFtRwg9zsVYQ=; b=oA4M5k3oQ666Xe5Xyd4p1AoAe7nRpRnPR3MGjxtvHtHOugICKi2iNSGxIpt8x9bfW5 ZGFFnO66deRaKFQAe/9OELAPWSM467QmMOxb4uh3qblbfQyhfy1o9ETLpiPqDqyrR9n6 doRqNglVldM80Zi6ZhTdvGxsK3mlyOZk/vpnK1vUWy2dhgYscMHbXrK407Uo6ExwLdEj gsv0WOVFWtqN2dj3CxapWNXZq/+dyQR4y63tad0zSgPk97bvoSd661Kks/rjcFENGY4G qXFPc6soxASSeiLRhoig3KKjI/Q/sWKEqXihZKKw7mh2N/I3B6wEPSd8N49sxYvoNyX3 ro1Q== X-Forwarded-Encrypted: i=1; AJvYcCXSfwg4d1+LxdbffD9cmePKn/2IC0hZ058K7sWdPhrYF+bJzm8GigX7UiHiBqsOoN2Vf7awClUWT24xsmo=@vger.kernel.org X-Gm-Message-State: AOJu0Yw4XCvc05rv95yBCW2vLYblFQYWMHqC4fFpEsIWGm/J2J0GdUPR jwvZFJC5aMBOSJKJvJXVbKhZxg9r35tLU+ihx3X2KeQnjy5gjLEm X-Gm-Gg: ASbGncvK/m/dzwc/3yQ3Fz+QNuC+G/Tcjabej9RSNFx1Vw8iw5CWKHk5upa+wXp9Q50 BUoDhMeg0ZMCpvLXJCnDY/GsXqWIr3g4GXI3IZNbLywDb5IYbl6yeg9s7NiBkiAe1/F52K3YW0j yX+dMdrudAT5RP3VzWDF6HF1ZGArHnibKKBsLqMGOKZ5K2AZQtv9RXVIYiHNjaMfKE5Mo50KFoD K1edK/rHl+NPgmQTbJwy+XTEo52T9vWiCmbZPc6/bo3AT7sljidKC0gYJfT81qA7U/tCVUvKitd X-Google-Smtp-Source: AGHT+IHSP4Koh9Y9mkSlcHToCXZivn+5KiUUo3WQY+jr+CS7AKVG2i+lvkc3J8jHXcv0v0GTO3NldA== X-Received: by 2002:a05:6820:823:b0:5e1:ea03:9286 with SMTP id 006d021491bc7-5f20a1e15edmr7969019eaf.6.1732895942287; Fri, 29 Nov 2024 07:59:02 -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.59.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 29 Nov 2024 07:59:01 -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 5/7] docs/sp_SP: Add translation of process/7.AdvancedTopics.rst Date: Fri, 29 Nov 2024 09:58:45 -0600 Message-ID: <20241129155851.1023884-6-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/7.AdvancedTopics.rst into Spanish. Co-developed-by: Carlos Bilbao Signed-off-by: Carlos Bilbao Signed-off-by: Avadhut Naik Signed-off-by: Carlos Bilbao --- .../sp_SP/process/7.AdvancedTopics.rst | 207 +++++++++++++++++- .../sp_SP/process/development-process.rst | 1 + 2 files changed, 206 insertions(+), 2 deletions(-) diff --git a/Documentation/translations/sp_SP/process/7.AdvancedTopics.rst = b/Documentation/translations/sp_SP/process/7.AdvancedTopics.rst index 553759857339..42cb8b866e11 100644 --- a/Documentation/translations/sp_SP/process/7.AdvancedTopics.rst +++ b/Documentation/translations/sp_SP/process/7.AdvancedTopics.rst @@ -1,11 +1,214 @@ .. include:: ../disclaimer-sp.rst =20 :Original: Documentation/process/7.AdvancedTopics.rst +:Translator: Carlos Bilbao and Avadhut Nai= k =20 .. _sp_development_advancedtopics: =20 Temas avanzados =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 -.. warning:: - TODO a=C3=BAn no traducido +Llegados a este punto, con suerte, tiene una idea de c=C3=B3mo funciona el +proceso de desarrollo. Sin embargo, =C2=A1todav=C3=ADa hay m=C3=A1s que ap= render! Esta +secci=C3=B3n cubrir=C3=A1 varios temas que pueden ser =C3=BAtiles para los= desarrolladores +que desean convertirse en una parte regular del proceso de desarrollo del +kernel Linux. + +Gestionar parches con git +------------------------- + +El uso del control de versiones distribuido para el kernel comenz=C3=B3 a +principios de 2002 cuando Linus comenz=C3=B3 a jugar con la aplicaci=C3=B3n +propietaria BitKeeper. Aunque BitKeeper fue controvertido, el enfoque de +la gesti=C3=B3n de versiones de software que incorpor=C3=B3 ciertamente no= lo fue. +El control de versiones distribuido permiti=C3=B3 una aceleraci=C3=B3n inm= ediata +del proyecto de desarrollo del kernel. En los tiempos actuales, existen +varias alternativas gratuitas a BitKeeper. Para bien o para mal, el +proyecto del kernel ha optado por git como su herramienta preferida. + +Administrar parches con git puede hacer la vida mucho m=C3=A1s f=C3=A1cil = para el +desarrollador, especialmente a medida que crece el volumen de esos +parches. Git tambi=C3=A9n tiene sus asperezas y representa ciertos peligro= s; +es una herramienta joven y poderosa que a=C3=BAn est=C3=A1 siendo civiliza= da por +sus desarrolladores. Este documento no intentar=C3=A1 ense=C3=B1ar al lect= or c=C3=B3mo +usar git; eso ser=C3=ADa material suficiente para un documento extenso por +derecho propio. En su lugar, el enfoque aqu=C3=AD ser=C3=A1 c=C3=B3mo git = encaja en el +proceso de desarrollo del kernel en particular. Los desarrolladores que +deseen ponerse al d=C3=ADa con git encontrar=C3=A1n m=C3=A1s informaci=C3= =B3n en: + + https://git-scm.com/ + + https://www.kernel.org/pub/software/scm/git/docs/user-manual.html + +y en varios tutoriales que se encuentran en la web. + +El primer orden del negocio es leer los sitios mencionados anteriormente +y comprender c=C3=B3mo funciona git antes de intentar usarlo para poner +parches a disposici=C3=B3n de otros. Un desarrollador que usa git debe ser +capaz de obtener una copia del repositorio mainline, explorar el historial +de revisiones, hacer commits en el =C3=A1rbol, usar ramas, etc=C3=A9tera. = Tambi=C3=A9n es +=C3=BAtil entender las herramientas de git para rescribir la historia (como +rebase). Git viene con su propia terminolog=C3=ADa y conceptos; un nuevo +usuario de git debe conocer las referencias, las ramas remotas, el =C3=ADn= dice, +las fusiones fast-forward, los pushes y pulls, las cabezas separadas, +etc=C3=A9tera. Todo puede ser un poco intimidante al principio, pero los +conceptos no son tan dif=C3=ADciles de entender con un poco de estudio. + +Usar git para generar parches para enviarlos por correo electr=C3=B3nico p= uede +ser un buen ejercicio mientras te pones al d=C3=ADa. + +Cuando est=C3=A9 listo para comenzar a publicar =C3=A1rboles de git para q= ue otros +los vean, necesitar=C3=A1 por supuesto, un servidor del que se pueda extra= er. +Configurar un servidor de este tipo con git-daemon es relativamente +sencillo si tiene un sistema accesible a Internet. De lo contrario, los +sitios de alojamiento p=C3=BAblico y gratuitos (GitHub, por ejemplo) est= =C3=A1n +comenzando a aparecer en la red. Los desarrolladores establecidos pueden +obtener una cuenta en kernel.org, pero no son f=C3=A1ciles de conseguir; v= er +https://kernel.org/faq/ para m=C3=A1s informaci=C3=B3n. + +El flujo de trabajo normal de git implica el uso de muchas ramas. Cada +l=C3=ADnea de desarrollo puede separarse en una =E2=80=9Crama tem=C3=A1tic= a=E2=80=9D separada y +mantenerse de forma independiente. Las ramas en git son baratas, no hay +raz=C3=B3n para no hacer uso gratuito de ellas. Y, en cualquier caso, no d= ebe +desarrollarse en ninguna rama de la que tenga la intenci=C3=B3n de pedir a +otros que hagan un pull. Las ramas disponibles p=C3=BAblicamente deben cre= arse +con cuidado; fusione los parches de las ramas de desarrollo cuando est=C3= =A9n +en forma completa y listos para usar =E2=80=93 no antes. + +Git proporciona herramientas poderosas que permiten reescribir su historia +de desarrollo. Un parche inconveniente (uno que rompe la bisecci=C3=B3n, p= or +ejemplo, o que tiene alg=C3=BAn otro tipo de error obvio) se puede corregi= r en +su lugar o hacer que desaparezca de la historia por completo. Una serie de +parches se puede reescribir como si se hubiera escrito sobre el mainline +de hoy, aunque haya estado trabajando en ella durante meses. Los cambios +se pueden transferir de manera transparente de una rama a otra. Y as=C3=AD +sucesivamente. El uso juicioso de la capacidad de git para revisar el +historial puede ayudar en la creaci=C3=B3n de conjuntos de parches limpios= con +menos problemas. + +El uso excesivo de esta capacidad puede llevar a otros problemas m=C3=A1s = all=C3=A1 +de una simple obsesi=C3=B3n por crear la historia perfecta del proyecto. +Reescribir la historia rescribir=C3=A1 los cambios contenidos en esa histo= ria, +convirtiendo un =C3=A1rbol del kernel probado (con suerte) en uno no proba= do. +Pero m=C3=A1s all=C3=A1 de eso, los desarrolladores no pueden colaborar f= =C3=A1cilmente +si no tienen una vista compartida del historial del proyecto; si reescribe +la historia que otros desarrolladores han introducido en sus repositorios, +les har=C3=A1 la vida mucho m=C3=A1s dif=C3=ADcil a esos desarrolladores. = Por lo tanto, +aqu=C3=AD se aplica una regla simple general: la historia que se ha export= ado +a otros generalmente debe considerarse inmutable a partir de entonces. + +Por lo tanto, una vez que envi=C3=A9 un conjunto de cambios a su servidor +disponible p=C3=BAblicamente, esos cambios no deben reescribirse. Git +intentar=C3=A1 hacer cumplir esta regla si intenta enviar cambios que no +resulten en un =E2=80=9Cfast-forward merge=E2=80=9D (es decir, cambios que= no comparten +el mismo historial). Es posible anular esta comprobaci=C3=B3n, y puede hab= er +ocasiones en las que sea necesario reescribir un =C3=A1rbol exportado. Mov= er +conjuntos de cambios entre =C3=A1rboles para evitar conflictos en linux-ne= xt +es un ejemplo. Pero tales acciones deber=C3=ADan ser raras. Esta es una de= las +razones por las que el desarrollo debe hacerse en ramas privadas (que se +pueden reescribir si es necesario) y solo trasladarse a ramas p=C3=BAblicas +cuando est=C3=A9 en un estado razonablemente avanzado. + +A medida que el mainline (u otro =C3=A1rbol en el que se basa un conjunto = de +cambios) avanza, es tentador fusionarse con ese =C3=A1rbol para permanecer= a +la vanguardia. Para una rama privada, la rebase puede ser una manera f=C3= =A1cil +de mantenerse al d=C3=ADa con otro =C3=A1rbol, pero la rebase no es una op= ci=C3=B3n una +vez que el =C3=A1rbol se exporta al mundo. Una vez que eso sucede, se debe +realizar una fusi=C3=B3n completa. Fusionar ocasionalmente tiene sentido, = pero +las fusiones demasiado frecuentes pueden desordenar el historial +innecesariamente. La t=C3=A9cnica sugerida en este caso es fusionar con po= ca +frecuencia y, por lo general, solo en puntos de lanzamiento espec=C3=ADfic= os +(como una versi=C3=B3n -rc del mainline). Si est=C3=A1 nervioso por cambios +espec=C3=ADficos, siempre puede realizar fusiones de prueba en una rama +privada. La herramienta git =E2=80=9Crerere=E2=80=9D puede ser =C3=BAtil e= n tales situaciones; +recuerda c=C3=B3mo se resolvieron los conflictos de fusi=C3=B3n para que n= o tenga +que hacer el mismo trabajo dos veces. + +Una de las mayores quejas recurrentes sobre herramientas como git es la +siguiente: el movimiento masivo de parches de un repositorio a otro hace +que sea f=C3=A1cil deslizar cambios m=C3=A1s aconsejados que pasan al main= line +debajo del radar de revisi=C3=B3n. Los desarrolladores del kernel tienden a +descontentarse cuando ven que suceden ese tipo de cosas; poner un =C3=A1rb= ol +de git con parches no revisados o fuera de tema puede afectar su capacidad +para hacer que los =C3=A1rboles sean integrados en el futuro. Citando a Li= nus: + +:: + + Puede enviarme parches, pero para que yo acepte un parche de git de + su parte, necesito saber que usted sabe lo que est=C3=A1 haciendo, y + necesito poder confiar en las cosas *sin* tener que revisar + manualmente cada cambio individual. + +(https://lwn.net/Articles/224135/). + +Para evitar este tipo de situaci=C3=B3n, aseg=C3=BArese de que todos los p= arches +dentro de una rama determinada se adhieran estrictamente al tema asociado; +una rama de =E2=80=9Ccorrecciones de drivers=E2=80=9D no deber=C3=ADa hace= r cambios en el +c=C3=B3digo central de gesti=C3=B3n de memoria. Y, lo m=C3=A1s importante,= no utilice un +=C3=A1rbol git para eludir el proceso de revisi=C3=B3n. Publique un resumen +ocasional del =C3=A1rbol en la lista relevante y, cuando sea el momento +adecuado, solicite que el =C3=A1rbol se incluya en linux-next. + +Si y cuando otros comiencen a enviar parches para su inclusi=C3=B3n en su +=C3=A1rbol, no olvide revisarlos. Adem=C3=A1s, aseg=C3=BArese de mantener = la informaci=C3=B3n +de autor=C3=ADa correcta; la herramienta git =E2=80=9Cam=E2=80=9D hace lo = mejor que puede es +este sentido, pero es posible que tenga que agregar una l=C3=ADnea =E2=80= =9CFrom:=E2=80=9D al +parche si ha sido reenviado a trav=C3=A9s de un tercero. + +Al solicitar un pull, proporcione toda la informaci=C3=B3n relevante: d=C3= =B3nde +est=C3=A1 su =C3=A1rbol, qu=C3=A9 rama se debe pull, y que cambios resulta= r=C3=A1n del pull. +El comando git request-pull puede ser =C3=BAtil en este sentido; formatear= =C3=A1 la +solicitud como otros desarrolladores esperan, y tambi=C3=A9n comprobar=C3= =A1 para +asegurarse de que ha recordado enviar esos cambios al servidor p=C3=BAblic= o. + +Revisi=C3=B3n de parches +------------------- + +Algunos lectores seguramente se opondr=C3=A1n a incluir esta secci=C3=B3n = con +=E2=80=9Ctemas avanzados=E2=80=9D porque incluso los desarrolladores princ= ipiantes del +kernel deber=C3=ADan revisar los parches. Es cierto que no hay mejor maner= a de +aprender a programar en el entorno del kernel que mirando el c=C3=B3digo +publicado por otros. Adem=C3=A1s, los revisores siempre escasean; al revis= ar +c=C3=B3digo, puede contribuir significativamente al proceso en su conjunto. + +Revisar el c=C3=B3digo puede ser una perspectiva intimidante, especialmente +para un nuevo desarrollador de kernel que puede sentirse nervioso al +cuestionar el c=C3=B3digo =E2=80=93 en p=C3=BAblico =E2=80=93 publicado po= r aquellos con m=C3=A1s +experiencia. Sin embargo, incluso el c=C3=B3digo escrito por los desarroll= adores +m=C3=A1s experimentados se puede mejorar. Quiz=C3=A1s el mejor consejo par= a los +revisores (todos los revisores) es este: expresar los comentarios de +revisi=C3=B3n como preguntas en lugar de cr=C3=ADticas. Preguntar =E2=80= =9C=C2=BFc=C3=B3mo se libera +el bloqueo en este camino?=E2=80=9D siempre funcionar=C3=A1 mejor que deci= r =E2=80=9Cel +bloqueo aqu=C3=AD es incorrecto=E2=80=9D. + +Otra t=C3=A9cnica que es =C3=BAtil en caso de desacuerdo es pedir a otros = que +intervengan. Si una discusi=C3=B3n llega a un punto muerto despu=C3=A9s de= algunos +intercambios, solicite las opiniones de otros revisores o maintainers. A +menudo, aquellos que est=C3=A1n de acuerdo con un revisor permanecen en +silencio a menos que se les invite a participar. La opini=C3=B3n de varias +personas tiene exponencialmente m=C3=A1s peso. + +Diferentes desarrolladores revisar=C3=A1n el c=C3=B3digo desde diferentes = puntos de +vista. Algunos se preocupan principalmente por el estilo de codificaci=C3= =B3n +y si las l=C3=ADneas de c=C3=B3digo tienen espacios en blanco al final. Ot= ros se +enfocar=C3=A1n principalmente en si el cambio implementado por el parche e= n su +totalidad es beneficioso para el kernel o no. Sin embargo, otros +comprobar=C3=A1n si hay bloqueos problem=C3=A1ticos, uso excesivo de la pi= la, +posibles problemas de seguridad, duplicaci=C3=B3n de c=C3=B3digo encontrad= o en +otras partes, documentaci=C3=B3n adecuada, efectos adversos en el rendimie= nto, +cambios en la ABI del espacio de usuario, etc=C3=A9tera. Todos los tipos de +revisi=C3=B3n, si conducen a un mejor c=C3=B3digo en el kernel, son bienve= nidos y +valen la pena. + +No hay ning=C3=BAn requisito estricto para usar etiquetas espec=C3=ADficas= como +``Reviewed-by``. De hecho, las revisiones en Ingl=C3=A9s sencillo son m=C3= =A1s +informativas y alentadas incluso cuando se proporciona una etiqueta, por +ejemplo, =E2=80=9CRevis=C3=A9 los aspectos A, B y C de esta propuesta y me= parece +bien=E2=80=9D. +=C2=A1Alguna forma de mensaje de revisi=C3=B3n o respuesta es obviamente n= ecesaria, +de lo contrario, los maintainers no sabr=C3=A1n que el revisor ha revisado= el +parche en absoluto! + +Por =C3=BAltimo, pero no menos importante, la revisi=C3=B3n de parches pue= de +convertirse en un proceso negativo, centrado en se=C3=B1alar problemas. = =C2=A1Por +favor, d=C3=A9 un cumplido de vez en cuando, especialmente a los principia= ntes! diff --git a/Documentation/translations/sp_SP/process/development-process.r= st b/Documentation/translations/sp_SP/process/development-process.rst index c977d047a792..ecfa04d96b5e 100644 --- a/Documentation/translations/sp_SP/process/development-process.rst +++ b/Documentation/translations/sp_SP/process/development-process.rst @@ -29,3 +29,4 @@ para entenderla. 4.Coding 5.Posting 6.Followthrough + 7.AdvancedTopics --=20 2.43.0 From nobody Sun Dec 14 12:51:50 2025 Received: from mail-ot1-f46.google.com (mail-ot1-f46.google.com [209.85.210.46]) (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 8748D19DF47; Fri, 29 Nov 2024 15:59:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.46 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732895946; cv=none; b=epoIDS73Gp+M9t+ezskE0xlDcb9Kxo21X2tdn6WtkuZOwI7byUbRf0SpWzrrS37tgcLU3Ra0IplY4KVTZIpfbGqAiR5R6rTeQxxyGsBO9q3hht/kHRAvjMDB7estDeBNFVGM9oKqB87sY0WyGXO+vrrIDywjqBGKhKMpjlYbnh0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732895946; c=relaxed/simple; bh=VDeprDTicXna6kpAAeukLMt08eeVdWnJ9nmGXd+UXqg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=k57tprksbrc/IgKPdBCagkmNVZv8Kd+Nr1tvItX6E6zrEDiSrJtoq+pn55g720Q8epw8gFc8mQP3amY0vzQtgZv75+JNh56AlIiGpZXBKPPRTjhknHGXMMSPff5ShhTfEo0AGRo5mZ1F3OlUCO8iUy8VF3H+PbwhmmLIpDIZHew= 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=PKQ3OUY7; arc=none smtp.client-ip=209.85.210.46 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="PKQ3OUY7" Received: by mail-ot1-f46.google.com with SMTP id 46e09a7af769-71d551855c2so810228a34.3; Fri, 29 Nov 2024 07:59:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1732895944; x=1733500744; 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=f6qEX0ra3qWfSu3iSNGny6l2UFPA6gOod5SJz2RGJZg=; b=PKQ3OUY7LX8aJvuW/Vmwl1P0zrLcazwXOxJnpcLVsGhoDbvGlo3jB+XCf+ZMefxTWB NxTxN0NTid2FKUmEJUPawHgB7dh5SjzBDJuxDX7/A96HqERCjqQZ6SPmtPCWjYmLcRIZ Uu6TNwDd1m44cLhJtVQNnvE2JR8utXrkc/3+Z+ptGOy9Pt/hWIPlEIOUdCE+BvtMCPWg 6lNus4tnYV8WWwC/UKVDyp3gaGPV7e8534YeJ+D/wVAfgHNby2WHPyDzLsMxWjCX7Dic Maiem1Bo2XUfx88X7UdmPM9RvNJaEtN3u8TP0YcV28H0XODpPnuSXl2N8WMg3y6sgbHs F23Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732895944; x=1733500744; 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=f6qEX0ra3qWfSu3iSNGny6l2UFPA6gOod5SJz2RGJZg=; b=Krfm1NKbr9S4y9ubzJ1gsyVxo4wJWiXZidJ9Vk5rkQQ3ibS6JvWj8Q7mHPDyuec5N/ 7ctjYh0nYbRnj7m7I/SyPIw5SmezrQ2lZ0e0E+5FI5FCTiJQDdL0MhCtReRsAHyoDE/v sx7ibZp5Q2iKYckc7AVdVbp1ohFeAllUm3xpWZ0cvltw80BWmb/bXWh0tiav80ptLmw+ +adrJaMtOxlSkiWeUXpLOpV3pJBSH1/HSEJyqAr8qmRE0JWU/C6ttxWdcqzP/t4tS/lD XjaCXruXtG9YtXG00/b7aCC/1TF/i2nJyEWabBEJNf1w4CidKZqr0U5lv5BgR3QDX7ic QlVQ== X-Forwarded-Encrypted: i=1; AJvYcCWtT2fs5eid+sBtH079Ehtz37i6r4z5Ai1xGwp0tfSWyc+f9PBYMkYbXhP9rBiGcdv1yHIZKfqT0hyC+fo=@vger.kernel.org X-Gm-Message-State: AOJu0YwM7SPLoZYjN6iVLEiMmtoiazJkuIuTHVGnO55sZgsp2j9b2+Va Q38KcYiDEXfsEmf4TFbjPv/iWPj6ZDkFJVbZbOVBHzRBGMH8+Ndv X-Gm-Gg: ASbGncvOU7JzKHHneEO9mqh0SPrwR2acTbw9BmDSWswwGEdVX1EBwyVPWKu01xI+uj+ 0W0sKTQ6dHSZFlsz2n2VWuw+/F8Q2gtvTg1JXBPsDySqaOqCvRf3EapHF85qVQHTNpjBAXOzco1 Jth/7iy4W4uyDgPcIFxX+MbLFH7nJRvUvlQQx0d1MaXzdDO34V+MUfmyQvS7jVyWA+Cd+ggZraQ 9QCJHAAA/wPmkn2S70qPPWE+xtQHhaeWJ2XVcawji+MdsLrG5klXSp8d6CivaWNXWwfTXxIp/lL X-Google-Smtp-Source: AGHT+IG6Z6fRSs4Zug2I8mFKNdNbMayY7kfoGAxg65YRVvZTj/fgG/KU+vyaVfTX1+Qb0bhuz4BT9Q== X-Received: by 2002:a05:6830:4112:b0:71d:4e0f:bf58 with SMTP id 46e09a7af769-71d65e8c78fmr10113431a34.30.1732895943632; Fri, 29 Nov 2024 07:59:03 -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.59.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 29 Nov 2024 07:59:03 -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 6/7] docs/sp_SP: Add translation of process/8.Conclusion.rst Date: Fri, 29 Nov 2024 09:58:46 -0600 Message-ID: <20241129155851.1023884-7-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/8.Conclusion.rst into Spanish, finishing the development-process docs. Co-developed-by: Carlos Bilbao Signed-off-by: Carlos Bilbao Signed-off-by: Avadhut Naik Signed-off-by: Carlos Bilbao --- .../sp_SP/process/8.Conclusion.rst | 75 ++++++++++++++++++- .../sp_SP/process/development-process.rst | 1 + 2 files changed, 74 insertions(+), 2 deletions(-) diff --git a/Documentation/translations/sp_SP/process/8.Conclusion.rst b/Do= cumentation/translations/sp_SP/process/8.Conclusion.rst index dd181cb8ec9a..d311a23d53df 100644 --- a/Documentation/translations/sp_SP/process/8.Conclusion.rst +++ b/Documentation/translations/sp_SP/process/8.Conclusion.rst @@ -1,11 +1,82 @@ .. include:: ../disclaimer-sp.rst =20 :Original: Documentation/process/8.Conclusion.rst +:Translator: Carlos Bilbao and Avadhut Nai= k =20 .. _sp_development_conclusion: =20 Para m=C3=A1s informaci=C3=B3n =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 +Hay numerosas fuentes de informaci=C3=B3n sobre el desarrollo del kernel de +Linux y temas relacionados. La primera de ellas ser=C3=A1 el directorio de +Documentaci=C3=B3n (Documentation) que se encuentra en la distribuci=C3=B3= n del +c=C3=B3digo fuente del kernel. Comience con el nivel superior +:ref:`Documentation/translations/sp_SP/process/howto.rst `; +tambi=C3=A9n lea +:ref:`Documentation/translations/sp_SP/process/submitting-patches.rst `. +Muchas API internas del kernel est=C3=A1n documentadas utilizando el mecan= ismo +de kerneldoc; =E2=80=9Cmake htmldocs=E2=80=9D o =E2=80=9Cmake pdfdocs=E2= =80=9D se pueden usar para +generar esos documentos en formato HTML o PDF (aunque la versi=C3=B3n de T= eX +incluida en algunas distribuciones tiene l=C3=ADmites internos y no procesa +los documentos correctamente). + +Varios sitios web discuten el desarrollo del kernel en todos los niveles +de detalle. A su autor le gustar=C3=ADa sugerir humildemente https://lwn.n= et/ +como fuente. La informaci=C3=B3n sobre muchos temas espec=C3=ADficos del k= ernel se +puede encontrar a trav=C3=A9s del =C3=ADndice del kernel de LWN en: + + https://lwn.net/Kernel/Index/ + +M=C3=A1s all=C3=A1 de eso, un recurso valioso para los desarrolladores del= kernel +es: + + https://kernelnewbies.org/ + +Y, por supuesto, no se debe olvidar https://kernel.org/, la ubicaci=C3=B3n +definitiva para informaci=C3=B3n de lanzamiento del kernel. + +Hay varios libros sobre el desarrollo del kernel: + + Linux Device Drivers, 3rd Edition (Jonathan Corbet, Alessandro + Rubini, and Greg Kroah-Hartman). En linea en + https://lwn.net/Kernel/LDD3/. + + Linux Kernel Development (Robert Love). + + Understanding the Linux Kernel (Daniel Bovet and Marco Cesati). + +Todos estos libros padecen un defecto com=C3=BAn: suelen estar algo obsole= tos +cuando llegan a las estanter=C3=ADas, y ya llevan un tiempo en las estante= r=C3=ADas. +Aun as=C3=AD, hay bastante buena informaci=C3=B3n que se puede encontrar a= ll=C3=AD. + +La documentaci=C3=B3n de git se puede encontrar en: + + https://www.kernel.org/pub/software/scm/git/docs/ + + https://www.kernel.org/pub/software/scm/git/docs/user-manual.html + +Conclusi=C3=B3n +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +Felicitaciones a todos los que han logrado leer este extenso documento. +Con suerte, ha proporcionado una comprensi=C3=B3n =C3=BAtil de c=C3=B3mo s= e desarrolla +el kernel Linux y c=C3=B3mo puede participar en ese proceso. + +Al final, lo que importa es la participaci=C3=B3n. Cualquier proyecto de +software de c=C3=B3digo abierto no es m=C3=A1s que la suma de lo que sus +colaboradores aportan. El kernel Linux ha progresado tan r=C3=A1pido y tan= como +lo ha hecho porque ha sido ayudado por un grupo impresionantemente grande +de desarrolladores, todos los cuales est=C3=A1n trabajando para mejorarlo.= El +kernel es un excelente ejemplo de lo que se puede lograr cuando miles de +personas trabajan juntas hacia un objetivo com=C3=BAn. + +Sin embargo, el kernel siempre puede beneficiarse de una base de +desarrolladores m=C3=A1s grande. Siempre hay m=C3=A1s trabajo por hacer. P= ero, lo +que es igual de importante, la mayor=C3=ADa de los dem=C3=A1s participante= s en el +ecosistema Linux pueden beneficiarse contribuyendo al kernel. Introducir +c=C3=B3digo en el mainline es la clave para una mayor calidad del c=C3=B3d= igo, +menores costes de mantenimiento y distribuci=C3=B3n, un mayor nivel de +influencia sobre la direcci=C3=B3n del desarrollo del kernel y m=C3=A1s. E= s una +situaci=C3=B3n en la que todos los involucrados ganan. Encienda su editor y +=C3=BAnase a nosotros; ser=C3=A1 m=C3=A1s que bienvenido. diff --git a/Documentation/translations/sp_SP/process/development-process.r= st b/Documentation/translations/sp_SP/process/development-process.rst index ecfa04d96b5e..5430c4cc001b 100644 --- a/Documentation/translations/sp_SP/process/development-process.rst +++ b/Documentation/translations/sp_SP/process/development-process.rst @@ -30,3 +30,4 @@ para entenderla. 5.Posting 6.Followthrough 7.AdvancedTopics + 8.Conclusion --=20 2.43.0 From nobody Sun Dec 14 12:51:50 2025 Received: from mail-oo1-f54.google.com (mail-oo1-f54.google.com [209.85.161.54]) (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 BEC1519F131; Fri, 29 Nov 2024 15:59:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.161.54 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732895947; cv=none; b=c8V9GD8F0UBBdipAHzrwPOALuFn4fliMaI4t2lmGDgMQ+WCcEykfWoURkMNEP7JvsYb4Rdl9BlAq9N8iONSFIsel1GWd9m0x41QGdeuHW4g4T3zoM1oUz5mBbRhNVYS6M2LTMsxYACRPfw2B5ifLcVszDr0qj5aZhQr4M24ljU8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1732895947; c=relaxed/simple; bh=rqkHtD6EwjRJGXY2csY/dazWRa4QmRqhNcTNC7LvMmY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=aBnX9exF7KWpsZ277zPEE5/SHQAog1rSJKgYYsRHBPt8pky+tapxdtjBHr1x+GQGQsc1817NiDYTApjzPW4gvdPuZzJaXGbSCUYWnAFURgJYE10tVWqy/HxGbjx5uNT2alluP+Du8UcL+2ga/OTn2pob/HR041vdwKvYhI3+c+U= 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=aJFi1XSf; arc=none smtp.client-ip=209.85.161.54 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="aJFi1XSf" Received: by mail-oo1-f54.google.com with SMTP id 006d021491bc7-5f1e573e65dso653603eaf.0; Fri, 29 Nov 2024 07:59:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1732895945; x=1733500745; 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=tzoMrkJxZaCg7wBkCMRChgW/WckCWeGemOGQ3ada7SQ=; b=aJFi1XSfRSm5GVUcXDt/ts7X7WXxRA1kZjBfOGZqegl2TYrt7KED/gImmNrN6upQ39 gfmcKPo0NDRPenjMJmniCg9cvHNXAERAyAdn1q96YpNCxBmG/wNJIrdXJ1vrOWw6AbjD vzfk2GBvIBM+XNUWMey9U2Qbmc+VlQxGPjokjmklOmFyPX9WZXDcakuJLusSvrGcREM0 sd38VAtm+oRniPL31njXMEoGyKEU8vafy/4JHCknGx2mR59fYOYDxd79ogTNGYETk2pV ZsS9uTtKicCfPwMJDcacAVnAxXOKpRUlUnKlk1rdk7G30/ATfp7EdEOklEknINfextlC sWiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732895945; x=1733500745; 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=tzoMrkJxZaCg7wBkCMRChgW/WckCWeGemOGQ3ada7SQ=; b=us/0RWdSvhcSTHO4FzgOhUfrgBHANb1nukTOKGoWFgOe3i3Q9WBKEyaGbJTZSOAlLw lWqZrDHYg7xBy69xDIoocfX78NRORdfs4SsJbp8xLEodqcdRwyfFFBbYR+djv155k/uN JmW8nwQAiW1HfbKfmdNUkQDI2dZjWJQWtrYsgj6ODnHnkM6nbwP1YxaJeEAFQI7AyjH/ 230u2qIe+PmtyLFZajX3zu8gTlWcDpXmHm6rN11MsNw/+JeOBVLy+FW/XBulDBaCvSeI MzmrXh5a+BNNA1hHXXAVAVW6in7gkC9X4JokQTrPLpoz/ks8fs3YGAsrQ1h2uEd63Q5B upxQ== X-Forwarded-Encrypted: i=1; AJvYcCVPnf2PY5zJMEA5CtdcHkWcMaSSk8tKigqDwUS8dNVHR/jxYYkYHpWSPfYxH+qQqQqofHGYvkuO/+LsgIA=@vger.kernel.org X-Gm-Message-State: AOJu0YxV9qgwlNkrG19EAhZKv8oJFQnZn/HNb2Tt5x7uEb+3lAWZodpF +vUhrBgMkh2bOD5kjZ3HTlS8wK6PAflChE/4QcA+0d3wginFqSIWGYtMEw== X-Gm-Gg: ASbGnct0lKTW171ibb0tzSmjZg+//czpdPdFnN193vsD3vVwpoyPSm3KKcOt7hwDKFJ XbFkPJ9YcH/xCcspwJAY16zhVZUMGBHW2GBYxR+v3M8jFMFqD5d6SuTKu/iPCMUFvfz2EscBTWi RGX6UTi1pvIrQFqBLELXontrZw3h/CGx+/rmh2rPRMPJhSRZzOYcLiAvzXo983UDHrVt604LF6i LzdSgtwazgI/iCCSPPp60sZMujboJPOCXDxb0rJ+d+sDjt3ideKTJPc3xY05x2kp2YH5EfEA1N6 X-Google-Smtp-Source: AGHT+IHElCuQ7DTZuarRABOdNaEJRHlZAVzd59Mo0eflwDJQsa9mJo3giajm3aMDABOGIB6aqwEriA== X-Received: by 2002:a05:6830:6d16:b0:71a:21c9:cd62 with SMTP id 46e09a7af769-71d65cabfbcmr12593507a34.17.1732895944806; Fri, 29 Nov 2024 07:59:04 -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.59.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 29 Nov 2024 07:59:04 -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 7/7] docs/sp_SP: Move development-process to top of index Date: Fri, 29 Nov 2024 09:58:47 -0600 Message-ID: <20241129155851.1023884-8-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 All documents in development-process are now translated. Reorder development-process to the top of the index for translated docs, matching the layout in the main Documentation index. Co-developed-by: Avadhut Naik Signed-off-by: Avadhut Naik Signed-off-by: Carlos Bilbao --- .../sp_SP/process/development-process.rst | 15 +++++++-------- .../translations/sp_SP/process/index.rst | 2 +- 2 files changed, 8 insertions(+), 9 deletions(-) diff --git a/Documentation/translations/sp_SP/process/development-process.r= st b/Documentation/translations/sp_SP/process/development-process.rst index 5430c4cc001b..261bcdea3ffc 100644 --- a/Documentation/translations/sp_SP/process/development-process.rst +++ b/Documentation/translations/sp_SP/process/development-process.rst @@ -1,7 +1,7 @@ .. include:: ../disclaimer-sp.rst =20 :Original: Documentation/process/development-process.rst -:Translator: Avadhut Naik +:Translator: Carlos Bilbao and Avadhut Nai= k =20 .. _sp_development_process_main: =20 @@ -9,14 +9,13 @@ Gu=C3=ADa del proceso de desarrollo del kernel =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 El prop=C3=B3sito de este documento es ayudar a los desarrolladores (y sus -gerentes) a trabajar con la comunidad de desarrollo con un m=C3=ADnimo de +jefes) a trabajar con la comunidad de desarrollo con el m=C3=ADnimo de frustraci=C3=B3n. Es un intento de documentar c=C3=B3mo funciona esta comu= nidad -de una manera accesible para aquellos que no est=C3=A1n familiarizados -=C3=ADntimamente con el desarrollo del kernel de Linux (o, de hecho, el -desarrollo de software libre en general). Si bien hay algo de material -t=C3=A9cnico aqu=C3=AD, este es en gran medida una discusi=C3=B3n orientad= a al proceso -que no requiere un conocimiento profundo de la programaci=C3=B3n del kernel -para entenderla. +de una manera accesible, para aquellos que no est=C3=A1n familiarizados +=C3=ADntimamente con el desarrollo del kernel Linux (o, de hecho, el desar= rollo +de software libre en general). Si bien hay algo de material t=C3=A9cnico a= qu=C3=AD, +esto es en gran medida una discusi=C3=B3n orientada al proceso que no requ= iere +un conocimiento profundo de la programaci=C3=B3n del kernel para entenderl= a. =20 .. toctree:: :caption: Contenido diff --git a/Documentation/translations/sp_SP/process/index.rst b/Documenta= tion/translations/sp_SP/process/index.rst index adb2cc845928..cff972fe0084 100644 --- a/Documentation/translations/sp_SP/process/index.rst +++ b/Documentation/translations/sp_SP/process/index.rst @@ -10,6 +10,7 @@ .. toctree:: :maxdepth: 1 =20 + development-process submitting-patches kernel-docs coding-style @@ -28,5 +29,4 @@ management-style submit-checklist howto - development-process maintainer-kvm-x86 --=20 2.43.0