Hola: Adjunto la página traducida. Un saludo, Rafa.
#use wml::debian::translation-check translation="2fe05a57dd331056b8916c4bef4163364bc741c0"
<define-tag pagetitle>Resolución General: sistemas de inicio y systemd</define-tag>
<define-tag status>V</define-tag>
# meanings of the <status> tag:
# P: proposed
# D: discussed
# V: voted on
# F: finished
# O: other (or just write anything else)
#use wml::debian::template title="<pagetitle>" BARETITLE="true" NOHEADER="true"
#use wml::debian::toc
#use wml::debian::votebar
<h1><pagetitle></h1>
<toc-display />
# The Tags beginning with v are will become H3 headings and are defined in
# english/template/debian/votebar.wml
# all possible Tags:
# vdate, vtimeline, vnominations, vdebate, vplatforms,
# Proposers
# vproposer, vproposera, vproposerb, vproposerc, vproposerd,
# vproposere, vproposerf
# Seconds
# vseconds, vsecondsa, vsecondsb, vsecondsc, vsecondsd, vsecondse,
# vsecondsf, vopposition
# vtext, vtextb, vtextc, vtextd, vtexte, vtextf
# vchoices
# vamendments, vamendmentproposer, vamendmentseconds, vamendmenttext
# vproceedings, vmajorityreq, vstatistics, vquorum, vmindiscuss,
# vballot, vforum, voutcome
<vtimeline />
<table class="vote">
<tr>
<th>Propuesta y enmienda</th>
<td>16-11-2019</td>
<td></td>
</tr>
<tr>
<th>Periodo de debate:</th>
<td>22-11-2019</td>
<td></td>
</tr>
<tr>
<th>Periodo de votación:</th>
<td>Sábado 07-12-2019 00:00:00 UTC</td>
<td>Viernes 27-12-2019 23:59:59 UTC</td>
</tr>
</table>
El líder del proyecto ha modificado el periodo de debate: el periodo de
debate mínimo finaliza el 30 de noviembre. [<a
href='https://lists.debian.org/debian-vote/2019/11/msg00189.html'>correo</a>]
<vproposerf />
<p>Martin Michlmayr [<email tbm@debian.org>]
[<a href='https://lists.debian.org/debian-vote/2019/11/msg00330.html'>texto de la propuesta</a>]
</p>
<vsecondsf />
<ol>
<li>Michael Biebl [<email biebl@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00331.html'>correo</a>] </li>
<li>Ansgar Burchardt [<email ansgar@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00332.html'>correo</a>] </li>
<li>Julien Cristau [<email jcristau@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00333.html'>correo</a>] </li>
<li>Enrico Zini [<email enrico@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00334.html'>correo</a>] </li>
<li>Matthias Klumpp [<email mak@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00335.html'>correo</a>] </li>
<li>Ana Beatriz Guerrero López [<email ana@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00337.html'>correo</a>] </li>
<li>Russ Allbery [<email rra@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00338.html'>correo</a>] </li>
<li>Intrigeri [<email intrigeri@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00341.html'>correo</a>] </li>
<li>Luca Filipozzi [<email lfilipoz@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00343.html'>correo</a>] </li>
<li>Moritz Mühlenhoff [<email jmm@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00346.html'>correo</a>] </li>
<li>Paul Tagliamonte [<email paultag@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00347.html'>correo</a>] </li>
<li>Jordi Mallach [<email jordi@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00348.html'>correo</a>] </li>
<li>Philipp Kern [<email pkern@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00350.html'>correo</a>] </li>
<li>Holger Levsen [<email holger@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00351.html'>correo</a>] </li>
<li>Jeremy Bicha [<email jbicha@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/12/msg00000.html'>correo</a>] </li>
</ol>
<vtextf />
<h3>Opción 1: F: Foco en systemd</h3>
<p>Esta resolución es una declaración de posicionamiento bajo la sección 4.1 (5) de la
Constitución de Debian:</p>
<p>Los estándares y la cooperación entre distribuciones son factores importantes en
la elección de tecnologías núcleo de Debian. Es importante reconocer
que el ecosistema Linux ha adoptado ampliamente systemd y que el nivel
de integración de tecnologías systemd en sistemas Linux aumentará
con el tiempo.</p>
<p>Debian se enorgullece de soportar e integrar muchas tecnologías diferentes.
Con todo lo que hacemos tenemos que considerar los costes y los beneficios,
tanto para los usuarios y usuarias como en términos de los efectos sobre nuestra comunidad de desarrolladores y desarrolladoras.
Un sistema de inicio no es un componente aislado, sino que se integra profundamente en
la capa nuclear del sistema y afecta a muchos paquetes. Creemos que
los beneficios de soportar sistemas de inicio múltiples no superan a sus
costes.</p>
<p>Debian puede seguir proporcionando y explorando otros sistemas de inicio, pero
systemd es el único sistema de inicio soportado de forma oficial. Se pueden enviar
informes de fallo «wishlist» con parches, que los y las responsables de los paquetes deberían
revisar como el resto de informes de fallo con parches. Igual que con systemd, se
debería trabajar con los proyectos originales y en cooperación con otras distribuciones Linux
y de programas libres y de código abierto (FOSS por sus siglas en inglés) cuando sea posible. La prioridad es la estandarización
sin depender de complicadas capas de compatibilidad.</p>
<p>La integración de systemd de forma más profunda en Debian conducirá a un sistema
más integrado y probado, aumentará la estandarización de los sistemas Linux
y proporcionará muchas tecnologías nuevas a nuestros usuarios y usuarias. Los paquetes pueden depender de
funcionalidades proporcionadas por systemd, y se recomienda que hagan un completo uso
de las mismas. Las soluciones basadas en tecnologías de systemd permitirán una mayor
cooperación entre distribuciones. El proyecto trabajará en propuestas y
coordinará transiciones desde soluciones específicas de Debian en los casos apropiados.</p>
<vproposerb />
<p>Sam Hartman [<email hartmans@debian.org>]
[<a href='https://lists.debian.org/debian-vote/2019/11/msg00117.html'>texto de la propuesta</a>]
[<a href='https://lists.debian.org/debian-vote/2019/11/msg00293.html'>enmienda</a>]
</p>
<vsecondsb />
Esta enmienda ha sido presentada por el actual líder del proyecto y, por lo tanto, no precisa apoyos
# <ol>
# </ol>
<vtextb />
<h3>Opción 2: B: systemd pero apoyamos la exploración de alternativas</h3>
<p>Haciendo uso de la capacidad que le otorga la sección 4.1 (5) de la Constitución, el proyecto emite
la declaración siguiente que describe su posicionamiento actual respecto a los sistemas
de inicio, sistemas de inicio múltiples y uso de las utilidades de systemd. Esta
declaración describe el posicionamiento del proyecto en el momento de su
adopción. El posicionamiento del proyecto puede evolucionar con el tiempo sin que sea necesario
recurrir a nuevas resoluciones generales (RG). El procedimiento de RG seguirá estando
disponible si el proyecto necesita una decisión y no puede alcanzar un
consenso.
</p>
<p>El proyecto Debian reconoce que las unidades de servicio de systemd son la
configuración preferida para describir cómo arrancar un daemon o servicio.
Sin embargo, Debian continúa siendo un entorno en el que desarrolladores y desarrolladoras, y usuarios y usuarias pueden
explorar y desarrollar diferentes sistemas de inicio y alternativas a las funcionalidades
de systemd. Quienes estén interesados o interesadas en explorar tales alternativas tienen que
proporcionar los recursos de desarrollo y de empaquetamiento necesarios para llevar a cabo ese
trabajo. Tecnologías como elogind, que facilitan la exploración de
alternativas mientras se ejecuta software que depende de algunas interfaces
de systemd, siguen siendo importantes para Debian. Es importante que el
proyecto apoye el esfuerzo de los desarrolladores y desarrolladoras que trabajen en tales tecnologías
cuando haya coincidencia entre las mismas y el resto del
proyecto, por ejemplo revisando parches y participando en
debates de manera regular.
</p>
<p>Los paquetes deberían incluir unidades de servicio o scripts de inicio para arrancar daemons
y servicios. Los paquetes pueden utilizar cualquier utilidad de systemd
según el criterio del o de la responsable del paquete, siempre y cuando lo hagan de forma consistente con
otros requisitos del manual de normas y con la expectativa tradicional de que los paquetes
no deberían depender de funcionalidades experimentales o no soportadas (en Debian)
de otros paquetes. Los paquetes pueden incluir soporte para sistemas de inicio
alternativos además de para systemd y pueden incluir alternativas para cualquier
interfaz específica de systemd que usen. Los y las responsables utilizan sus procedimientos
normales para decidir qué parches incluir.
</p>
<p>Debian está comprometido con la colaboración con distribuciones derivadas que hagan diferentes
elecciones de sistemas de inicio. Como con todas nuestras interacciones con
los proyectos derivados, los y las resposables implicados e implicadas trabajarán con dichos proyectos para
entender qué cambios tiene sentido incorporar a Debian y cuáles
permanecen exclusivamente en la distribución derivada.
</p>
<vproposera />
<p>Sam Hartman [<email hartmans@debian.org>]
[<a href='https://lists.debian.org/debian-vote/2019/11/msg00257.html'>texto de la propuesta</a>]
[<a href='https://lists.debian.org/debian-vote/2019/11/msg00258.html'>enmienda</a>]
[<a href='https://lists.debian.org/debian-vote/2019/11/msg00260.html'>enmienda</a>]
[<a href='https://lists.debian.org/debian-vote/2019/11/msg00293.html'>enmienda</a>]
</p>
<vsecondsa />
Esta enmienda ha sido presentada por el actual líder del proyecto y, por lo tanto, no precisa apoyos
# <ol>
# </ol>
<vtexta />
<h3>Opción 3: A: El soporte de sistemas de inicio múltiples es Importante</h3>
<p>El proyecto emite la siguiente declaración que describe su posicionamiento
actual respecto a los sistemas de inicio, sistemas de inicio múltiples y uso de
las utilidades de systemd. Esta declaración describe el posicionamiento del
proyecto en el momento de su adopción. El posicionamiento del proyecto puede evolucionar con el
tiempo sin que sea necesario recurrir a nuevas resoluciones generales (RG). El
procedimiento de RG seguirá estando disponible si el proyecto necesita una decisión y
no puede alcanzar un consenso.
</p>
<p>La capacidad de ejecutar sistemas Debian con sistemas de inicio distintos de systemd
sigue siendo algo que el proyecto valora. Todo paquete
debería funcionar con pid1 != systemd, a no ser que haya sido diseñado por el proyecto original
para funcionar exclusivamente con systemd y no haya disponible soporte para que
funcione sin systemd. Es un fallo «important» (aunque no uno
«serious») que un paquete que debería funcionar sin systemd no lo haga.
Según las directrices de las NMU, los desarrolladores y desarrolladoras pueden hacer actualizaciones sin necesidad de ser los o las responsables del
paquete para corregir estos fallos.
</p>
<p>No se considerará que un software haya sido diseñado por el proyecto original para funcionar
exclusivamente con systemd por el mero hecho de que el proyecto original no proporcione,
ni acepte, un script de inicio.
</p>
<p>No se recomienda la modificación del manual de normas para adoptar utilidades de systemd
en lugar de las estrategias existentes salvo que haya disponible una implementación
equivalente de la utilidad en cuestión para otros sistemas de inicio.
</p>
<vproposerd />
<p>Ian Jackson [<email iwj@debian.org>]
[<a href='https://lists.debian.org/debian-vote/2019/11/msg00163.html'>texto de la propuesta</a>]
[<a href='https://lists.debian.org/debian-vote/2019/11/msg00206.html'>texto de la enmienda</a>]
[<a href='https://lists.debian.org/debian-vote/2019/11/msg00283.html'>texto de la enmienda</a>]
[<a href='https://lists.debian.org/debian-vote/2019/11/msg00306.html'>texto de la enmienda</a>]
</p>
<vsecondsd />
<ol>
<li>Russ Allbery [<email rra@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00128.html'>correo</a>] </li>
<li>Sean Whitton [<email spwhitton@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00133.html'>correo</a>] </li>
<li>Simon Richter [<email sjr@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00138.html'>correo</a>] </li>
<li>Kyle Robbertze [<email paddatrapper@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00140.html'>correo</a>] </li>
<li>Dmitry Bogatov [<email kaction@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00156.html'>correo</a>] </li>
<li>Jonathan McDowell [<email noodles@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00168.html'>correo</a>] </li>
<li>Matthew Vernon [<email matthew@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00174.html'>correo</a>] </li>
<li>James Clarke [<email jrtc27@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00205.html'>correo</a>] </li>
<li>Thomas Goirand [<email zigo@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00247.html'>correo</a>] </li>
<li>Jonathan Dowland [<email jmtd@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00289.html'>correo</a>] </li>
</ol>
<vtextd />
<h3>Opción 4: D: Soporte para sistemas distintos de systemd, sin bloquear el avance</h3>
<h4>PRINCIPIOS</h4>
<p>1. Nos gustaría seguir soportando múltiples sistemas de inicio por el
momento. Y queremos mejorar nuestro soporte de systemd.
</p>
<p>2. Corresponde fundamentalmente a las comunidades de cada ecosistema software
mantener y desarrollar su software respectivo, pero con el
apoyo activo de otros y otras responsables y de personas que ayuden a filtrar cuando sea necesario.
</p>
<h4>DEPENDENCIAS CON SYSTEMD</h4>
<p>3. Idealmente, los paquetes deberían ser completamente funcionales con todos los sistemas
de inicio. Esto significa (por ejemplo) que los daemons deberían distribuirse
con scripts de inicio tradicionales o usar otros mecanismos para asegurar que
arranquen sin systemd. También significa que el software
de escritorio debería ser instalable, e idealmente completamente funcional,
sin systemd.
</p>
<p>4. Por lo tanto, la falta de soporte para sistemas distintos de systemd, cuando dicho soporte no está
disponible, es un fallo. Pero <b>no</b> es un fallo crítico para la publicación.
La decisión de registrar la dependencia con systemd como un fallo formal en
el sistema de fallos de Debian, cuando no hay parches disponibles, queda en manos del o de la
responsable.
</p>
<p>5. Cuando sin systemd se reduce la funcionalidad de un paquete, este
no debería, en el caso general, documentarse como «Depende de» o «Recomienda»
(directa o indirectamente) systemd-sysv. Esto es debido a que, con tales
dependencias, la instalación del paquete puede intentar cambiar de
sistema de inicio, que no es lo que el usuario o usuaria quería. Por ejemplo, un
daemon con un único script, fichero de unidad de sytemd, debería ser
instalable en un sistema sin systemd, ya que podría arrancarse
manualmente.
</p>
<p>Una consecuencia de esto es que en sistemas distintos de systemd puede ser
factible instalar software que después no funcionará, o no funcionará
correctamente, debido a una dependencia con systemd no declarada. Esto es
desafortunado, pero intentar cambiar el sistema de inicio del usuario o usuaria es peor.
Esperamos que se puedan desarrollar mejores soluciones técnicas para
abordar esto.
</p>
<p>6. Reconocemos que algunos o algunas responsables de paquetes consideran una carga los scripts de inicio y
esperamos que la comunidad pueda encontrar maneras de hacer más sencillo
la adición de soporte para sistemas de inicio distintos del sistema de inicio por omisión. Los debates sobre el
diseño de tales sistemas deberían ser amistosos y cooperativos, y si
se desarrollan soluciones adecuadas estas deberían soportarse en
Debian de las maneras habituales.
</p>
<h4>LAS CONTRIBUCIONES DE SOPORTE PARA SISTEMAS DISTINTOS DE SYSTEMD SERÁN ACEPTADAS</h4>
<p>7. No soportar sistemas distintos de systemd cuando dicho soporte esté
disponible, o sea ofrecido en forma de parches (o paquetes),
<b>debería</b> tratarse como un fallo crítico para la publicación. Por ejemplo: los scripts
de inicio <b>no deben</b> borrarse sencillamente porque se proporcione una unidad de
systemd en su lugar; los parches con los que se contribuya a proporcionar soporte para otros sistemas
de inicio (sin efecto sustancial sobre las instalaciones systemd)
deberían registrarse como fallos con gravedad “serious”.
</p>
<p>Esto es así con la intención de proporcionar un camino ligero pero efectivo para
asegurar que se puede proporcionar a los usuarios y usuarias de Debian un soporte razonable,
incluso cuando las prioridades del o de la responsable sean otras. (Invocar
al comité técnico en relación con parches individuales no es apropiado).
</p>
<p>Si los parches presentan, a su vez, fallos críticos para la publicación (en la opinión del o de la
responsable en un primer momento o del equipo responsable de la publicación en última instancia), entonces, por
supuesto, el informe de error debería degradarse o cerrarse.
</p>
<p>8. Los o las responsables de componentes de systemd u otras personas que ayuden a filtrar (incluyendo a
otros y otras responsables y al equipo responsable de la publicación) en ocasiones tienen que evaluar
contribuciones técnicas destinadas a dar soporte a usuarios y usuarias no systemd. La
aceptabilidad para los usuarios y usuarias de sistemas de inicio distintos del sistema de inicio por omisión de los riesgos
de calidad que puedan estar asociados a dichas contribuciones es asunto de los y las responsables de
los sistemas de inicio distintos del sistema de inicio por omisión y de la comunidad correspondiente. Pero esas
contribuciones no deberían imponer riesgos no triviales a los usuarios y usuarias de la
configuración por omisión (systemd con los Recomienda instalados).
</p>
<h4>UTILIDADES DECLARATIVAS DE SYSTEMD NO RELACIONADAS CON EL INICIO</h4>
<p>9. systemd proporciona varias utilidades además de las relacionadas con el inicio de daemons.
Por ejemplo, en relación con la creación de usuarios del sistema o de directorios temporales.
Las estrategias actuales de Debian se basan, a menudo, en scripts de debhelper.
</p>
<p>
En general, son mejores las estrategias más declarativas. Cuando
<ul>
<li>systemd proporciona la utilidad
<li>existe una especificación de la utilidad (o de un subconjunto adecuado)
<li>la utilidad es mejor que el resto de estrategias disponibles
en Debian, por ejemplo por ser más declarativa
<li>es razonable esperar que los desarrolladores y desarrolladoras de sistemas distintos de
systemd, incluyendo sistemas no Linux, la implementen
<li>teniendo en cuenta la cantidad de trabajo necesaria
</ul>
la utilidad debería documentarse en el manual de normas de Debian (mediante su incorporación
textual, no haciendo referencia a un documento externo). La
transición debería ser suave para todos los usuarios y usuarias. La comunidad
no systemd debería disponer de un mínimo de seis meses, preferiblemente doce,
para desarrollar su implementación. (Lo mismo vale para cualquier
mejora futura).
</p>
<p>
Si no se puede alcanzar consenso normativo sobre dicha utilidad, el
comité técnico debería decidir en base a los deseos expresados por el
proyecto en esta RG.
</p>
<h4>SER EXCELENTE CON LOS Y LAS DEMÁS</h4>
<p>10. En general, los y las responsables de programas en competencia, incluyendo
los y las responsables de los distintos sistemas de inicio en competencia, deberían ser
complacientes con las necesidades del resto. Esto incluye las necesidades y
la conveniencia de los usuarios y usuarias de configuraciones distintas de las configuraciones por omisión que sean razonables.
</p>
<p>11. Deben evitarse los comentarios generales negativos acerca de programas y
de sus comunidades, incluyendo comentarios sobre el propio systemd y sobre los sistemas de
inicio distintos de systemd. Ni los mensajes expresando
desagrado en general con systemd ni las predicciones sobre la desaparición de
los sistemas distintos de systemd son adecuados para los foros de comunicación de Debian;
como tampoco lo son las referencias a fallos que no sean relevantes para el asunto que se esté
tratando.
</p>
<p>Las comunicaciones en los foros de Debian sobre estas materias deberían ser siempre
alentadoras y agradables, aun cuando se discutan problemas técnicos.
Pedimos a los propietarios y propietarias de los foros de comunicación que hagan cumplir esto de forma estricta.
</p>
<p>12. Pedimos respetuosamente a todos los contribuidores y contribuidoras de Debian, incluyendo a los y las responsables,
a los editores y editoras del manual de normas, al equipo responsable de la publicación, al comité técnico y al o a la
líder del proyecto, que persigan estos objetivos y principios en su trabajo
y que los incluyan en documentos, etc., según resulte adecuado.
(Esta resolución es una declaración de posicionamiento bajo s4.1(5)).
</p>
<vproposerh />
<p>Ian Jackson [<email iwj@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/12/msg00142.html'>texto de la propuesta</a>]
</p>
<vsecondsh />
<ol>
<li>Jonas Smedegaard [<email js@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/12/msg00129.html'>correo</a>] </li>
<li>Holger Levsen [<email holger@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/12/msg00131.html'>correo</a>] </li>
<li>Michael Lustfield [<email mtecknology@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/12/msg00132.html'>correo</a>] </li>
<li>Guilhem Moulin [<email guilhem@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/12/msg00134.html'>correo</a>] </li>
<li>Matthew Vernon [<email matthew@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/12/msg00137.html'>correo</a>] </li>
<li>Kyle Robbertze [<email paddatrapper@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/12/msg00139.html'>correo</a>] </li>
<li>gregor herrmann [<email gregoa@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/12/msg00156.html'>correo</a>] </li>
<li>Sean Whitton [<email spwhitton@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/12/msg00163.html'>correo</a>] </li>
</ol>
<vtexth />
<h3>Opción 5: H: Soporte para la portabilidad, sin bloquear el avance</h3>
<h4>PRINCIPIOS</h4>
<p>1. El proyecto Debian ratifica su compromiso de ser el pegamento que une
e integra distintos programas que proporcionan funcionalidades similares o
equivalentes con sus usuarios y usuarias, sean estos humanos u otros programas,
lo cual es una de las características definitorias centrales de una distribución.</p>
<p>2. Consideramos la portabilidad a diferentes plataformas hardware y colecciones de
software un aspecto importante del trabajo que hacemos como distribución, que
hace el software mejor en términos de arquitectura, más robusto y con mayor garantía de futuro.</p>
<p>3. Admitimos que los distintos proyectos originales tienen diferentes puntos de vista sobre
desarrollo de software, casos de uso, portabilidad y tecnología en general.
Y que los usuarios y usuarias de esos proyectos sopesan de forma distinta las soluciones de compromiso y tienen
requisitos y necesidades, que son al mismo tiempo diferentes y válidos, satisfechos
desde sus diversos puntos de vista.</p>
<p>4. Siguiendo nuestra tradición histórica, daremos la bienvenida a la integración de
esas tecnologías diversas que podrían, en ocasiones, presentar visiones opuestas
del mundo, para permitir que coexistan de forma armoniosa en nuestra distribución,
conciliando los conflictos por medios técnicos, mientras
haya personas deseando realizar el esfuerzo requerido.</p>
<p>5. Esto nos habilita para seguir proporcionando un amplio rango de usos de nuestra distribución
(algunos inesperados incluso para nosotros mismos). Desde servidores a equipos de sobremesa
o sistemas empotrados; desde propósito general a usos personalizados muy
específicos. Tanto si se trata de proyectos relacionados con hardware o basados en software, bibliotecas,
daemons, entornos completos de escritorio u otras piezas de la colección de
software.</p>
<h4>DEPENDENCIAS CON SYSTEMD</h4>
<p>6. Idealmente, los paquetes deberían ser completamente funcionales con todos los sistemas
de inicio. Esto significa (por ejemplo) que los daemons deberían distribuirse
con scripts de inicio tradicionales o usar otros mecanismos para asegurar que
arranquen sin systemd. También significa que el software
de escritorio debería ser instalable, e idealmente completamente funcional,
sin systemd.
</p>
<p>7. Por lo tanto, la falta de soporte para sistemas distintos de systemd, cuando dicho soporte no está
disponible, es un fallo. Pero <b>no</b> es un fallo crítico para la publicación.
La decisión de registrar la dependencia con systemd como un fallo formal en
el sistema de fallos de Debian, cuando no hay parches disponibles, queda en manos del o de la
responsable.
</p>
<p>8. Cuando sin systemd se reduce la funcionalidad de un paquete, este
no debería, en el caso general, documentarse como «Depende de» o «Recomienda»
(directa o indirectamente) systemd-sysv. Esto es debido a que, con tales
dependencias, la instalación del paquete puede intentar cambiar de
sistema de inicio, que no es lo que el usuario o usuaria quería. Por ejemplo, un
daemon con un único script, fichero de unidad de sytemd, debería ser
instalable en un sistema sin systemd, ya que podría arrancarse
manualmente.
</p>
<p>Una consecuencia de esto es que en sistemas distintos de systemd puede ser
factible instalar software que después no funcionará, o no funcionará
correctamente, debido a una dependencia con systemd no declarada. Esto es
desafortunado, pero intentar cambiar el sistema de inicio del usuario o usuaria es peor.
Esperamos que se puedan desarrollar mejores soluciones técnicas para
abordar esto.
</p>
<p>9. Reconocemos que algunos o algunas responsables de paquetes consideran una carga los scripts de inicio y
esperamos que la comunidad pueda encontrar maneras de hacer más sencillo
la adición de soporte para sistemas de inicio distintos del sistema de inicio por omisión. Los debates sobre el
diseño de tales sistemas deberían ser amistosos y cooperativos, y si
se desarrollan soluciones adecuadas estas deberían soportarse en
Debian de las maneras habituales.
</p>
<h4>LAS CONTRIBUCIONES DE SOPORTE PARA SISTEMAS DISTINTOS DE SYSTEMD SERÁN ACEPTADAS</h4>
<p>10. No soportar sistemas distintos de systemd cuando dicho soporte esté
disponible, o sea ofrecido en forma de parches (o paquetes),
<b>debería</b> tratarse como un fallo crítico para la publicación. Por ejemplo: los scripts
de inicio <b>no deben</b> borrarse sencillamente porque se proporcione una unidad de
systemd en su lugar; los parches con los que se contribuya a proporcionar soporte para otros sistemas
de inicio (sin efecto sustancial sobre las instalaciones systemd)
deberían registrarse como fallos con gravedad “serious”.
</p>
<p>Esto es así con la intención de proporcionar un camino ligero pero efectivo para
asegurar que se puede proporcionar a los usuarios y usuarias de Debian un soporte razonable,
incluso cuando las prioridades del o de la responsable sean otras. (Invocar
al comité técnico en relación con parches individuales no es apropiado).
</p>
<p>Si los parches presentan, a su vez, fallos críticos para la publicación (en la opinión del o de la
responsable en un primer momento o del equipo responsable de la publicación en última instancia), entonces, por
supuesto, el informe de error debería degradarse o cerrarse.
</p>
<p>11. Los o las responsables de componentes de systemd u otras personas que ayuden a filtrar (incluyendo a
otros y otras responsables y al equipo responsable de la publicación) en ocasiones tienen que evaluar
contribuciones técnicas destinadas a dar soporte a usuarios y usuarias no systemd. La
aceptabilidad para los usuarios y usuarias de sistemas de inicio distintos del sistema de inicio por omisión de los riesgos
de calidad que puedan estar asociados a dichas contribuciones es asunto de los y las responsables de
los sistemas de inicio distintos del sistema de inicio por omisión y de la comunidad correspondiente. Pero esas
contribuciones no deberían imponer riesgos no triviales a los usuarios y usuarias de la
configuración por omisión (systemd con los Recomienda instalados).
</p>
<h4>UTILIDADES DECLARATIVAS DE SYSTEMD NO RELACIONADAS CON EL INICIO</h4>
<p>12. systemd proporciona varias utilidades además de las relacionadas con el inicio de daemons.
Por ejemplo, en relación con la creación de usuarios del sistema o de directorios temporales.
Las estrategias actuales de Debian se basan, a menudo, en scripts de debhelper.
</p>
<p>
En general, son mejores las estrategias más declarativas. Cuando
<ul>
<li>systemd proporciona la utilidad
<li>existe una especificación de la utilidad (o de un subconjunto adecuado)
<li>la utilidad es mejor que el resto de estrategias disponibles
en Debian, por ejemplo por ser más declarativa
<li>es razonable esperar que los desarrolladores y desarrolladoras de sistemas distintos de
systemd, incluyendo sistemas no Linux, la implementen
<li>teniendo en cuenta la cantidad de trabajo necesaria
</ul>
la utilidad debería documentarse en el manual de normas de Debian (mediante su incorporación
textual, no haciendo referencia a un documento externo). La
transición debería ser suave para todos los usuarios y usuarias. La comunidad
no systemd debería disponer de un mínimo de seis meses, preferiblemente doce,
para desarrollar su implementación. (Lo mismo vale para cualquier
mejora futura).
</p>
<p>
Si no se puede alcanzar consenso normativo sobre dicha utilidad, el
comité técnico debería decidir en base a los deseos expresados por el
proyecto en esta RG.
</p>
<h4>SER EXCELENTE CON LOS Y LAS DEMÁS</h4>
<p>13. En general, los y las responsables de programas en competencia, incluyendo
los y las responsables de los distintos sistemas de inicio en competencia, deberían ser
complacientes con las necesidades del resto. Esto incluye las necesidades y
la conveniencia de los usuarios y usuarias de configuraciones distintas de las configuraciones por omisión que sean razonables.
</p>
<p>14. Deben evitarse los comentarios generales negativos acerca de programas y
de sus comunidades, incluyendo comentarios sobre el propio systemd y sobre los sistemas de
inicio distintos de systemd. Ni los mensajes expresando
desagrado en general con systemd ni las predicciones sobre la desaparición de
los sistemas distintos de systemd son adecuados para los foros de comunicación de Debian;
como tampoco lo son las referencias a fallos que no sean relevantes para el asunto que se esté
tratando.
</p>
<p>Las comunicaciones en los foros de Debian sobre estas materias deberían ser siempre
alentadoras y agradables, aun cuando se discutan problemas técnicos.
Pedimos a los propietarios y propietarias de los foros de comunicación que hagan cumplir esto de forma estricta.
</p>
<p>15. Pedimos respetuosamente a todos los contribuidores y contribuidoras de Debian, incluyendo a los y las responsables,
a los editores y editoras del manual de normas, al equipo responsable de la publicación, al comité técnico y al o a la
líder del proyecto, que persigan estos objetivos y principios en su trabajo
y que los incluyan en documentos, etc., según resulte adecuado.
(Esta resolución es una declaración de posicionamiento bajo s4.1(5)).
</p>
<vproposere />
<p>Dmitry Bogatov [<email kaction@debian.org>]
[<a href='https://lists.debian.org/debian-vote/2019/11/msg00202.html'>texto de la última propuesta</a>]
</p>
<vsecondse />
<ol>
<li>Ian Jackson [<email iwj@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00193.html'>correo</a>] </li>
<li>Matthew Vernon [<email matthew@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00194.html'>correo</a>] </li>
<li>Jonathan Carter [<email jcc@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00195.html'>correo</a>] </li>
<li>Kyle Robbertze [<email paddatrapper@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00196.html'>correo</a>] </li>
<li>Axel Beckert [<email abe@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00197.html'>correo</a>] </li>
<li>Brian Gupta [<email bgupta@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00234.html'>correo</a>] </li>
<li>Simon Richter [<email sjr@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00238.html'>correo</a>] </li>
</ol>
<vtexte />
<h3>Opción 6: E: Soportar múltiples sistemas de inicio es un Requisito</h3>
<p>La capacidad de ejecutar sistemas Debian con sistemas de inicio distintos de systemd
sigue siendo algo que el proyecto valora. Todo paquete DEBE funcionar con
pid1 != systemd, a no ser que haya sido diseñado por el proyecto original para funcionar exclusivamente
con systemd y no haya disponible soporte para que funcione sin systemd.
</p>
<p>No se considerará que un software haya sido diseñado por el proyecto original para funcionar
exclusivamente con systemd por el mero hecho de que el proyecto original no proporcione,
ni acepte, un script de inicio.
</p>
<vproposerg />
<p> Guillem Jover [<email guillem@debian.org>]
[<a href='https://lists.debian.org/debian-vote/2019/11/msg00361.html'>texto de la propuesta</a>]
[<a href='https://lists.debian.org/debian-vote/2019/12/msg00176.html'>texto de la propuesta</a>]
</p>
<vsecondsg />
<ol>
<li>Simon Richter [<email sjr@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00362.html'>correo</a>] </li>
<li>gregor herrmann [<email gregoa@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00363.html'>correo</a>] </li>
<li>Jonas Smedegaard [<email js@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00364.html'>correo</a>] </li>
<li>Guilhem Moulin [<email guilhem@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00365.html'>correo</a>] </li>
<li>Ricardo Mones [<email mones@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00366.html'>correo</a>] </li>
<li>Mathias Behrle [<email mbehrle@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00367.html'>correo</a>] </li>
<li>Steve Kostecke [<email steve@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00368.html'>correo</a>] </li>
<li>Alberto Gonzalez Iniesta [<email agi@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00375.html'>correo</a>] </li>
<li>Kyle Robbertze [<email paddatrapper@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/12/msg00179.html'>correo</a>] </li>
<li>Adam Borowski [<email kilobyte@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/12/msg00180.html'>correo</a>] </li>
<li>Donald Scott Kitterman [<email kitterman@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/12/msg00181.html'>correo</a>] </li>
</ol>
<vtextg />
<h3>Opción 7: G: Soporte para la portabilidad y de las implementaciones múltiples</h3>
<h4>Principios</h4>
<p>El proyecto Debian ratifica su compromiso de ser el pegamento que une
e integra distintos programas que proporcionan funcionalidades similares o
equivalentes con sus usuarios y usuarias, sean estos humanos u otros programas,
lo cual es una de las características definitorias centrales de una distribución.</p>
<p>Consideramos la portabilidad a diferentes plataformas hardware y colecciones de
software un aspecto importante del trabajo que hacemos como distribución, que
hace el software mejor en términos de arquitectura, más robusto y con mayor garantía de futuro.</p>
<p>Admitimos que los distintos proyectos originales tienen diferentes puntos de vista sobre
desarrollo de software, casos de uso, portabilidad y tecnología en general.
Y que los usuarios y usuarias de esos proyectos sopesan de forma distinta las soluciones de compromiso y tienen
requisitos y necesidades, que son al mismo tiempo diferentes y válidos, satisfechos
desde sus diversos puntos de vista.</p>
<p>Siguiendo nuestra tradición histórica, daremos la bienvenida a la integración de
esas tecnologías diversas que podrían, en ocasiones, presentar visiones opuestas
del mundo, para permitir que coexistan de forma armoniosa en nuestra distribución,
conciliando los conflictos por medios técnicos, mientras
haya personas deseando realizar el esfuerzo requerido.</p>
<p>Esto nos habilita para seguir proporcionando un amplio rango de usos de nuestra distribución
(algunos inesperados incluso para nosotros mismos). Desde servidores a equipos de sobremesa
o sistemas empotrados; desde propósito general a usos personalizados muy
específicos. Tanto si se trata de proyectos relacionados con hardware o basados en software, bibliotecas,
daemons, entornos completos de escritorio u otras piezas de la colección de
software.</p>
<h4>Guía</h4>
<p>De la misma manera que los y las responsables de paquetes Debian están en cierto sentido restringidos por las
decisiones y la dirección que emerge de los proyectos originales respectivos,
así también la distribución Debian está en cierto sentido restringida por el hecho de estar basada
en el trabajo voluntario, otra de sus características definitorias centrales, deseando
no imponer obligaciones de trabajo a sus miembros y, al mismo
tiempo, estando limitada por los intereses, motivación, energía y tiempo
de sus miembros.</p>
<p>Debido a estas restricciones, intentar proporcionar una guía
detallada para aplicar los principios mencionados nunca
va a resultar satisfactorio, puesto que terminará siendo, inexorablemente, una lista
rígida e incompleta de directrices que no cubrirá, probablemente,
la mayoría de los escenarios, lo cual puede perpetuar las posibles tensiones actuales.</p>
<p>Siempre será necesario estudiar, caso por caso, soluciones de compromiso entre los
cambios o peticiones que los proyectos originales podrían o no aceptar, o el coste del mantenimiento
de las modificaciones («deltas») o implementaciones impuestas que los y las miembros de Debian podrían tener
que llevar a cabo. Todo lo cual no puede cuantificarse ni listarse de forma genérica
y universal.</p>
<p>También tendremos presente que lo que alguien podría considerar
importante, para otros u otras podría ser un nicho o un
entretenimiento sin mayor interés, y podríamos terminar en
uno u otro lado de la valla al enviar o recibir estas peticiones.</p>
<p>Seremos guiados, igual que hemos sido guiados en muchos otros contextos de Debian en el
pasado, teniendo en cuenta todo lo dicho y debatiendo y evaluando
cada situación, respetando y valorando el hecho de que todos y todas tenemos distintos
intereses y motivaciones. Va en nuestro propio interés general intentar
resolver las cosas junto con los y las otras, transigir, llegar a soluciones o encontrar
alternativas que resulten lo bastante satisfactorias para todas las partes
implicadas, crear un entorno en el que intentemos corresponder
unos con otros. Y al final, y en la mayoría de los casos, quizá sea cuestión,
únicamente, de querer intentarlo.</p>
<vproposerc />
<p>Sam Hartman [<email hartmans@debian.org>]
[<a href='https://lists.debian.org/debian-vote/2019/11/msg00117.html'>texto de la propuesta</a>]
[<a href='https://lists.debian.org/debian-vote/2019/11/msg00293.html'>enmienda</a>]
[<a href='https://lists.debian.org/debian-vote/2019/11/msg00381.html'>retirada</a>]
</p>
<vsecondsc />
Esta enmienda ha sido presentada por el actual líder del proyecto y, por lo tanto, no precisa apoyos
<ol>
<li>Ansgar Burchardt [<email ansgar@debian.org>] [<a href='https://lists.debian.org/debian-vote/2019/11/msg00253.html'>correo</a>] </li>
</ol>
<vtextc />
<h3>Foco en systemd como sistema de inicio y otras utilidades (retirada)</h3>
# <vquorum />
# <p>
# With the current list of <a href="vote_002_quorum.log">voting
# developers</a>, we have:
# </p>
# <pre>
##include 'vote_002_quorum.txt'
# </pre>
##include 'vote_002_quorum.src'
#
<vstatistics />
<p>
Para esta RG, como siempre,
se obtendrán <a href="https://vote.debian.org/~secretary/gr_private/";>estadísticas</a>
# <a href="suppl_002_stats">statistics</a>
de forma periódica durante el periodo de votación
sobre las papeletas recibidas y sobre los acuses de recibo
enviados.
## Additionally, the list of voters will be
## recorded. Also, the tally
## sheet will also be made available to be viewed.
# Additionally, the list of <a
# href="vote_002_voters.txt">voters</a> will be
# recorded. Also, the <a href="vote_002_tally.txt">tally
# sheet</a> will also be made available to be viewed.
# </p>
<vmajorityreq />
<p>
La propuesta necesita mayoría simple.
</p>
##include 'vote_002_majority.src'
# <voutcome />
##include 'vote_002_results.src'
<hrline />
<address>
<a href="mailto:secretary@debian.org";>El secretario del proyecto Debian</a>
</address>
Attachment:
signature.asc
Description: PGP signature