From nobody Sun Dec 14 20:28:52 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