From nobody Sun Dec 14 20:12:57 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