From nobody Fri Dec 19 21:53:30 2025 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2050.outbound.protection.outlook.com [40.107.244.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 21C301292FC; Tue, 5 Mar 2024 22:18:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=40.107.244.50 ARC-Seal: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709677143; cv=fail; b=nTZJLQzvRdWqlpYhQ7RbNwStp2C8l3OMpOyPgwNPsCmG1/VRr46x4QUNOju1UcZR3jIwMPf7EsMynEOXW+BbJlIqlyhIDzo//zSd1kMwIYeHbrdPZOebrGJaadq/IBh/Bgc3xQazJC/kpiFv2du8BmKp+z4Ng5+AbPQT/L/s7a8= ARC-Message-Signature: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709677143; c=relaxed/simple; bh=+8EyHNLzJ49N0vtQQ95NkSuR5hr5f8Y6PbKCO/AppTU=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=fR+JtaxocOeKWvZqG289pG2CJbRZjFL3l9aKK+zQITZEaiZ6JMvD5ZKU61rmBH43TFdpCdAdXz3Gtvmz7UvA7oVMa5aqT+COb/KZpJk3Vw6bI2P4vWLccGGSdb3TchzsbkchI8oK2wLDPib8cr8j3UnjESSU0odfrO2+WJ/qpS8= ARC-Authentication-Results: i=2; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amd.com; spf=fail smtp.mailfrom=amd.com; dkim=pass (1024-bit key) header.d=amd.com header.i=@amd.com header.b=XWQCrCW2; arc=fail smtp.client-ip=40.107.244.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amd.com Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=amd.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=amd.com header.i=@amd.com header.b="XWQCrCW2" ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iCj5GlQwWyO8aZMmHy2ciynpJMGbQW5JUXZK+5SE1vwLKp4vitbAFtPrlurG2CQKD3TAwqYU9BWSeNI5o+4DRHot39gqMpHRZMOxEWqLwIM17Xxq19kvdkK81AOTxYCCJdlULILg/cOUpGJMMheammCky5znC50sbBe3KMflpNerLK/yamNJP5oHqyF5itZ1nYp3Mmb4bURjwr21TA+xNLgaILVpmqPMtzBbRJuW3c4Zwb1xhG/9ytxlc0cItFPCVK5CVIAbiInwW1skLWgSEE8gjurpp3DVv0iahLIZWr0H/gYe11Ho+k8bfpAJP0SY0XJgihjZ/EzlIB/amyrCHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=9Fevx6G7xMv/hd4H278G13QKJr8EWbXn4kXdtafzIMk=; b=MUReypgKDn4gOtnVhRAJHi+P8W6wDUz5Fnl6WKvgZUZ9kCePH9+GPTzCZDzMQWCDum2Ckg5JoRdFEv4+OaC4yDpL0Td7MtlBQdKRUVrLsn15tQkcXeCRf5yVJMj+9/eKQu0m78QcALX5mHg5mPLWkI+p9zoHV2XXrmvoANv3rDOqdQPXESPqYj5CQUuDyAII2/U73xaUVbSsPBwHiVbuCy8uLRZIB8FOpFoaPuzyf6lYm0Dw/ufLxraEg8UuXSkUo1w6c4dcL6HzKADSpchfPTnzj91kvalpIbhwEx+6jl5ofTsNP9XCaqbZhNF0+twTK3DnFjl53AYxbR0bAWlIaw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lwn.net smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9Fevx6G7xMv/hd4H278G13QKJr8EWbXn4kXdtafzIMk=; b=XWQCrCW2MR/jpkhbjs5KpG+aIk6XSxOhu/J/Yaf90Mat7CO9D7JrjpBS6exEZhkxVBlQIidLZamXc+IBKoUTQRBuXjDUFKrp5n7NQyVLprwCKBkRVfid5pZMqPxWNARJJsZ07BKxn7TNbOCW9/PsKYPaKN34SgfXH4Q/uuhVymg= Received: from CH5P222CA0011.NAMP222.PROD.OUTLOOK.COM (2603:10b6:610:1ee::26) by PH7PR12MB7186.namprd12.prod.outlook.com (2603:10b6:510:202::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.24; Tue, 5 Mar 2024 22:18:56 +0000 Received: from CH1PEPF0000AD7C.namprd04.prod.outlook.com (2603:10b6:610:1ee:cafe::67) by CH5P222CA0011.outlook.office365.com (2603:10b6:610:1ee::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.24 via Frontend Transport; Tue, 5 Mar 2024 22:18:56 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C Received: from SATLEXMB04.amd.com (165.204.84.17) by CH1PEPF0000AD7C.mail.protection.outlook.com (10.167.244.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7362.11 via Frontend Transport; Tue, 5 Mar 2024 22:18:56 +0000 Received: from titanite-d354host.amd.com (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 5 Mar 2024 16:18:55 -0600 From: Avadhut Naik To: CC: , , , Subject: [PATCH 1/4] docs/sp_SP: Update process/submitting-patches Date: Tue, 5 Mar 2024 16:18:36 -0600 Message-ID: <20240305221839.2764380-2-avadhut.naik@amd.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240305221839.2764380-1-avadhut.naik@amd.com> References: <20240305221839.2764380-1-avadhut.naik@amd.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 X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH1PEPF0000AD7C:EE_|PH7PR12MB7186:EE_ X-MS-Office365-Filtering-Correlation-Id: fc8e6eef-583d-40b4-2233-08dc3d623f9b X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: I1B8jFdkdrYFgfa35CqVcpmP4vV3QWUO1W/9RvMN8De0Zktj5kskCAbTId3yA07hGWuEfoyR+FSGmR3qO6nEG45aSAWJhxa+QGPl2QoqdKLI35Uo9hzJvvWo8XzbW4E7MuilDu5VsdC7nRHPqN+g8FgJZqvEVk9GSNtjDBzUwEMPASsLdXKthU0xRj5FJXe2dwJ9G7oDbxYVE+/FdP1NO5VsMrK8AV3sW5ZOEKyUBlRmMIelJktStbSH3zrfzvsaH/xWj66na/EbRkh4tf9T8QVt3B5bEpW8Ci4uuoR2FXuNAkIAVoFqymt/XjQHYgXX/n59rDtodr7jTGKQEEW8I27MJwvi8qolhX70svhqWt2zDbuaxR/NTCywhLD7H2BbLnpnsETUbkg6wXerIdk9hCbWnW83Ho5L8x8eGOJGKMdFOkPgpGAR1Q9M1CwAui2HQrBDTDPEOTBPlYTw2lILhq/DMBsGe33P5i5H4wwzSXPpPNKSgTP/czoHlV2i/k+wW5ZL7QyDpNRyMfSucwdkmpkpzCKUqQKMHUuWFxFaVNOnxWBH/bh0h5GxBmATYH22RomsWInUTVTKgPhvtSxT5v2Be6a2mHMEYTe6fqI/A1JwSU2z4o6wmKcXDIy0rBHDGib+/pWSdXuAQQ5sW4ofKigUPhGDv7dR8CWvTmHcvc938RjS+N49JgmETvlgYBml2hemLZ8THDcVQ1U13j0Okw== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:es;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(36860700004)(376005)(82310400014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Mar 2024 22:18:56.2363 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: fc8e6eef-583d-40b4-2233-08dc3d623f9b X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CH1PEPF0000AD7C.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB7186 Commit 329ac9af902e (docs: submitting-patches: Discuss interleaved replies) updates the original Documentation/process/submitting-patches.rst file. Translate and add the updates to its corresponding version in Spanish. Signed-off-by: Avadhut Naik Reviewed-by: Carlos Bilbao --- .../sp_SP/process/submitting-patches.rst | 28 +++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/Documentation/translations/sp_SP/process/submitting-patches.rs= t b/Documentation/translations/sp_SP/process/submitting-patches.rst index c2757d9ab216..3b35566db736 100644 --- a/Documentation/translations/sp_SP/process/submitting-patches.rst +++ b/Documentation/translations/sp_SP/process/submitting-patches.rst @@ -356,6 +356,34 @@ Consulte Documentation/process/email-clients.rst para = obtener recomendaciones sobre clientes de correo electr=C3=B3nico y normas de etiq= ueta en la lista de correo. =20 +.. _sp_interleaved_replies: + +Uso de respuestas intercaladas recortadas en las discusiones por correo el= ectr=C3=B3nico +--------------------------------------------------------------------------= --------- + +Se desaconseja encarecidamente la publicaci=C3=B3n en la parte superior de= las +discusiones sobre el desarrollo del kernel de Linux. Las respuestas +intercaladas (o "en l=C3=ADnea") hacen que las conversaciones sean mucho m= =C3=A1s +f=C3=A1ciles de seguir. Para obtener m=C3=A1s detalles, consulte: +https://en.wikipedia.org/wiki/Posting_style#Interleaved_style + +Como se cita frecuentemente en la lista de correo:: + + A: http://en.wikipedia.org/wiki/Top_post + Q: =C2=BFD=C3=B3nde puedo encontrar informaci=C3=B3n sobre esto que se l= lama top-posting? + A: Porque desordena el orden en el que la gente normalmente lee el texto. + Q: =C2=BFPor qu=C3=A9 es tan malo el top-posting? + A: Top-posting. + Q: =C2=BFQu=C3=A9 es lo m=C3=A1s molesto del correo electr=C3=B3nico? + +Del mismo modo, por favor, recorte todas las citas innecesarias que no +sean relevantes para su respuesta. Esto hace que las respuestas sean m=C3= =A1s +f=C3=A1ciles de encontrar y ahorra tiempo y espacio. Para obtener m=C3=A1s +informaci=C3=B3n, consulte: http://daringfireball.net/2007/07/on_top :: + + A: No. + Q: =C2=BFDebo incluir citas despu=C3=A9s de mi respuesta? + .. _sp_resend_reminders: =20 No se desanime o impaciente --=20 2.34.1 From nobody Fri Dec 19 21:53:30 2025 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2040.outbound.protection.outlook.com [40.107.236.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3559512D20D; Tue, 5 Mar 2024 22:19:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=40.107.236.40 ARC-Seal: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709677151; cv=fail; b=mQ+kfyq749BK2l9q7P4YmIu4GjKa9myf2b69VHWEUi3tpGpjOuF2pT0EOhYeDwDJpuznMZj/ZYH9bY0fH1H8j9nonNT1tI0H2u25DvGFX+aQqdnMdyf4AKMPV96+xNydV5KLdYR/4K1ODxQg/uO7yGQpbPHfV+Vbmvy/ybIYKXo= ARC-Message-Signature: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709677151; c=relaxed/simple; bh=ECnrVbRzkHgD8C6yqjSuGdf7G+b69ly7zwYyxIr8KQY=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=i2OLMQrl3E6O6KF5uteIiIWbHnx3eXoXmF/36yYO25OYI874w/epURJM9k5Z80BXV5o8AJNFKHF4cPeb6OZI+n07jsJMdfc/MxmL9DmNwgGV4Dtknbfevkbkd6RLfeVv74PM5+em5iOO3YehRUXQ0mRZzmHpjhE8FJos9hPFjcw= ARC-Authentication-Results: i=2; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amd.com; spf=fail smtp.mailfrom=amd.com; dkim=pass (1024-bit key) header.d=amd.com header.i=@amd.com header.b=c+k1E8sp; arc=fail smtp.client-ip=40.107.236.40 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amd.com Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=amd.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=amd.com header.i=@amd.com header.b="c+k1E8sp" ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=R/ycXMfOqOQwJ79eZWI0wQcANwnJYQEB5eLW6Hz7ZDXuf9eyIPucf8/ZZeRLivaCwXj5f3lGnsD2RXwrYvctmbiuQktBk+ujpwdcBlUX3txywmJvuVMSaxpxJ/K4P36g/iJRYwKIyhVVInzT/lh/IY6s7h5PpjsLq9au0jAwtluz3Ljl/5r1VLuUeTyX7qICuPGBWmSAG6+S4kl+rbc/G/LoFoomPhI2sRU4FHqlchE2y+9cUvybveqSmQs8tnN7ejJfK4PUiGMLG+hrxVtUOWJ9rDb9gHl1EKObN4DgcJdaTnjxxnhfPXSziEGOToKBwwXqp2FTaRDdTH3eNkOq1A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=KigzDJIRzjCau7t+OZt8V41M5faKqAe2b0ilMgga4VE=; b=gI+83pEP1VmrAR5TFMATXgktcvrjOZh9vDHGjZMBR9IA+kLBiLssLm2KT/r+9EWpw261njr6UcUf1hxr3eH3TjOTvBQOjT6XrZ4j7w7eHZYVEJ9PRJcrrGntL+flt0Y3oKlffUbk68/kexew4uWlr5JRnr9Tu6Z2JW/dM+OOiufasCv9wH60X3dTADJSvUtjkfgV6t5jh+AqrKZ+UhULwuL1fMlfcxcCKduPNqLkEVqs3AiDOzW9dv1isKhASH1XOBSzyUFTghX1vIZ1zi3C5He0qhNRte7kAtK3chjM2M0keo9WKsfqu0Lmml6iKZLCwsq/YN6b5KBjmilg5HAGoA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lwn.net smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KigzDJIRzjCau7t+OZt8V41M5faKqAe2b0ilMgga4VE=; b=c+k1E8spZMeMTqC6Epcho9UsT4IyY7FQRa5DjMPx4t1IdGcqC5gp3d5QHCdyPx0PkVUoGfpBeBK2tpFUEBwNSHQ4zm1oH1RlU67utJWq6Wiq43ERpDI21s/i9lAk8fqrplbKslpCabiL55cWwza+t/Jv+vn0p/OLjmFPq45tH1E= Received: from CH2PR12CA0016.namprd12.prod.outlook.com (2603:10b6:610:57::26) by IA1PR12MB6187.namprd12.prod.outlook.com (2603:10b6:208:3e5::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7339.37; Tue, 5 Mar 2024 22:19:07 +0000 Received: from CH1PEPF0000AD7E.namprd04.prod.outlook.com (2603:10b6:610:57:cafe::2a) by CH2PR12CA0016.outlook.office365.com (2603:10b6:610:57::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.24 via Frontend Transport; Tue, 5 Mar 2024 22:19:07 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C Received: from SATLEXMB04.amd.com (165.204.84.17) by CH1PEPF0000AD7E.mail.protection.outlook.com (10.167.244.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7362.11 via Frontend Transport; Tue, 5 Mar 2024 22:19:07 +0000 Received: from titanite-d354host.amd.com (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 5 Mar 2024 16:19:06 -0600 From: Avadhut Naik To: CC: , , , Subject: [PATCH 2/4] docs/sp_SP: Add translation of process/development-process.rst Date: Tue, 5 Mar 2024 16:18:37 -0600 Message-ID: <20240305221839.2764380-3-avadhut.naik@amd.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240305221839.2764380-1-avadhut.naik@amd.com> References: <20240305221839.2764380-1-avadhut.naik@amd.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 X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH1PEPF0000AD7E:EE_|IA1PR12MB6187:EE_ X-MS-Office365-Filtering-Correlation-Id: 46810141-e2d9-451d-816f-08dc3d624613 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 68U0BZebJi7ViOBuRyIA6aqIId2TlhYCtLnJTK68t9TEm99c3BuOcU5PLCSafd3ASxh3wLcGc9mVZE6TFpoG7PFEwvdvmjG1nWSbfSR9oLYEFYA/TObnHvaCAQDBGbNPLwXYI55SkSKCLG+kTJ7Fo1On0Ni3NRKRRuyhs0yC3xqjqcyfp/9FtrdPe6U7mC+D9c0j7rZNgua3/z3DZY2eGoApkwdKW8+Q3X7fqbmYgGTO61AIqX/Of62guk2bLfhOnMNGtQULXXjqgUvxZKTP4+Un+CZ5H6wEVg5XYPg9HTAAz0EcAxGAQ8ZhE0FFfnn4SGYDdZsU9E+4F9Zn79uFqzQ76L+moB4sETlSoQgzkuvtx8YC5SBh7ZDdQfX3NTGi2j4/Z/+Q8XHwzi6X1omEf0EEVnmeIF+HwEMoTjgrZtuEft0DzDJrbJa0T5QeERSXEY4ZXlTC0RHBUiMRLhly40pD8auOwxfdF2tMZNOw/vKj0MlHZ2wf4J+FHcVe84ukvd5bTz/th3rJY7ltOBkpKBljC+qNPyB64GgGjc5aSBgnLQ/jLEWQXrDsY4MAAe8HnnwWhv5QvmRNtIBCAH2N2oqobolOQ+VCdfB4w6y4+wPix0N+0W9zASZ+aVOEe7fYlb614Zvb2FIOMjiO/KgydQkKNpr5mu8ZKBoS/Rpfwmf+5ZTHj4ynwp3l6ccoGdebtMhohw6htIHcCsYjivnhdRGxue554cas7WbBNLG5IS8vdGmXMek7ouYprgpEtf36 X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:es;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(36860700004)(82310400014)(376005);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Mar 2024 22:19:07.0915 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 46810141-e2d9-451d-816f-08dc3d624613 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CH1PEPF0000AD7E.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR12MB6187 Translate Documentation/process/development-process.rst into Spanish Signed-off-by: Avadhut Naik Reviewed-by: Carlos Bilbao --- .../sp_SP/process/development-process.rst | 24 +++++++++++++++++++ .../translations/sp_SP/process/index.rst | 1 + 2 files changed, 25 insertions(+) create mode 100644 Documentation/translations/sp_SP/process/development-pr= ocess.rst diff --git a/Documentation/translations/sp_SP/process/development-process.r= st b/Documentation/translations/sp_SP/process/development-process.rst new file mode 100644 index 000000000000..41616249aa9e --- /dev/null +++ b/Documentation/translations/sp_SP/process/development-process.rst @@ -0,0 +1,24 @@ +.. include:: ../disclaimer-sp.rst + +:Original: Documentation/process/development-process.rst +:Translator: Avadhut Naik + +.. _sp_development_process_main: + +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 + +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 +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. + +.. toctree:: + :caption: Contenido + :numbered: + :maxdepth: 2 diff --git a/Documentation/translations/sp_SP/process/index.rst b/Documenta= tion/translations/sp_SP/process/index.rst index 2239373b3999..4892159310ff 100644 --- a/Documentation/translations/sp_SP/process/index.rst +++ b/Documentation/translations/sp_SP/process/index.rst @@ -28,3 +28,4 @@ management-style submit-checklist howto + development-process --=20 2.34.1 From nobody Fri Dec 19 21:53:30 2025 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2043.outbound.protection.outlook.com [40.107.92.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7701012D202; Tue, 5 Mar 2024 22:19:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=40.107.92.43 ARC-Seal: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709677165; cv=fail; b=UQ3Wt/HrCy02j3YmE4eAajTzNTj0ShUXnPURu4uCB8TFa4gztmqAIyRxM9125sR16o6xC5HmrX6JSyXtMr1H1dFPvw6VemKGxP+2WXXX34nba0Q2ikRtzwi481rTwbMvzJuBaQ1Lhly0XWZ/Go+rIPt/eFndhxor4Phg0LIGrvg= ARC-Message-Signature: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709677165; c=relaxed/simple; bh=lQe/Fm6PgMomyf2JLYC4Hh6faokLZm/mD4OIQZpAAhw=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=dXY93Ed2rmEHFAoN2PaTDA9u3a1sXbY4PakPua9NybqlfgDYYfJ+6dyxWcOq45afV4ctCE0wXuZakzhcMcN1aU8MRZtdnQKsL2bW9ZpGH0dBf+43HwdTyFQNs2EXkeKV73dTfMr0oROWiFyYdX+9nuP93MZSQaaZXrbuJxKkpdY= ARC-Authentication-Results: i=2; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amd.com; spf=fail smtp.mailfrom=amd.com; dkim=pass (1024-bit key) header.d=amd.com header.i=@amd.com header.b=jziuSI6U; arc=fail smtp.client-ip=40.107.92.43 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amd.com Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=amd.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=amd.com header.i=@amd.com header.b="jziuSI6U" ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MJQnIhJ1k9LniBhqBuNa3B7yzG/Z7sq9viTEPtwxiozGp2rOouEp26XjoLL+YiIY3AkTMgYWVQSOFlLUworLWrkWPsl89k4xaBawvNWe9a/z/5SuZi2sB5xd8Y00jkwuzRqeuEX6vBt5NOfjRw/QXh26Iz2V1uEZrGaayWiWCMzCc0PL4BFoQ+n2cpSteZIqOjNT3PIxt0dgQC8TNU8/CO6vJYtNWvpU80cIj+LylGcLzokpsP/7Z/22T5Mn5Mirw08F3z3rkKJUdwbhWhZ6zSi5LI22aYzpREUuBzeh9wc3Wy96+WnbiJdRspp4aKxodTVDXdnCzdT/c2DcP1bVxA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=L0mXncK8z3pOLU7AvOXJs9Kr+lxZXPU0W+f0wdz1Tzo=; b=LLsq8qnU/GBcw+M2D9d+W+80PbWvot4+o/2GEP/D/t7TAyHCJEURj2aCW6hNaj481v71AxB/53rfsMqdWYPKuUoPTDrN/VH4C3FuLvsb04g/hUYSPo5T5oElgyrpLr8HIb96jQm3pBwbaZEhFcKhQxNmtJgWH1DcYS6nQfenTRGduo5r8CChLHTYhG2xVAYg1SfHpO4RzGKuHaST17kCB8KXoDLx+fk+B5CyQkbpLkTCu1HpJtl4yDeDZUVlAtpcxV81sEQJPaSUikUUEoeo3WZ+f5haIVB0+YtoDAZ4wbLTrtW4PD0Kd1IxTZg1Em59oiPfN8Aoqz99zy51WM6zlA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lwn.net smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=L0mXncK8z3pOLU7AvOXJs9Kr+lxZXPU0W+f0wdz1Tzo=; b=jziuSI6UOdjCjttxxru4M2O2fdsey1jfv1y804cYCQSaNbj566eAMlpSJ0pTbV/1/YLAjdr7na1XyB3fVGTeaWMyQezZOKchuLwE5iOTUjhq3EFZUQEBHzppLH9PQSggX5vLM1pjBOsZZ+k21sreiY+yKxzEBOJnoZkuhU3kDxY= Received: from CH5PR05CA0012.namprd05.prod.outlook.com (2603:10b6:610:1f0::10) by MN2PR12MB4486.namprd12.prod.outlook.com (2603:10b6:208:263::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.24; Tue, 5 Mar 2024 22:19:20 +0000 Received: from CH1PEPF0000AD7D.namprd04.prod.outlook.com (2603:10b6:610:1f0:cafe::32) by CH5PR05CA0012.outlook.office365.com (2603:10b6:610:1f0::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7362.24 via Frontend Transport; Tue, 5 Mar 2024 22:19:20 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C Received: from SATLEXMB04.amd.com (165.204.84.17) by CH1PEPF0000AD7D.mail.protection.outlook.com (10.167.244.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7362.11 via Frontend Transport; Tue, 5 Mar 2024 22:19:20 +0000 Received: from titanite-d354host.amd.com (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 5 Mar 2024 16:19:17 -0600 From: Avadhut Naik To: CC: , , , Subject: [PATCH 3/4] docs/sp_SP: Add translation of process/1.Intro.rst Date: Tue, 5 Mar 2024 16:18:38 -0600 Message-ID: <20240305221839.2764380-4-avadhut.naik@amd.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240305221839.2764380-1-avadhut.naik@amd.com> References: <20240305221839.2764380-1-avadhut.naik@amd.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 X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH1PEPF0000AD7D:EE_|MN2PR12MB4486:EE_ X-MS-Office365-Filtering-Correlation-Id: f2b6d90e-1552-4194-9b89-08dc3d624e23 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: k/eTAuWHMTvfk/aXS/yLvwTBs4ye3h9tM5RKoiTmz+NEGYlYVkugyjlC1RZdbRBBds4FFGjM256KyGCYeHmCi6NzPAVAExWsNQ6tvE9O3OZ36rsk6XtGrSJOAGj5o46rXS2x8XHnzTIkpj49rNtSOkz4KNdqAbdfZ4gWxxkFdAEw6Nofl1U5XFGO25LPXAtgu3Z9U15m3pGMC1y7DaxEUvrS1WnhXcbAdPPKINbU9zEp+ALT0L1FNxLs2kA4I9i5wJ4yeobUAx0nxrtZnbiCogJor7Ig3Y3J9D9VsztP+ZoZxdjXV/9OB/k9J2UYYZL42SMNzSF1CLUq4XsnqmMMOw/frWZWH59xrsYNm9KYhaHIffw/HgXxZ4HOvfe+0CbRdgGDtEXHRlgXpA9h3jZLEx3JAfSpEZKRMDqlc0dJ9iX9mv48diRZlyp9OtJDZxO3fYSzVSWrDanCkwDziup6W1jpaWnZLRtFBDqJt4oglnSI/wZ29UGsIJZcCLe8eULlKw0rGSFbdg2ZfMzDuXBoFwwodhK0i1wIvloWQSr4zOyX/X05O8x0yn+ZHwLTf0gp+CwCZTRkFsp/BOsxE2n+knikUdAKrjbvwRiVdQPYV+fFoarb69qRG6681nYrZZqJK6so0DxHnK9nGJjOHfTD4YvXUXOSIMV1NE8FAwcync+Y3EMEUy9qplsgHigdOE6htVGS2DM07UIvcCNWfsBqgjrILLgsMP2OECXUL9ARx9Ro1QOtqni9RwVb3Knwl2pQ X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:es;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(376005)(36860700004)(82310400014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Mar 2024 22:19:20.6188 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f2b6d90e-1552-4194-9b89-08dc3d624e23 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CH1PEPF0000AD7D.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB4486 Translate Documentation/process/1.Intro.rst into Spanish In order to avoid broken links in the translated document, empty files have been created for documents which have not yet been translated. Signed-off-by: Avadhut Naik Reviewed-by: Carlos Bilbao --- .../translations/sp_SP/process/1.Intro.rst | 302 ++++++++++++++++++ .../translations/sp_SP/process/2.Process.rst | 11 + .../sp_SP/process/3.Early-stage.rst | 11 + .../translations/sp_SP/process/4.Coding.rst | 11 + .../translations/sp_SP/process/5.Posting.rst | 11 + .../sp_SP/process/6.Followthrough.rst | 11 + .../sp_SP/process/7.AdvancedTopics.rst | 11 + .../sp_SP/process/8.Conclusion.rst | 11 + .../sp_SP/process/development-process.rst | 2 + 9 files changed, 381 insertions(+) create mode 100644 Documentation/translations/sp_SP/process/1.Intro.rst create mode 100644 Documentation/translations/sp_SP/process/2.Process.rst create mode 100644 Documentation/translations/sp_SP/process/3.Early-stage.= rst create mode 100644 Documentation/translations/sp_SP/process/4.Coding.rst create mode 100644 Documentation/translations/sp_SP/process/5.Posting.rst create mode 100644 Documentation/translations/sp_SP/process/6.Followthroug= h.rst create mode 100644 Documentation/translations/sp_SP/process/7.AdvancedTopi= cs.rst create mode 100644 Documentation/translations/sp_SP/process/8.Conclusion.r= st diff --git a/Documentation/translations/sp_SP/process/1.Intro.rst b/Documen= tation/translations/sp_SP/process/1.Intro.rst new file mode 100644 index 000000000000..9b92b6c85221 --- /dev/null +++ b/Documentation/translations/sp_SP/process/1.Intro.rst @@ -0,0 +1,302 @@ +.. include:: ../disclaimer-sp.rst + +:Original: Documentation/process/1.Intro.rst +:Translator: Avadhut Naik + +.. _sp_development_process_intro: + +Introducci=C3=B3n +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +Resumen ejecutivo +----------------- + +El resto de esta secci=C3=B3n cubre el alcance del proceso de desarrollo d= el +kernel y los tipos de frustraciones que los desarrolladores y sus +empleadores pueden encontrar all=C3=AD. Hay muchas razones por las que el +c=C3=B3digo del kernel debe fusionarse con el kernel oficial (=E2=80=9Cmai= nline=E2=80=9D), +incluyendo la disponibilidad autom=C3=A1tica para los usuarios, el apoyo d= e la +comunidad en muchas formas, y la capacidad de influir en la direcci=C3=B3n= del +desarrollo del kernel. El c=C3=B3digo contribuido al kernel de Linux debe +estar disponible bajo una licencia compatible con GPL. + +:ref:`sp_development_process` introduce el proceso de desarrollo, el ciclo +de lanzamiento del kernel y la mec=C3=A1nica de la "ventana de combinaci= =C3=B3n" +(merge window). Se cubren las distintas fases en el desarrollo del parche, +la revisi=C3=B3n y, el ciclo de fusi=C3=B3n. Hay algunas discusiones sobre +herramientas y listas de correo. Se anima a los desarrolladores que deseen +comenzar con el desarrollo del kernel a encontrar y corregir errores como +ejercicio inicial. + +:ref:`sp_development_early_stage` cubre la planificaci=C3=B3n de proyectos= en +etapas tempranas, con =C3=A9nfasis en involucrar a la comunidad de desarro= llo +lo antes posible. + +:ref:`sp_development_coding` trata sobre el proceso de codificaci=C3=B3n. = Se +discuten varios escollos encontrados por otros desarrolladores. Se cubren +algunos requisitos para los parches, y hay una introducci=C3=B3n a algunas= de +las herramientas que pueden ayudar a garantizar que los parches del kernel +sean correctos. + +:ref:`sp_development_posting` trata sobre el proceso de enviar parches para +su revisi=C3=B3n. Para ser tomados en serio por la comunidad de desarrollo, +los parches deben estar correctamente formateados y descritos, y deben +enviarse al lugar correcto. Seguir los consejos de esta secci=C3=B3n deber= =C3=ADa +ayudar a garantizar la mejor recepci=C3=B3n posible para su trabajo. + +:ref:`sp_development_followthrough` cubre lo que sucede despu=C3=A9s de pu= blicar +parches; el trabajo est=C3=A1 lejos de terminar en ese momento. Trabajar c= on +revisores es una parte crucial del proceso de desarrollo; esta secci=C3=B3n +ofrece varios consejos sobre c=C3=B3mo evitar problemas en esta importante +etapa. Se advierte a los desarrolladores que no asuman que el trabajo est= =C3=A1 +terminado cuando un parche se fusiona en mainline. + +:ref:`sp_development_advancedtopics` introduce un par de temas =E2=80=9Cav= anzados=E2=80=9D: +la administraci=C3=B3n de parches con git y la revisi=C3=B3n de parches pu= blicados +por otros. + +:ref:`sp_development_conclusion` concluye el documento con punteros a las +fuentes para obtener m=C3=A1s informaci=C3=B3n sobre el desarrollo del ker= nel. + +De qu=C3=A9 trata este documento +--------------------------- + +El kernel de Linux, con m=C3=A1s de 8 millones de l=C3=ADneas de c=C3=B3di= go y m=C3=A1s de +1000 colaboradores en cada versi=C3=B3n, en uno de los proyectos de softwa= re +libre m=C3=A1s grandes y activos que existen. Desde sus humildes comienzos= en +1991, este kernel ha evolucionado hasta convertirse en el mejor componente +del sistema operativo que se ejecuta en reproductores de m=C3=BAsica digit= al +de bolsillo, PC de escritorio, las supercomputadoras m=C3=A1s grandes que +existen y todo tipo de sistemas intermedios. Es una soluci=C3=B3n robusta, +eficiente, y escalable para casi cualquier situaci=C3=B3n. + +Con el crecimiento de Linux, ha llegado un aumento en el n=C3=BAmero de +desarrolladores (y empresas) que desean participar en su desarrollo. Los +vendedores de hardware quieren asegurarse de que Linux sea compatible con +sus productos, lo que hace que esos productos sean atractivos para los +usuarios de Linux. Los vendedores de sistemas embebidos, que utilizan +Linux como componente de un producto integrado, quieren que Linux sea lo +m=C3=A1s capaz y adecuado posible para tarea en cuesti=C3=B3n. Los distrib= uidores +y otros vendedores de software que basan sus productos en Linux tienen un +claro inter=C3=A9s en las capacidades, el rendimiento, y la fiabilidad del +kernel de Linux. Y los usuarios finales, tambi=C3=A9n, a menudo desear=C3= =A1n +cambiar Linux para que se adapte mejor a sus necesidades. + +Una de las caracter=C3=ADsticas m=C3=A1s convincentes de Linux es que es a= ccesible +a estos desarrolladores; cualquier persona con las habilidades necesarias +puede mejorar Linux e influir en la direcci=C3=B3n de su desarrollo. Los +productos propietarios no pueden ofrecer este tipo de apertura, que es una +caracter=C3=ADstica del proceso de software libre. Pero, en todo caso, el +kernel es a=C3=BAn m=C3=A1s libre que la mayor=C3=ADa de los otros proyect= os de software +libre. Un ciclo t=C3=ADpico de desarrollo de kernel de tres meses puede +involucrar a m=C3=A1s de 1000 desarrolladores que trabajan para m=C3=A1s d= e 100 +empresas diferentes (o sin pertenecer a ninguna empresa). + +Trabajar con la comunidad de desarrollo del kernel no es especialmente +dif=C3=ADcil. Pero, a pesar de eso, muchos colaboradores potenciales han +experimentado dificultades al tratar de hacer el trabajo del kernel. La +comunidad del kernel ha desarrollado sus propias formas distintivas de +operar, lo que le permite funcionar de manera fluida (y producir un +producto de alta calidad) en un entorno donde miles de l=C3=ADneas de c=C3= =B3digo +se cambian todos los d=C3=ADas. Por lo tanto, no es sorprendente que el +proceso de desarrollo del kernel de Linux difiera mucho de los m=C3=A9todo= s de +desarrollo propietarios. + +El proceso de desarrollo del kernel puede parecer extra=C3=B1o e intimidan= te +para los nuevos desarrolladores, pero hay buenas razones y una s=C3=B3lida +experiencia detr=C3=A1s de =C3=A9l. Un desarrollador que no entienda las f= ormas de +la comunidad del kernel (o, peor a=C3=BAn, que intente burlarse o eludirla= s) +tendr=C3=A1 una experiencia frustrante por delante. La comunidad de +desarrollo, si bien es servicial para aquellos que est=C3=A1n tratando de +aprender, tiene poco tiempo para aquellos que no escuchan o que no se +preocupan por el proceso de desarrollo. + +Se espera que quienes lean este documento puedan evitar esa experiencia +frustrante. Hay mucho material aqu=C3=AD, pero el esfuerzo que implica lee= rlo +ser=C3=A1 recompensado en poco tiempo. La comunidad de desarrollo siempre +necesita desarrolladores que ayudan a mejorar el kernel; el siguiente +texto deber=C3=ADa ayudarle =E2=80=93 o a quienes trabajan para usted, a u= nirse a +nuestra comunidad. + +Cr=C3=A9ditos +-------- + +Este documento fue escrito por Jonathan Corbet, corbet@lwn.net. Ha sido +mejorado por los comentarios de Johannes Berg, James Berry, Alex Chiang, +Roland Dreier, Randy Dunlap, Jake Edge, Jiri Kosina, Matt Mackall, Arthur +Marsh, Amanda McPherson, Andrew Morton, Andrew Price, Tsugikazu Shibata y +Jochen Vo=C3=9F. +Este trabajo fue respaldado por la Fundaci=C3=B3n Linux; gracias especialm= ente +a Amanda McPherson, quien reconoci=C3=B3 el valor de este esfuerzo e hizo = que +todo sucediera. + +Importancia de integrar el c=C3=B3digo en el mainline +------------------------------------------------ + +Algunas empresas y desarrolladores ocasionalmente se preguntan por qu=C3= =A9 +deber=C3=ADan molestarse en aprender c=C3=B3mo trabajar con la comunidad d= el +kernel y obtener su c=C3=B3digo en el kernel mainline (el =E2=80=9Cmainlin= e=E2=80=9D es el +kernel mantenido por Linus Torvalds y utilizado como base por los +distribuidores de Linux. A corto plazo, contribuir con c=C3=B3digo puede +parecer un gasto evitable; parece m=C3=A1s f=C3=A1cil mantener el c=C3=B3d= igo separado +y dar soporte a los usuarios directamente. La verdad del asunto es que +mantener el c=C3=B3digo separado (=E2=80=9Cfuera del =C3=A1rbol=E2=80=9D) = es pan para hoy y hambre +para ma=C3=B1ana. + +Para ilustrar los costos del c=C3=B3digo fuera-del-=C3=A1rbol, aqu=C3=AD h= ay algunos +aspectos relevantes del proceso de desarrollo del kernel. La mayor=C3=ADa = de +estos se discutir=C3=A1n con mayor detalle m=C3=A1s adelante en este docum= ento. +Considerar: + +- El c=C3=B3digo que se ha fusionado con el kernel mainline est=C3=A1 disp= onible + para todos los usuarios de Linux. Estar=C3=A1 presente autom=C3=A1ticame= nte en + todas las distribuciones que lo habiliten. No hay necesidad de discos + de controladores, descargas, o las molestias de admitir m=C3=BAltiples + versiones de m=C3=BAltiples distribuciones; todo simplemente funciona, p= ara + el desarrollador y para el usuario. La incorporaci=C3=B3n al mainline + resuelve un gran n=C3=BAmero de problemas de distribuci=C3=B3n y soporte. + +- Mientras los desarrolladores del kernel se esfuerzan por mantener una + interfaz estable para el espacio de usuario, la API interna de kernel + est=C3=A1 en constante cambio. La falta de una interfaz interna estable = es + una decisi=C3=B3n deliberada de dise=C3=B1o; permite realizar mejoras + fundamentales en cualquier momento y da como resultado un c=C3=B3digo de + mayor calidad. Pero uno resultado de esa pol=C3=ADtica es que cualquier + c=C3=B3digo fuera-del-=C3=A1rbol requiere un mantenimiento constante si = va a + funcionar con los nuevos kernels. Mantener el c=C3=B3digo fuera-del-=C3= =A1rbol + requiere una cantidad significativa de trabajo s=C3=B3lo para que ese c= =C3=B3digo + siga funcionando. + + En su lugar, el c=C3=B3digo en el mainline no requiere este trabajo como + resultado de una regla simple que requiere que cualquier desarrollador + que realice un cambio en la API tambi=C3=A9n corrija cualquier c=C3=B3di= go que + se rompa como resultado de ese cambio. As=C3=AD que, el c=C3=B3digo fusi= onado en + el mainline tiene costos de mantenimiento significativamente m=C3=A1s ba= jos. + +- M=C3=A1s all=C3=A1 de eso, el c=C3=B3digo que est=C3=A1 en el kernel a m= enudo ser=C3=A1 + mejorado por otros desarrolladores. Resultados sorprendentes pueden + provenir de capacitar a su comunidad de usuarios y clientes para mejorar + su producto. + +- El c=C3=B3digo del kernel se somete a revisi=C3=B3n, tanto antes como de= spu=C3=A9s + de fusionarse con el mainline. No importa cu=C3=A1n fuertes sean las + habilidades del desarrollador original, este proceso de revisi=C3=B3n + invariablemente encuentra formas en las que se puede mejorar el c=C3=B3d= igo. + A menudo la revisi=C3=B3n encuentra errores graves y problemas de seguri= dad. + Esto es especialmente cierto para el c=C3=B3digo que se ha desarrollado = en + un entorno cerrado; dicho c=C3=B3digo se beneficia fuertemente de la + revisi=C3=B3n por desarrolladores externos. El c=C3=B3digo fuera-del-=C3= =A1rbol es + de menor calidad. + +- La participaci=C3=B3n en el proceso de desarrollo es su manera de influi= r en + la direcci=C3=B3n del desarrollo del kernel. Los usuarios que se quejan + desde el sofa son escuchados, pero los desarrolladores activos tienen + una voz m=C3=A1s fuerte =E2=80=93 y la capacidad de implementar cambios = que hacen + que el kernel funcione mejor para sus necesidades. + +- Cuando el c=C3=B3digo se mantiene por separado, siempre existe la posibi= lidad + de que un tercero contribuya a una implementaci=C3=B3n diferente de una + caracter=C3=ADstica similar. Si eso sucede, conseguir que su c=C3=B3digo + fusionado ser=C3=A1 mucho m=C3=A1s dif=C3=ADcil =E2=80=93 hasta el punto= de la imposibilidad. + Entonces se enfrentar=C3=A1 a las desagradables alternativas de (1) mant= ener + una caracter=C3=ADstica no est=C3=A1ndar fuera del =C3=A1rbol indefinida= mente, o + (2) abandonar su c=C3=B3digo y migrar sus usuarios a la versi=C3=B3n en = el =C3=A1rbol. + +- La contribuci=C3=B3n del c=C3=B3digo es la acci=C3=B3n fundamental que h= ace que todo + el proceso funcione. Al contribuir con su c=C3=B3digo, puede agregar nue= vas + funcionalidades al kernel y proporcionar capacidades y ejemplos que son + =C3=BAtiles para otros desarrolladores del kernel. Si ha desarrollado c= =C3=B3digo + para Linux (o est=C3=A1 pensando en hacerlo), claramente tiene un inter= =C3=A9s + en el =C3=A9xito continuo de esta plataforma; contribuir con c=C3=B3digo= es una + de las mejores maneras de ayudar a garantizar ese =C3=A9xito. + +Todo el razonamiento anterior se aplica a cualquier c=C3=B3digo de kernel +fuera-del-=C3=A1rbol, incluido el c=C3=B3digo que se distribuye en forma p= ropietaria +y =C3=BAnicamente en binario. Sin embargo, hay factores adicionales que de= ben +tenerse en cuenta antes de considerar cualquier tipo de distribuci=C3=B3n = de +c=C3=B3digo de kernel =C3=BAnicamente en binario. Estos incluyen: + +- Las cuestiones legales en torno a la distribuci=C3=B3n de m=C3=B3dulos + propietarios del kernel son, en el mejor de los casos, confusas; + bastantes titulares de derechos de autor del kernel creen que la + mayor=C3=ADa de los m=C3=B3dulos binarios son productos derivados del ke= rnel y + que, como resultado, su distribuci=C3=B3n es una violaci=C3=B3n de la li= cencia + P=C3=BAblica General de GNU (sobre la que se dir=C3=A1 m=C3=A1s adelante= ). El autor + de este texto no es abogado, y nada en este documento puede considerarse + asesoramiento legal. Solo los tribunales pueden determinar el verdadero + estatus legal de los m=C3=B3dulos de c=C3=B3digo cerrado. Pero la incert= idumbre + que acecha a esos m=C3=B3dulos est=C3=A1 ah=C3=AD a pesar de todo. + +- Los m=C3=B3dulos binarios aumentan enormemente la dificultad de depurar + problemas del kernel, hasta el punto de que la mayor=C3=ADa de los + desarrolladores del kernel ni siquiera lo intentar=C3=A1n. Por lo tanto, + la distribuci=C3=B3n de m=C3=B3dulos =C3=BAnicamente en binario har=C3= =A1 que sea m=C3=A1s + dif=C3=ADcil para sus usuarios obtener soporte de la comunidad. + +- El soporte tambi=C3=A9n es m=C3=A1s dif=C3=ADcil para los distribuidores= de m=C3=B3dulos + =C3=BAnicamente en binario, que deben proporcionar una versi=C3=B3n del = m=C3=B3dulo + para cada distribuci=C3=B3n y cada versi=C3=B3n del kernel que deseen ap= oyar. + Podr=C3=ADa requerir docenas de compilaciones de un solo m=C3=B3dulo para + proporcionar una cobertura razonablemente completa, y sus usuarios + tendr=C3=A1n que actualizar su m=C3=B3dulo por separado cada vez que + actualicen su kernel. + +- Todo lo que se dijo anteriormente sobre la revisi=C3=B3n de c=C3=B3digo = se aplica + doblemente al c=C3=B3digo cerrado. Dado que este c=C3=B3digo no est=C3= =A1 disponible + en absoluto, no puede haber sido revisado por la comunidad y, sin duda, + tendr=C3=A1 serios problemas. + +Los fabricantes de sistemas embebidos, en particular, pueden verse +tentados a ignorar gran parte de lo que se ha dicho en esta secci=C3=B3n +creyendo que est=C3=A1n enviando un producto aut=C3=B3nomo que utiliza una +versi=C3=B3n de kernel congelada y no requiere m=C3=A1s desarrollo despu= =C3=A9s de su +lanzamiento. Este argumento desaprovecha el valor de la revisi=C3=B3n +generalizad del c=C3=B3digo y el valor de permitir que sus usuarios agregu= en +capacidades a su producto. Pero estos productos tambi=C3=A9n tienen una vi= da +comercial limitada, despu=C3=A9s de la cual se debe lanzar una nueva versi= =C3=B3n. +En ese punto, los vendedores cuyo c=C3=B3digo est=C3=A9 en el mainline y b= ien +mantenido estar=C3=A1n en una posici=C3=B3n mucho mejor para preparar el n= uevo +producto r=C3=A1pidamente para el mercado. + +Licencias +--------- + +El c=C3=B3digo se contribuye al kernel de Linux bajo varias licencias, pero +todo el c=C3=B3digo debe ser compatible con la versi=C3=B3n 2 de la Licenc= ia +P=C3=BAblica General de GNU (GPLv2), que cubre la distribuci=C3=B3n del ke= rnel. En +la pr=C3=A1ctica, esto significa que todas las contribuciones de c=C3=B3di= go est=C3=A1n +cubiertas ya sea por la GPLv2 (con, opcionalmente, un lenguaje que permite +la distribuci=C3=B3n en versiones posteriores de la GPL) o por la licencia= BSD +de tres cl=C3=A1usulas. Cualquier contribuci=C3=B3n que no est=C3=A9 cubie= rta por una +licencia compatible no ser=C3=A1 aceptada en el kernel. + +No se requieren (ni se solicitan) cesiones de derechos de autor para el +c=C3=B3digo aportado al kernel. Todo el c=C3=B3digo fusionado en el kernel +mainline conserva su propiedad original; como resultado, el kernel ahora +tiene miles de propietarios. + +Una implicaci=C3=B3n de esta estructura de propiedad es que cualquier inte= nto +de cambiar la licencia del kernel est=C3=A1 condenado a un fracaso casi se= guro. +Hay pocos escenarios pr=C3=A1cticos en los que se pueda obtener el acuerdo= de +todos los titulares de derechos de autor (o eliminar su c=C3=B3digo del +kernel). As=C3=AD que, en particular, no hay perspectivas de una migraci= =C3=B3n a +la versi=C3=B3n 3 de la GPL en un futuro previsible. + +Es imperativo que todo el c=C3=B3digo aportado al kernel sea leg=C3=ADtima= mente +software libre. Por esa raz=C3=B3n, no se aceptar=C3=A1 c=C3=B3digo de col= aboradores +an=C3=B3nimos (o seud=C3=B3nimos). Todos los colaboradores est=C3=A1n obli= gados a +=E2=80=9Cfirmar=E2=80=9D su c=C3=B3digo, indicando que el c=C3=B3digo pued= e ser distribuido con +el kernel bajo la GPL. El c=C3=B3digo que no ha sido licenciado como softw= are +libre por su propietario, o que corre el riesgo de crear problemas +relacionadas con los derechos de autor para el kernel (como el c=C3=B3digo= que +se deriva de esfuerzos de ingenier=C3=ADa inversa que carecen de las garan= t=C3=ADas +adecuadas) no puede ser contribuido. + +Las preguntas sobre cuestiones relacionadas con los derechos de autor son +comunes en las listas de correo de desarrollo de Linux. Normalmente, estas +preguntas no recibir=C3=A1n escasez de respuestas, pero se debe tener en c= uenta +que las personas que responden a esas preguntas no son abogados y no +pueden proporcionar consejo legal. Si tiene preguntas legales relacionadas +con el c=C3=B3digo fuente de Linux, no hay sustituto para hablar con un ab= ogado +que entienda este campo. Confiar en las respuestas obtenidas en listas +t=C3=A9cnicas de correo es un asunto arriesgado. diff --git a/Documentation/translations/sp_SP/process/2.Process.rst b/Docum= entation/translations/sp_SP/process/2.Process.rst new file mode 100644 index 000000000000..768c43dfd805 --- /dev/null +++ b/Documentation/translations/sp_SP/process/2.Process.rst @@ -0,0 +1,11 @@ +.. include:: ../disclaimer-sp.rst + +:Original: Documentation/process/2.Process.rst + +.. _sp_development_process: + +C=C3=B3mo funciona el proceso de desarrollo +=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 + +.. warning:: + TODO a=C3=BAn no traducido diff --git a/Documentation/translations/sp_SP/process/3.Early-stage.rst b/D= ocumentation/translations/sp_SP/process/3.Early-stage.rst new file mode 100644 index 000000000000..71cfb3fb0fda --- /dev/null +++ b/Documentation/translations/sp_SP/process/3.Early-stage.rst @@ -0,0 +1,11 @@ +.. include:: ../disclaimer-sp.rst + +:Original: Documentation/process/3.Early-stage.rst + +.. _sp_development_early_stage: + +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 + +.. warning:: + TODO a=C3=BAn no traducido diff --git a/Documentation/translations/sp_SP/process/4.Coding.rst b/Docume= ntation/translations/sp_SP/process/4.Coding.rst new file mode 100644 index 000000000000..d9436e039b4b --- /dev/null +++ b/Documentation/translations/sp_SP/process/4.Coding.rst @@ -0,0 +1,11 @@ +.. include:: ../disclaimer-sp.rst + +:Original: Documentation/process/4.Coding.rst + +.. _sp_development_coding: + +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 + +.. warning:: + TODO a=C3=BAn no traducido diff --git a/Documentation/translations/sp_SP/process/5.Posting.rst b/Docum= entation/translations/sp_SP/process/5.Posting.rst new file mode 100644 index 000000000000..50a3bc5998a8 --- /dev/null +++ b/Documentation/translations/sp_SP/process/5.Posting.rst @@ -0,0 +1,11 @@ +.. include:: ../disclaimer-sp.rst + +:Original: Documentation/process/5.Posting.rst + +.. _sp_development_posting: + +Publicar parches +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +.. warning:: + TODO a=C3=BAn no traducido diff --git a/Documentation/translations/sp_SP/process/6.Followthrough.rst b= /Documentation/translations/sp_SP/process/6.Followthrough.rst new file mode 100644 index 000000000000..f0acf9082bb3 --- /dev/null +++ b/Documentation/translations/sp_SP/process/6.Followthrough.rst @@ -0,0 +1,11 @@ +.. include:: ../disclaimer-sp.rst + +:Original: Documentation/process/6.Followthrough.rst + +.. _sp_development_followthrough: + +Seguimiento +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +.. warning:: + TODO a=C3=BAn no traducido diff --git a/Documentation/translations/sp_SP/process/7.AdvancedTopics.rst = b/Documentation/translations/sp_SP/process/7.AdvancedTopics.rst new file mode 100644 index 000000000000..553759857339 --- /dev/null +++ b/Documentation/translations/sp_SP/process/7.AdvancedTopics.rst @@ -0,0 +1,11 @@ +.. include:: ../disclaimer-sp.rst + +:Original: Documentation/process/7.AdvancedTopics.rst + +.. _sp_development_advancedtopics: + +Temas avanzados +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +.. warning:: + TODO a=C3=BAn no traducido diff --git a/Documentation/translations/sp_SP/process/8.Conclusion.rst b/Do= cumentation/translations/sp_SP/process/8.Conclusion.rst new file mode 100644 index 000000000000..dd181cb8ec9a --- /dev/null +++ b/Documentation/translations/sp_SP/process/8.Conclusion.rst @@ -0,0 +1,11 @@ +.. include:: ../disclaimer-sp.rst + +:Original: Documentation/process/8.Conclusion.rst + +.. _sp_development_conclusion: + +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 + +.. warning:: + TODO a=C3=BAn no traducido diff --git a/Documentation/translations/sp_SP/process/development-process.r= st b/Documentation/translations/sp_SP/process/development-process.rst index 41616249aa9e..17fb168418ac 100644 --- a/Documentation/translations/sp_SP/process/development-process.rst +++ b/Documentation/translations/sp_SP/process/development-process.rst @@ -22,3 +22,5 @@ para entenderla. :caption: Contenido :numbered: :maxdepth: 2 + + 1.Intro --=20 2.34.1 From nobody Fri Dec 19 21:53:30 2025 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2047.outbound.protection.outlook.com [40.107.243.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5FC2F12DDBF; Tue, 5 Mar 2024 22:19:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=40.107.243.47 ARC-Seal: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709677177; cv=fail; b=eJFz0D6ntHqfoDopD0pNR8+53gRroX7ERcJecJnL5vZoymgLuICzjs+1dcvn93nPWYYoZ6m5h5Wj5i7xTviypN1EelIS2P0AGOXoNAiqfgQL937bpwVpdKfU/+DvLKkshmktfb7CF0pndfzEWHlRsVckZjwR/uzp4cFHfwHY0pI= ARC-Message-Signature: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709677177; c=relaxed/simple; bh=LhrufpR/yZM0v9fylAyS0qOMYqCkgRfP0kbofegZSqA=; h=From:To:CC:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Fnq5WO7zdP6kPQNJopXXpljisBSKjoohQe+V7BD3Z4fmf8oPNswQRBy840KfmpfXlLlKofgPxPD+dLT+j/kGTmwb6mjWBsv4aDPAhODxagVaJbMBH3O8vMy5C7DxbiyqiYmhCWjRYoBvZ3YnJxsLb6bX4FwA4iF9r5VXjMAA6MU= ARC-Authentication-Results: i=2; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amd.com; spf=fail smtp.mailfrom=amd.com; dkim=pass (1024-bit key) header.d=amd.com header.i=@amd.com header.b=wQRsmo+z; arc=fail smtp.client-ip=40.107.243.47 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amd.com Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=amd.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=amd.com header.i=@amd.com header.b="wQRsmo+z" ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lNlkWzWadyBCunpoS35IN+uBj1X8Y9QoTEP9DqTCXrXOvWvRvtsfC6N5Uk8fPBWSjBoLCwQlc1DvydIBfG4+SAHF3blAMQrrqE4wBvGhD3PFzDuOQ7WdP4AmR5Zq46CwAi3bOfC0nMw7GA/LX8tK5P3Y9sEIK4w0BG66w14XP/d3aTCMgWWvkrmErTI9g+IyrSGVnubNAT7xrxwx0WegpO3+gUpCGJ+V5GhBTrA4XIfLDSj0qDb3rhDN0sWq5Fty7u4ywR+C8ZkEZpV5/bdJMzeKhCvEtjwgs/hqil7Vefn1QbkRfwzznbhSlATCM6/qpgcnuSAFoKqoDibNOInqeQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=RDtO+SUJBnJFqyZz2FK7IyT9Pb+9/gborxjjkDRcGe0=; b=S4YksvU6ihKYoInPIBPrj9ygpYtktMGNnKoGnvvLFLZnx7wy/v45gLO/E2ek5DHFmcFpzpGh/nlAivXW+veN2KCSIHrP4WrPKCxbnrU5rYm5Sj5F7yxgEB2eMKgViuCyoNW22mdcXtD6nsKRQ7dLIb/f8DnUWGCWwMgbFwhqbNA2DsUZfXDVFxOoq9T0MofCEBK6+YzhrqTZtmqiMbMv8Du/qHOXFrgfPY9P9Dnhwf38fZDi7tC3Q6um52nU/ESs22fDD3dbiNxd7RiQUXUZNqb+1sR35Gz6bLitx+cn9Z2mfjtZ+r1Ia/jMvog+bK8kQNJJ/VCZsdV4lpTJu7CnBw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lwn.net smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RDtO+SUJBnJFqyZz2FK7IyT9Pb+9/gborxjjkDRcGe0=; b=wQRsmo+zWSebPjh8fJS0f6gcYJ4wRNwpvkXvKpMQL67rMyWeScnPVlu3z5Zdg5+S26NqCVbPDSZemDm5zW0NNm2JZZWEQDikxwiLLRympepCtXL1HJf2oOcayfnvhDJdzg1C/NOexvOO39wQ98KxEBCMnVsE34NEf2Qx6ed1re4= Received: from CH2PR03CA0016.namprd03.prod.outlook.com (2603:10b6:610:59::26) by DM4PR12MB5843.namprd12.prod.outlook.com (2603:10b6:8:66::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7339.39; Tue, 5 Mar 2024 22:19:30 +0000 Received: from CH1PEPF0000AD83.namprd04.prod.outlook.com (2603:10b6:610:59:cafe::e1) by CH2PR03CA0016.outlook.office365.com (2603:10b6:610:59::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7339.39 via Frontend Transport; Tue, 5 Mar 2024 22:19:29 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C Received: from SATLEXMB04.amd.com (165.204.84.17) by CH1PEPF0000AD83.mail.protection.outlook.com (10.167.244.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7362.11 via Frontend Transport; Tue, 5 Mar 2024 22:19:29 +0000 Received: from titanite-d354host.amd.com (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Tue, 5 Mar 2024 16:19:28 -0600 From: Avadhut Naik To: CC: , , , Subject: [PATCH 4/4] docs/sp_SP: Add translation of process/2.Process.rst Date: Tue, 5 Mar 2024 16:18:39 -0600 Message-ID: <20240305221839.2764380-5-avadhut.naik@amd.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20240305221839.2764380-1-avadhut.naik@amd.com> References: <20240305221839.2764380-1-avadhut.naik@amd.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 X-ClientProxiedBy: SATLEXMB03.amd.com (10.181.40.144) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH1PEPF0000AD83:EE_|DM4PR12MB5843:EE_ X-MS-Office365-Filtering-Correlation-Id: 77e27ff4-7174-4f0a-2365-08dc3d625346 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: e1Z/ZhdP2iq09B+IyDQrtCbrd/4FmBYVIFsZmw2mAHwaixQeW2XgklbWsg6hyXAec8TVdMY8ij1u40QKXXx3ZLl3Vb9BYMI9ZX5tbUm2aGU7YaUX5+G2KW83LmKiyr1yTrpMqzhGiDPrkEKJjsncBAf120koXqxC3ve1+Ab7/KSVHVdd0wWBUEmlPlm9Zo3ujxqT0k7ZaEu/Vawb6NOPdLdEV1tmyqutGaBWC87OV3C+DemiDBu7zt4Iofg8LEZUEtXX+oGWDLNqehXeNrAWS81fvPgAB3FcKpPmHIQgtu0vhgy0PAYqcVCHc1XYRW1s7mAPEibIZwVpk81LW2vxwSX4/xKFcsdd8H6CqaQCojGei27hQ9Rz9+bFFA5e2V2qViSMePGB7XluSmcdlHifvZ3s3cZwtojwgZhyleLgKm07RH3mDwS9092Tt/Fd3iH1fe2xzoFXv6HBZ2kklaJYcBV4+icBVA7Vqv3J/B6RcumaFPfbgMY8Kp8khUCP5rgDxAXULpJCSMa5JFQBXJjdvRKDoiWVkWKR+EVLFfRLSf81q4hJkdLtXEMnh5gOuQT5+vy0LvMOYnvL2OnPkNehTsyEfpMt+U3Khp/K0f/w90Cdzd9RhuFA5GUsAfCyyfrXK88xDDJCNhDgSTF/c6hY+WxydzF4dHYZWcrQfpZWxeWfoO4HlUVFowLvtv/IfAcWhnm9147LCD7l8dMJmkkB1w== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:es;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(36860700004)(376005)(82310400014);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Mar 2024 22:19:29.2337 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 77e27ff4-7174-4f0a-2365-08dc3d625346 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CH1PEPF0000AD83.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR12MB5843 Translate Documentation/process/2.Process.rst into Spanish Signed-off-by: Avadhut Naik Reviewed-by: Carlos Bilbao --- .../translations/sp_SP/process/2.Process.rst | 535 +++++++++++++++++- .../sp_SP/process/development-process.rst | 1 + 2 files changed, 534 insertions(+), 2 deletions(-) diff --git a/Documentation/translations/sp_SP/process/2.Process.rst b/Docum= entation/translations/sp_SP/process/2.Process.rst index 768c43dfd805..5993eed71563 100644 --- a/Documentation/translations/sp_SP/process/2.Process.rst +++ b/Documentation/translations/sp_SP/process/2.Process.rst @@ -1,11 +1,542 @@ .. include:: ../disclaimer-sp.rst =20 :Original: Documentation/process/2.Process.rst +:Translator: Avadhut Naik =20 .. _sp_development_process: =20 C=C3=B3mo funciona el proceso de desarrollo =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 -.. warning:: - TODO a=C3=BAn no traducido +El desarrollo del kernel de Linux a principios de la d=C3=A9cada de 1990 f= ue +un asunto relajado, con un n=C3=BAmero relativamente peque=C3=B1o de usuar= ios y +desarrolladores involucrados. Con una base de usuarios en los millones y +alrededor de 2,000 desarrolladores involucrados durante un a=C3=B1o, el ke= rnel +ha tenido que adaptar varios procesos para mantener el desarrollo sin +problemas. Se requiere una comprensi=C3=B3n solida de c=C3=B3mo funciona e= l proceso +para ser una parte efectiva del mismo. + +El panorama general +------------------- + +Los desarrolladores del kernel utilizan un proceso de lanzamiento basado +en el tiempo de manera flexible, con uno nuevo lanzamiento principal del +kernel ocurriendo cada dos o tres meses. El historial reciente de +lanzamientos se ve as=C3=AD: + + =3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D + 5.0 Marzo 3, 2019 + 5.1 Mayo 5, 2019 + 5.2 Julio 7, 2019 + 5.3 Septiembre 15, 2019 + 5.4 Noviembre 24, 2019 + 5.5 Enero 6, 2020 + =3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D + +Cada lanzamiento 5.x es un lanzamiento principal del kernel con nuevas +caracter=C3=ADsticas, cambios internos en la API y m=C3=A1s. Un lanzamient= o t=C3=ADpico +puede contener alrededor de 13,000 conjuntos de cambios incluyendo en +varias centenas de miles de l=C3=ADneas de c=C3=B3digo. 5.x es la vanguard= ia del +desarrollo del kernel de Linux; el kernel utiliza un modelo de desarrollo +continuo que est=C3=A1 integrando continuamente cambios importantes. + +Se sigue una disciplina relativamente sencilla con respecto a la fusi=C3= =B3n +de parches para cada lanzamiento. Al comienzo de cada ciclo de desarrollo, +se dice que la "merge window" (ventana de fusi=C3=B3n) est=C3=A1 abierta. = En ese +momento, el c=C3=B3digo que se considera lo suficientemente estable (y que= es +aceptado por la comunidad de desarrollo) se fusiona en el kernel mainline. +La mayor parte de los cambios para un nuevo ciclo de desarrollo (y todos +los cambios principales) se fusionar=C3=A1n durante este tiempo, a un ritmo +cercano a los 1,000 cambios (=E2=80=9Cparches=E2=80=9D o =E2=80=9Cconjunto= s de cambios=E2=80=9D) por +d=C3=ADa. + +(Aparte, vale la pena se=C3=B1alar que los cambios integrados durante la +ventana de fusi=C3=B3n no surgen de la nada; han sido recolectados, probad= os +y montados con anticipaci=C3=B3n. Como funciona ese proceso se describir= =C3=A1 en +detalle m=C3=A1s adelante). + +La ventana de fusi=C3=B3n dura aproximadamente dos semanas. Al final de es= te +tiempo, Linux Torvalds declarar=C3=A1 que la ventana est=C3=A1 cerrada y p= ublicar=C3=A1 +el primero de los kernels =E2=80=9Crc=E2=80=9D. Para el kernel destinado a= ser 5.6, por +ejemplo, el lanzamiento al final de la ventana de fusi=C3=B3n se llamar=C3= =A1 +5.6-rc1. El lanzamiento -rc1 se=C3=B1ala que el tiempo para fusionar nuevas +caracter=C3=ADsticas ha pasado y que el tiempo para estabilizar el siguien= te +kernel ha comenzado. + +Durante las pr=C3=B3ximas seis a diez semanas, solo los parches que soluci= onen +problemas deben enviarse al mainline. En ocasiones, se permitir=C3=A1 un c= ambio +m=C3=A1s significativo, pero tales ocasiones son raras; los desarrolladore= s que +intentan fusionar nuevas caracter=C3=ADsticas fuera de la ventana de fusi= =C3=B3n +suelen recibir una recepci=C3=B3n poco amistosa. Como regla general, si se +pierde la ventana de fusi=C3=B3n de una caracter=C3=ADstica determinada, l= o mejor +que puede hacer es esperar al siguiente ciclo de desarrollo. (Se hace una +excepci=C3=B3n ocasional para los drivers de hardware que no se admit=C3= =ADa +anteriormente; si no afectan a ning=C3=BAn c=C3=B3digo en =C3=A1rbol, no p= ueden causar +regresiones y deber=C3=ADa ser seguro agregarlos en cualquier momento). + +A medida que las correcciones se abren paso en el mainline, la tasa de +parches se ralentizar=C3=A1 con el tiempo. Linus lanza nuevos kernels -rc +aproximadamente una vez a la semana; una serie normal llegar=C3=A1 a alg= =C3=BAn +punto entre -rc6 y -rc9 antes de que se considere que el kernel es +suficientemente estable y realice el lanzamiento final. En ese momento, +todo el proceso vuelve a empezar. + +Como ejemplo, as=C3=AD fue el ciclo de desarrollo de 5.4 (todas las fechas= son +de 2019): + + =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D + Septiembre 15 5.3 lanzamiento estable + Septiembre 30 5.4-rc1, la ventana de fusion se cierra + Octubre 6 5.4-rc2 + Octubre 13 5.4-rc3 + Octubre 20 5.4-rc4 + Octubre 27 5.4-rc5 + Noviembre 3 5.4-rc6 + Noviembre 10 5.4-rc7 + Noviembre 17 5.4-rc8 + Noviembre 24 5.4 lanzamiento estable + =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D + +=C2=BFC=C3=B3mo deciden los desarrolladores cu=C3=A1ndo cerrar el ciclo de= desarrollo +y crear el lanzamiento estable? La m=C3=A9trica m=C3=A1s significativa uti= lizada +es la lista de regresiones de lanzamientos anteriores. Ningunos errores +son bienvenidos, pero aquellos que rompen sistemas que funcionaron en el +pasado se consideran especialmente graves. Por esta raz=C3=B3n, los parches +que causan regresiones se ven con malos ojos y es bastante probable que +se reviertan durante el periodo de estabilizaci=C3=B3n. + +El objetivo de los desarrolladores es corregir todas las regresiones +conocidas antes de que se realice el lanzamiento estable. En el mundo +real, este tipo de perfecci=C3=B3n es dif=C3=ADcil de lograr; hay demasiad= os +variables en un proyecto de este tama=C3=B1o. Llega un punto en el que +retrasar el lanzamiento final solo empeora el problema; la pila de cambios +que esperan la siguiente ventana de fusi=C3=B3n crecer=C3=A1, creando a=C3= =BAn m=C3=A1s +regresiones la pr=C3=B3xima vez. Por lo tanto, la mayor=C3=ADa de los kern= els 5.x +se lanzan con un punado de regresiones conocidas, aunque, con suerte, +ninguna de ellas es seria. + +Una vez que se realiza un lanzamiento estable, su mantenimiento continuo +se transfiere al =E2=80=9Cequipo estable=E2=80=9D, actualmente encabezado = por Greg +Kroah-Hartman. El equipo estable lanzar=C3=A1 actualizaciones ocasionales = al +lanzamiento estable utilizando el esquema de numeraci=C3=B3n 5.x.y. Para s= er +considerado para un lanzamiento de actualizaci=C3=B3n, un parche debe +(1) corregir un error significativo y (2) ya estar fusionado en el +mainline para el siguiente kernel de desarrollo. Por lo general, los +kernels recibir=C3=A1n actualizaciones estables durante un poco m=C3=A1s d= e un +ciclo de desarrollo despu=C3=A9s de su lanzamiento inicial. As=C3=AD, por = ejemplo, +la historia del kernel 5.2 se ve=C3=ADa as=C3=AD (todas las fechas en 2019= ): + + =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=3D=3D=3D=3D + Julio 7 5.2 lanzamiento estable + Julio 14 5.2.1 + Julio 21 5.2.2 + Julio 26 5.2.3 + Julio 28 5.2.4 + Julio 31 5.2.5 + ... ... + Octubre 11 5.2.21 + =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=3D=3D=3D=3D + +5.2.21 fue la =C3=BAltima actualizaci=C3=B3n estable del lanzamiento 5.2. + +Algunos kernels se designan como kernels =E2=80=9Ca largo plazo=E2=80=9D; = recibir=C3=A1n +soporte durante un periodo m=C3=A1s largo. Consulte el siguiente enlace pa= ra +obtener la lista de versiones activas del kernel a largo plazos y sus +maintainers: + + https://www.kernel.org/category/releases.html + +La selecci=C3=B3n de un kernel para soporte a largo plazo es puramente una +cuesti=C3=B3n de que un maintainer tenga la necesidad y el tiempo para +mantener ese lanzamiento. No hay planes conocidos para ofrecer soporte a +largo plazo para ning=C3=BAn lanzamiento especifico pr=C3=B3ximo. + +Ciclo de vida de un parche +-------------------------- + +Los parches no van directamente desde el teclado del desarrollador al +kernel mainline. Hay, en cambio, un proceso algo complicado (aunque algo +informal) dise=C3=B1ado para garantizar que cada parche sea revisado en cu= anto +a calidad y que cada parche implemente un cambio que es deseable tener en +el mainline. Este proceso puede ocurrir r=C3=A1pidamente para correcciones +menores, o, en el caso de cambios grandes y controvertidos, continuar +durante a=C3=B1os. Gran parte de la frustraci=C3=B3n de los desarrolladore= s proviene +de la falta de compresi=C3=B3n de este proceso o de sus intentos de eludir= lo. + +Con la esperanza de reducir esa frustraci=C3=B3n, este documento describir= =C3=A1 +c=C3=B3mo un parche entra en el kernel. Lo que sigue a continuaci=C3=B3n e= s una +introducci=C3=B3n que describe el proceso de una manera tanto idealizada. = Un +tratamiento mucho m=C3=A1s detallado vendr=C3=A1 en secciones posteriores. + +Las etapas por las que pasa un parche son, generalmente: + + - Dise=C3=B1o. Aqu=C3=AD es donde se establecen los requisitos reales par= a el + parche =E2=80=93 y la forma en que se cumplir=C3=A1n esos requisitos. E= l trabajo + de dise=C3=B1o a menudo se realiza sin involucrar a la comunidad, pero = es + mejor hacer este trabajo de manera abierta si es posible; puede ahorrar + mucho tiempo redise=C3=B1ando las cosas m=C3=A1s tarde. + + - Revisi=C3=B3n inicial. Los parches se publican en la lista de correo + relevante y los desarrolladores en esa lista responden con cualquier + comentario que puedan tener. Este proceso deber=C3=ADa revelar cualquier + problema importante con un parche si todo va bien. + + - Revisi=C3=B3n m=C3=A1s amplia. Cuando el parche se acerca a estar listo= para su + inclusi=C3=B3n en el mainline, debe ser aceptado por un maintainer del + subsistema relevante =E2=80=93 aunque esta aceptaci=C3=B3n no es una ga= rant=C3=ADa de + que el parche llegara hasta el mainline. El parche aparecer=C3=A1 en el + =C3=A1rbol de subsistemas del maintainer y en los =C3=A1rboles -next (d= escritos + a continuaci=C3=B3n). Cuando el proceso funciona, este paso conduce a u= na + revisi=C3=B3n exhaustiva del parche y al descubrimiento de cualquier + problema resultante de la integraci=C3=B3n de este parche con el trabajo + realizado por otros. + + - Tenga en cuenta que la mayor=C3=ADa de los maintainers tambi=C3=A9n tie= nen + trabajos diurnos, por lo que fusionar su parche no puede ser su m=C3=A1= xima + prioridad. Si su parche est=C3=A1 recibiendo comentarios sobre los camb= ios + que se necesitan, deber=C3=ADa realizar esos cambios o justificar por q= u=C3=A9 + no deber=C3=ADan realizarse. Si su parche no tiene quejas de revisi=C3= =B3n, pero + no est=C3=A1 siendo fusionado por el maintainer apropiado del subsistem= a o + del driver, debe ser persistente en la actualizaci=C3=B3n del parche + al kernel actual para que se aplique limpiamente y seguir envi=C3=A1ndo= lo + para su revisi=C3=B3n y fusi=C3=B3n. + + - Fusi=C3=B3n en el mainline. Eventualmente, un parche exitoso se fusiona= r=C3=A1 + en el repositorio mainline administrado por Linux Torvalds. Mas + comentarios y/o problemas pueden surgir en este momento; es importante + que el desarrollador responda a estos y solucione cualquier problema + que surja. + + - Lanzamiento estable. El n=C3=BAmero de usuarios potencialmente afectado= s por + el parche es ahora grande, por lo que, una vez m=C3=A1s, pueden surgir + nuevos problemas. + + - Mantenimiento a largo plazo. Si bien un desarrollador puede olvidarse + del c=C3=B3digo despu=C3=A9s de fusionarlo, ese comportamiento tiende a= dejar + una impresi=C3=B3n negativa en la comunidad de desarrollo. Fusionar el + c=C3=B3digo elimina parte de la carga de mantenimiento; otros soluciona= r=C3=A1n + los problemas causados por los cambios en la API. Sin embargo, el + desarrollador original debe seguir asumiendo la responsabilidad del + c=C3=B3digo si quiere seguir siendo =C3=BAtil a largo plazo. + +Uno de los peores errores cometidos por los desarrolladores del kernel +(o sus empleadores) es tratar de reducir el proceso a un solo paso de +=E2=80=9Cfusi=C3=B3n en el mainline=E2=80=9D. Este enfoque conduce invaria= blemente a la +frustraci=C3=B3n de todos los involucrados. + +C=C3=B3mo se integran los parches en el kernel +----------------------------------------- + +Hay exactamente una persona que puede fusionar parches en el repositorio +mainline del kernel: Linus Torvalds. Pero, por ejemplo, de los m=C3=A1s de +9,500 parches que se incluyeron en el kernel 2.6.38, solo 112 (alrededor +del 1.3%) fueron elegidos directamente por Linus mismo. El proyecto del +kernel ha crecido mucho desde hace tiempo a un tama=C3=B1o en el que ning= =C3=BAn +desarrollador individual podr=C3=ADa inspeccionar y seleccionar todos los +parches sin ayuda. La forma que los desarrolladores del kernel han +abordado este crecimiento es a trav=C3=A9s del uso de un sistema jer=C3=A1= rquico +alrededor de una cadena de confianza. + +La base de c=C3=B3digo del kernel se descompone l=C3=B3gicamente en un con= junto de +subsistemas: redes, soporte de arquitectura especifica, gesti=C3=B3n de +memoria, dispositivos de video, etc. La mayor=C3=ADa de los subsistemas ti= enen +un maintainer designado, un desarrollador que tiene la responsabilidad +general del c=C3=B3digo dentro de ese subsistema. Estos maintainers de +subsistemas son los guardianes (en cierto modo) de la parte del kernel que +gestionan; son los que (usualmente) aceptar=C3=A1n un parche para incluirl= o en +el kernel mainline. + +Cada uno de los maintainers del subsistema administra su propia versi=C3= =B3n +del =C3=A1rbol de fuentes del kernel, generalmente (pero, ciertamente no +siempre) usando la herramienta de administraci=C3=B3n de c=C3=B3digo fuent= e de git. +Herramientas como git (y herramientas relacionadas como quilt o mercurial) +permiten a los maintainers realizar un seguimiento de una lista de +parches, incluida la informaci=C3=B3n de autor=C3=ADa y otros metadatos. En +cualquier momento, el maintainer puede identificar qu=C3=A9 parches de su +repositorio no se encuentran en el mainline. + +Cuando se abre la ventana de fusi=C3=B3n, los maintainers de nivel superior +le pedir=C3=A1n a Linus que =E2=80=9Cextraiga=E2=80=9D los parches que han= seleccionado para +fusionar de sus repositorios. Si Linus est=C3=A1 de acuerdo, el flujo de +parches fluir=C3=A1 hacia su repositorio, convirti=C3=A9ndose en parte del= kernel +mainline. La cantidad de atenci=C3=B3n que Linus presta a los parches +espec=C3=ADficos recibidos en una operaci=C3=B3n de extracci=C3=B3n varia.= Est=C3=A1 claro +que, a veces, examina bastante de cerca. Pero, como regla general, Linus +conf=C3=ADa en que los maintainers del subsistema no env=C3=ADen parches +defectuosos al upstream. + +Los maintainers de subsistemas, a su vez, pueden extraer parches de otros +maintainers. Por ejemplo, el =C3=A1rbol de red se construye a partir de +parches que se acumulan primero en arboles dedicados a drivers de +dispositivos de red, redes inal=C3=A1mbricas, etc. Esta cadena de reposito= rios +puede ser arbitrariamente larga, aunque rara vez supera los dos o tres +enlaces. Dado que cada maintainer de la cadena conf=C3=ADa en los que +administran =C3=A1rboles de nivel inferior, este proceso se conoce como la +=E2=80=9Ccadena de confianza=E2=80=9D. + +Claramente, en un sistema como este, lograr que los parches se integren +en el kernel depende de encontrar el maintainer adecuado. Enviar parches +directamente a Linus no es normalmente la forma correcta de hacerlo. + +=C3=81rboles siguientes (next) +------------------------- + +La cadena de =C3=A1rboles de subsistemas gu=C3=ADa el flujo de parches en = el +kernel, pero tambi=C3=A9n plantea una pregunta interesante: =C2=BFQu=C3=A9= pasa si +alguien quiere ver todos los parches que se est=C3=A1n preparando para la +pr=C3=B3xima ventana de fusi=C3=B3n? Los desarrolladores estar=C3=A1n inte= resados en +saber que otros cambios est=C3=A1n pendientes para ver si hay alg=C3=BAn c= onflicto +del que preocuparse; un parche que cambia un prototipo de funci=C3=B3n del +n=C3=BAcleo del kernel, por ejemplo, entrar=C3=A1 en conflicto con cualqui= er otro +parche que utilice la forma anterior de esa funci=C3=B3n. Los revisores y +probadores quieren tener acceso a los cambios en su forma integrada antes +de que todos esos cambios se integren en el kernel mainline. Uno podr=C3= =ADa +extraer cambios de todos los =C3=A1rboles de subsistemas interesantes, pero +eso ser=C3=ADa un trabajo tedioso y propenso a errores. + +La respuesta viene en forma de =C3=A1rboles -next, donde los =C3=A1rboles = de +subsistemas se recopilan para pruebas y revisiones. El m=C3=A1s antiguo de +estos =C3=A1rboles, mantenido por Andrew Morton, se llama =E2=80=9C-mm=E2= =80=9D (por gesti=C3=B3n +de la memoria, que es como comenz=C3=B3). El =C3=A1rbol =E2=80=9C-mm=E2=80= =9D integra parches +de una larga lista de =C3=A1rboles de subsistemas; tambi=C3=A9n tiene algu= nos +parches destinados a ayudar con la depuraci=C3=B3n. + +M=C3=A1s all=C3=A1 de eso, -mm contiene una colecci=C3=B3n significativa d= e parches +que han sido seleccionados directamente por Andrew. Estos parches pueden +haber sido publicados en una lista de correo o aplicarse a una parte del +kernel para la que no hay un =C3=A1rbol de subsistemas designado. Como +resultado, -mm funciona como una especie de =C3=A1rbol de subsistemas de +=C3=BAltimo recurso; si no hay otro camino obvio para un parche en el main= line, +es probable que termine en -mm. Los parches miscel=C3=A1neos que se acumul= an +en -mm eventualmente se enviar=C3=A1n a un =C3=A1rbol de subsistema apropi= ado o se +enviar=C3=A1n directamente a Linus. En un ciclo de desarrollo t=C3=ADpico, +aproximadamente el 5-10% de los parches que van al mainline llegan all=C3= =AD +a trav=C3=A9s de -mm. + +El parche -mm actual est=C3=A1 disponible en el directorio =E2=80=9Cmmotm= =E2=80=9D (-mm +del momento) en: + + https://www.ozlabs.org/~akpm/mmotm/ + +Sin embargo, es probable que el uso del =C3=A1rbol MMOTM sea una experienc= ia +frustrante; existe una posibilidad definitiva de que ni siquiera se +compile. + +El =C3=A1rbol principal para la fusi=C3=B3n de parches del siguiente ciclo= es +linux-next, mantenido por Stephen Rothwell. El =C3=A1rbol linux-next es, p= or +dise=C3=B1o, una instant=C3=A1nea de c=C3=B3mo se espera que se vea el mai= nline despu=C3=A9s +de que se cierre la siguiente ventana de fusi=C3=B3n. Los =C3=A1rboles lin= ux-next +se anuncian en las listas de correo linux-kernel y linux-next cuando se +ensamblan; Se pueden descargar desde: + + https://www.kernel.org/pub/linux/kernel/next/ + +Linux-next se ha convertido en una parte integral del proceso de +desarrollo del kernel; todos los parches fusionados durante una ventana +de fusi=C3=B3n determinada deber=C3=ADan haber encontrado su camino en lin= ux-next +en alg=C3=BAn momento antes de que se abra la ventana de fusi=C3=B3n. + +=C3=81rboles de staging +------------------ + +El =C3=A1rbol de fuentes del kernel contiene el directorio drivers/staging= /, +donde residen muchos subdirectorios para drivers o sistemas de archivos +que est=C3=A1n en proceso de ser agregados al =C3=A1rbol del kernel. Perma= necen +en drivers/staging mientras a=C3=BAn necesitan m=C3=A1s trabajo; una vez +completados, se pueden mover al kernel propiamente dicho. Esta es una +forma de realizar un seguimiento de los drivers drivers que no est=C3=A1n = a la +altura de la codificaci=C3=B3n o los est=C3=A1ndares de calidad del kernel= de +Linux, pero que las personas pueden querer usarlos y realizar un +seguimiento del desarrollo. + +Greg Kroah-Hartman mantiene actualmente el =C3=A1rbol de staging. Los driv= ers +que aun necesitan trabajo se le env=C3=ADan, y cada driver tiene su propio +subdirectorio en drivers/staging/. Junto con los archivos de origen del +driver, tambi=C3=A9n debe haber un archivo TODO en el directorio. El archi= vo +TODO enumera el trabajo pendiente que el driver necesita para ser aceptado +en el kernel propiamente dicho, as=C3=AD como una lista de personas a las = que +Cc=E2=80=99d para cualquier parche para el driver. Las reglas actuales exi= gen +que los drivers que contribuyen a staging deben, como m=C3=ADnimo, compila= rse +correctamente. + +El staging puede ser una forma relativamente f=C3=A1cil de conseguir nuevos +drivers en el mainline donde, con suerte, llamar=C3=A1n la atenci=C3=B3n d= e otros +desarrolladores y mejorar=C3=A1n r=C3=A1pidamente. Sin embargo, la entrada= en el +staging no es el final de la historia; el c=C3=B3digo que no est=C3=A1 vie= ndo +progreso regular eventualmente ser=C3=A1 eliminado. Los distribuidores tam= bi=C3=A9n +tienden a ser relativamente reacios a habilitar los drivers de staging. +Por lo tanto, el staging es, en el mejor de los casos, una parada en el +camino para hacia convertirse en un apropiado driver del mainline. + +Herramientas +------------ + +Como se puede ver en el texto anterior, el proceso de desarrollo del +kernel depende en gran medida de la capacidad de dirigir colecciones de +parches en varias direcciones. Todo ello no funcionar=C3=ADa tan bien como= lo +hace sin herramientas apropiadamente potentes. Los tutoriales sobre c=C3= =B3mo +usar estas herramientas est=C3=A1n mucho m=C3=A1s all=C3=A1 del alcance de= este +documento, pero hay espacio para algunos consejos. + +Con mucho, el sistema de gesti=C3=B3n de c=C3=B3digo fuente dominante util= izado +por la comunidad del kernel es git. Git es uno de los varios sistemas de +control de versiones distribuidos que se est=C3=A1n desarrollando en la +comunidad de software libre. Est=C3=A1 bien ajustado para el desarrollo de +kernel, ya que funciona bastante bien cuando se trata de grandes +repositorios y grandes cantidades de parches. Tambi=C3=A9n tiene la reputa= ci=C3=B3n +de ser dif=C3=ADcil de aprender y usar, aunque ha mejorado con el tiempo. +Alg=C3=BAn tipo de familiaridad con git es casi un requisito para los +desarrolladores del kernel; incluso si no lo usan para su propio +trabajo, necesitar=C3=A1n git para mantenerse al d=C3=ADa con lo que otros +desarrolladores (y el mainline) est=C3=A1n haciendo. + +Git ahora est=C3=A1 empaquetado por casi todas las distribuciones de Linux. +Hay una p=C3=A1gina de inicio en: + + https://git-scm.com/ + +Esa p=C3=A1gina tiene punteros a documentaci=C3=B3n y tutoriales. + +Entre los desarrolladores de kernel que no usan git, la opci=C3=B3n m=C3= =A1s +popular es casi con certeza Mercurial: + + https://www.selenic.com/mercurial/ + +Mercurial comparte muchas caracter=C3=ADsticas con git, pero proporciona u= na +interfaz que muchos encuentran m=C3=A1s f=C3=A1cil de usar. + +Otra herramienta que vale la pena conocer es Quilt: + + https://savannah.nongnu.org/projects/quilt/ + +Quilt es un sistema de gesti=C3=B3n de parches, en lugar de un sistema de +gesti=C3=B3n de c=C3=B3digo fuente. No rastrea el historial a lo largo del= tiempo; +en cambio, est=C3=A1 orientado al seguimiento de un conjunto especifico de +cambios en relaci=C3=B3n con una base de c=C3=B3digo en evoluci=C3=B3n. Al= gunos de los +principales maintainers de subsistemas utilizan Quilt para gestionar los +parches destinados a ir upstream. Para la gesti=C3=B3n de ciertos tipos de +=C3=A1rboles (por ejemplo, -mm) Quilt es la mejor herramienta para el trab= ajo. + +Listas de correo +---------------- + +Una gran parte del trabajo de desarrollo del kernel de Linux se realiza a +trav=C3=A9s de listas de correo. Es dif=C3=ADcil ser un miembro plenamente= funcional +de la comunidad sin unirse al menos a una lista en alg=C3=BAn parte. Pero = las +listas de correo de Linux tambi=C3=A9n representan un peligro potencial pa= ra +los desarrolladores, que corren el riesgo de quedar enterrados bajo una +carga de correo electr=C3=B3nico, incumplir las convenciones utilizadas en= las +listas de Linux, o ambas cosas. + +La mayor=C3=ADa de las listas de correo del kernel se ejecutan en +vger.kernel.org; la lista principal se puede encontrar en: + + http://vger.kernel.org/vger-lists.html + +Sim embargo, hay listas alojadas en otros lugares; varios de ellos se +encuentran en redhat.com/mailman/listinfo. + +La lista de correo principal para el desarrollo del kernel es, por +supuesto, linux-kernel. Esta lista es un lugar intimidante; el volumen +puede alcanzar 500 mensajes por d=C3=ADa, la cantidad de ruido es alta, la +conversaci=C3=B3n puede ser muy t=C3=A9cnica y los participantes no siempr= e se +preocupan por mostrar un alto grado de cortes=C3=ADa. Pero no hay otro lug= ar +donde la comunidad de desarrollo del kernel se re=C3=BAna como un todo; los +desarrolladores que eviten esta lista se perder=C3=A1n informaci=C3=B3n im= portante. + +Hay algunos consejos que pueden ayudar a sobrevivir en el kernel de Linux: + +- Haga que la lista se entregue en una carpeta separada, en lugar de su + buz=C3=B3n principal. Uno debe ser capaz de ignorar el flujo durante + periodos prolongados. + +- No trate de seguir cada conversaci=C3=B3n, nadie lo hace. Es importante + filtrar tanto por el tema de inter=C3=A9s (aunque tenga en cuenta que las + conversaciones prolongadas pueden alejarse del asunto original sin + cambiar la l=C3=ADnea de asunto del correo electr=C3=B3nico) por las per= sonas + que participan. + +- No alimente a los trolls. Si alguien est=C3=A1 tratando de provocar una + respuesta de enojo, ign=C3=B3relos. + +- Al responder al correo electr=C3=B3nico del kernel de Linux (o al de otr= as + listas) conserve el encabezado Cc: para todos los involucrados. En + ausencia de una raz=C3=B3n solida (como una solicitud expl=C3=ADcita), n= unca debe + eliminar destinarios. Aseg=C3=BArese siempre de que la persona a la que = est=C3=A1 + respondiendo est=C3=A9 en la lista Cc:. Esta convenci=C3=B3n tambi=C3=A9= n hace que no + sea necesario solicitar expl=C3=ADcitamente que se le copie en las respu= estas + a sus publicaciones. + +- Busque en los archivos de la lista (y en la red en su conjunto) antes + de hacer preguntas. Algunos desarrolladores pueden impacientarse con + las personas que claramente no han hecho sus deberes. + +- Utilice respuestas intercaladas (=E2=80=9Cen l=C3=ADnea=E2=80=9D), lo qu= e hace que su + respuesta sea m=C3=A1s f=C3=A1cil de leer. (Es decir, evite top-posting = =E2=80=93 la + pr=C3=A1ctica de poner su respuesta encima del texto citado al que est= =C3=A1 + respondiendo.) Para obtener m=C3=A1s informaci=C3=B3n, consulte + :ref:`Documentation/translations/sp_SP/process/submitting-patches.rst `. + +- Pregunte en la lista de correo correcta. linux-kernel puede ser el + punto de encuentro general, pero no es el mejor lugar para encontrar + desarrolladores de todos los subsistemas. + +El =C3=BAltimo punto, encontrar la lista de correo correcta, es una fuente +com=C3=BAn de errores para desarrolladores principiantes. Alguien que haga +una pregunta relacionada con las redes en linux-kernel seguramente +recibir=C3=A1 una surgencia educada para preguntar en la lista de netdev e= n su +lugar, ya que esa es la lista frecuentada por la mayor=C3=ADa de los +desarrolladores de redes. Existen otras listas para los subsistemas SCSI, +video4linux, IDE, sistema de archivos, etc. El mejor lugar para buscar +listas de correo es en el archivo MAINTAINERS incluido con el c=C3=B3digo +fuente del kernel. + +Comenzar con el desarrollo del kernel +------------------------------------- + +Las preguntas sobre como comenzar con el proceso de desarrollo del kernel +son comunes, tanto de individuos como de empresas. Igualmente comunes son +los pasos en falso que hacen que el comienzo de la relaci=C3=B3n sea m=C3= =A1s +dif=C3=ADcil de lo que tiene que ser. + +Las empresas a menudo buscan contratar desarrolladores conocidos para +iniciar un grupo de desarrollo. De hecho, esta puede ser una t=C3=A9cnica +efectiva. Pero tambi=C3=A9n tiende a ser caro y no hace mucho para crecer = el +grupo de desarrolladores de kernel experimentados. Es posible poner al +d=C3=ADa a los desarrolladores internos en el desarrollo de kernel de Linu= x, +dada la inversi=C3=B3n de alg=C3=BAn tiempo. Tomarse este tiempo puede dot= ar a un +empleador de un grupo de desarrolladores que comprendan tanto el kernel +como la empresa, y que tambi=C3=A9n puedan ayudar a educar a otros. A medio +plazo, este es a menudo el enfoque m=C3=A1s rentable. + +Los desarrolladores individuales, a menudo, comprensiblemente, no tienen +un lugar para empezar. Comenzar con un proyecto grande puede ser +intimidante; a menudo uno quiere probar las aguas con algo m=C3=A1s peque= =C3=B1o +primero. Este es el punto en el que algunos desarrolladores se lanzan a +la creaci=C3=B3n de parches para corregir errores ortogr=C3=A1ficos o prob= lemas +menores de estilo de codificaci=C3=B3n. Desafortunadamente, dicho parches +crean un nivel de ruido que distrae a la comunidad de desarrollo en su +conjunto, por lo que, cada vez m=C3=A1s, se los mira con desprecio. Los nu= evos +desarrolladores que deseen presentarse a la comunidad no recibir=C3=A1n la +recepci=C3=B3n que desean por estos medios. + +Andrew Morton da este consejo (traducido) para los aspirantes a +desarrolladores de kernel. + +:: + + El proyecto #1 para los principiantes en el kernel seguramente deber=C3= =ADa + ser =E2=80=9Caseg=C3=BArese de que el kernel funcione perfectamente en to= do momento + en todas las m=C3=A1quinas que pueda conseguir=E2=80=9D. Por lo general, = la forma + de hacer esto es trabajar con otros para arreglar las cosas (=C2=A1esto + puede requerir persistencia!), pero eso est=C3=A1 bien, es parte del + desarrollo del kernel. + +(https://lwn.net/Articles/283982/) + +En ausencia de problemas obvios que solucionar, se aconseja a los +desarrolladores que consulten las listas actuales de regresiones y errores +abiertos en general. Nunca faltan problemas que necesitan soluci=C3=B3n; al +abordar estos problemas, los desarrolladores ganar=C3=A1n experiencia con = el +proceso mientras, al mismo tiempo, se ganar=C3=A1n el respeto del resto de= la +comunidad de desarrollo. diff --git a/Documentation/translations/sp_SP/process/development-process.r= st b/Documentation/translations/sp_SP/process/development-process.rst index 17fb168418ac..40d74086f22e 100644 --- a/Documentation/translations/sp_SP/process/development-process.rst +++ b/Documentation/translations/sp_SP/process/development-process.rst @@ -24,3 +24,4 @@ para entenderla. :maxdepth: 2 =20 1.Intro + 2.Process --=20 2.34.1