Resolución General: sistemas de inicio y systemd

Línea temporal

Propuesta y enmienda 16-11-2019
Periodo de debate: 22-11-2019
Periodo de votación: Sábado 07-12-2019 00:00:00 UTC Viernes 27-12-2019 23:59:59 UTC
El líder del proyecto ha modificado el periodo de debate: el periodo de debate mínimo finaliza el 30 de noviembre. [correo]

Proponente propuesta F

Martin Michlmayr [[email protected]] [texto de la propuesta]

Apoyos a la propuesta F

  1. Michael Biebl [[email protected]] [correo]
  2. Ansgar Burchardt [[email protected]] [correo]
  3. Julien Cristau [[email protected]] [correo]
  4. Enrico Zini [[email protected]] [correo]
  5. Matthias Klumpp [[email protected]] [correo]
  6. Ana Beatriz Guerrero López [[email protected]] [correo]
  7. Russ Allbery [[email protected]] [correo]
  8. Intrigeri [[email protected]] [correo]
  9. Luca Filipozzi [[email protected]] [correo]
  10. Moritz Mühlenhoff [[email protected]] [correo]
  11. Paul Tagliamonte [[email protected]] [correo]
  12. Jordi Mallach [[email protected]] [correo]
  13. Philipp Kern [[email protected]] [correo]
  14. Holger Levsen [[email protected]] [correo]
  15. Jeremy Bicha [[email protected]] [correo]

Propuesta F

Opción 1: F: Foco en systemd

Esta resolución es una declaración de posicionamiento bajo la sección 4.1 (5) de la Constitución de Debian:

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.

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.

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.

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.

Proponente propuesta B

Sam Hartman [[email protected]] [texto de la propuesta] [enmienda]

Apoyos a la propuesta B

Esta enmienda ha sido presentada por el actual líder del proyecto y, por lo tanto, no precisa apoyos

Propuesta B

Opción 2: B: systemd pero apoyamos la exploración de alternativas

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.

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.

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.

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.

Proponente propuesta A

Sam Hartman [[email protected]] [texto de la propuesta] [enmienda] [enmienda] [enmienda]

Apoyos a la propuesta A

Esta enmienda ha sido presentada por el actual líder del proyecto y, por lo tanto, no precisa apoyos

Propuesta A

Opción 3: A: El soporte de sistemas de inicio múltiples es Importante

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.

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.

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.

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.

Proponente propuesta D

Ian Jackson [[email protected]] [texto de la propuesta] [texto de la enmienda] [texto de la enmienda] [texto de la enmienda]

Apoyos a la propuesta D

  1. Russ Allbery [[email protected]] [correo]
  2. Sean Whitton [[email protected]] [correo]
  3. Simon Richter [[email protected]] [correo]
  4. Kyle Robbertze [[email protected]] [correo]
  5. Dmitry Bogatov [[email protected]] [correo]
  6. Jonathan McDowell [[email protected]] [correo]
  7. Matthew Vernon [[email protected]] [correo]
  8. James Clarke [[email protected]] [correo]
  9. Thomas Goirand [[email protected]] [correo]
  10. Jonathan Dowland [[email protected]] [correo]

Propuesta D

Opción 4: D: Soporte para sistemas distintos de systemd, sin bloquear el avance

PRINCIPIOS

1. Nos gustaría seguir soportando múltiples sistemas de inicio por el momento. Y queremos mejorar nuestro soporte de systemd.

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.

DEPENDENCIAS CON SYSTEMD

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.

4. Por lo tanto, la falta de soporte para sistemas distintos de systemd, cuando dicho soporte no está disponible, es un fallo. Pero no 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.

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 systemd, debería ser instalable en un sistema sin systemd, ya que podría arrancarse manualmente.

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.

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.

LAS CONTRIBUCIONES DE SOPORTE PARA SISTEMAS DISTINTOS DE SYSTEMD SERÁN ACEPTADAS

7. No soportar sistemas distintos de systemd cuando dicho soporte esté disponible, o sea ofrecido en forma de parches (o paquetes), debería tratarse como un fallo crítico para la publicación. Por ejemplo: los scripts de inicio no deben 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”.

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).

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.

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).

UTILIDADES DECLARATIVAS DE SYSTEMD NO RELACIONADAS CON EL INICIO

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.

En general, son mejores las estrategias más declarativas. Cuando

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).

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.

SER EXCELENTE CON LOS Y LAS DEMÁS

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.

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.

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.

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)).

Proponente propuesta H

Ian Jackson [[email protected]] [texto de la propuesta]

Apoyos a la propuesta H

  1. Jonas Smedegaard [[email protected]] [correo]
  2. Holger Levsen [[email protected]] [correo]
  3. Michael Lustfield [[email protected]] [correo]
  4. Guilhem Moulin [[email protected]] [correo]
  5. Matthew Vernon [[email protected]] [correo]
  6. Kyle Robbertze [[email protected]] [correo]
  7. gregor herrmann [[email protected]] [correo]
  8. Sean Whitton [[email protected]] [correo]

Propuesta H

Opción 5: H: Soporte para la portabilidad, sin bloquear el avance

PRINCIPIOS

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.

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.

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.

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.

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.

DEPENDENCIAS CON SYSTEMD

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.

7. Por lo tanto, la falta de soporte para sistemas distintos de systemd, cuando dicho soporte no está disponible, es un fallo. Pero no 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.

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 systemd, debería ser instalable en un sistema sin systemd, ya que podría arrancarse manualmente.

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.

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.

LAS CONTRIBUCIONES DE SOPORTE PARA SISTEMAS DISTINTOS DE SYSTEMD SERÁN ACEPTADAS

10. No soportar sistemas distintos de systemd cuando dicho soporte esté disponible, o sea ofrecido en forma de parches (o paquetes), debería tratarse como un fallo crítico para la publicación. Por ejemplo: los scripts de inicio no deben 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”.

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).

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.

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).

UTILIDADES DECLARATIVAS DE SYSTEMD NO RELACIONADAS CON EL INICIO

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.

En general, son mejores las estrategias más declarativas. Cuando

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).

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.

SER EXCELENTE CON LOS Y LAS DEMÁS

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.

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.

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.

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)).

Proponente propuesta E

Dmitry Bogatov [[email protected]] [texto de la última propuesta]

Apoyos a la propuesta E

  1. Ian Jackson [[email protected]] [correo]
  2. Matthew Vernon [[email protected]] [correo]
  3. Jonathan Carter [[email protected]] [correo]
  4. Kyle Robbertze [[email protected]] [correo]
  5. Axel Beckert [[email protected]] [correo]
  6. Brian Gupta [[email protected]] [correo]
  7. Simon Richter [[email protected]] [correo]

Propuesta E

Opción 6: E: Soportar múltiples sistemas de inicio es un Requisito

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.

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.

Proponente propuesta G

Guillem Jover [[email protected]] [texto de la propuesta] [texto de la propuesta]

Apoyos a la propuesta G

  1. Simon Richter [[email protected]] [correo]
  2. gregor herrmann [[email protected]] [correo]
  3. Jonas Smedegaard [[email protected]] [correo]
  4. Guilhem Moulin [[email protected]] [correo]
  5. Ricardo Mones [[email protected]] [correo]
  6. Mathias Behrle [[email protected]] [correo]
  7. Steve Kostecke [[email protected]] [correo]
  8. Alberto Gonzalez Iniesta [[email protected]] [correo]
  9. Kyle Robbertze [[email protected]] [correo]
  10. Adam Borowski [[email protected]] [correo]
  11. Donald Scott Kitterman [[email protected]] [correo]

Propuesta G

Opción 7: G: Soporte para la portabilidad y de las implementaciones múltiples

Principios

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.

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.

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.

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.

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.

Guía

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.

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.

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.

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.

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.

Proponente propuesta C

Sam Hartman [[email protected]] [texto de la propuesta] [enmienda] [retirada]

Apoyos a la propuesta C

Esta enmienda ha sido presentada por el actual líder del proyecto y, por lo tanto, no precisa apoyos
  1. Ansgar Burchardt [[email protected]] [correo]

Propuesta C

Foco en systemd como sistema de inicio y otras utilidades (retirada)

Quórum

Con la lista actual del censo de desarrolladores y desarrolladoras, tenemos: 

 Número actual de desarrolladores = 1011
 Q ( raíz cuadrada (num. desarrolladores) / 2 ) = 15.8981130955846
 K min(5, Q )           = 5
 Quorum  (3 x Q )       = 47.6943392867539

Quorum

Datos y estadísticas

Para esta RG, como siempre, se obtendrán estadísticas de forma periódica durante el periodo de votación sobre las papeletas recibidas y sobre los acuses de recibo enviados. Además, la lista de votantes quedará registrada. También estará disponible para su consulta la hoja del escrutinio.

Mayoría necesaria

La propuesta necesita mayoría simple.

Mayoría

Resultado

Representación gráfica de los resultados

En el gráfico anterior los nodos rosa indican que esa opción no ha superado la mayoría y la azul es la opción ganadora. El octógono se utiliza para las opciones que no han batido a la opción por omisión.

En la tabla siguiente, escrutinio[fila x][columna y] representa el número de votos en los que se prefiere la opción x sobre la opción y. Una explicación más detallada de la matriz de duelos puede ayudar a entender la tabla. Para entender el método Condorcet, la entrada de la Wikipedia es bastante informativa.

Matriz de duelos
 Opción
  1 2 3 4 5 6 7 8
Opción 1   185 246 223 227 278 243 307
Opción 2 207   243 211 216 286 240 299
Opción 3 159 131   113 120 250 165 225
Opción 4 192 177 235   137 309 261 281
Opción 5 187 168 222 163   301 246 271
Opción 6 116 104 88 53 51   121 173
Opción 7 168 145 176 93 91 207   216
Opción 8 110 111 166 114 124 214 168  

Mirando a la fila 2, columna 1, en 207 votos
se prefirió B: systemd pero apoyamos la exploración de alternativas
sobre F: Foco en systemd

Mirando a la fila 1, columna 2, en 185 votos
se prefirió F: Foco en systemd
sobre B: systemd pero apoyamos la exploración de alternativas.

Enfrentamientos por parejas

El conjunto de Schwartz contiene

Los ganadores

Debian utiliza el método Condorcet en las votaciones. Esquemáticamente, el método Condorcets se puede enunciar de la siguiente manera:
Considérense todos los posibles enfrentamientos entre pares de candidatos. El ganador Condorcet, si es que hay alguno, es el candidato que puede vencer a todos los demás en dichos enfrentamientos entre pares. El problema es que, en votaciones complejas, puede haber un resultado circular en el que A vence a B, B vence a C y C vence a A. Las distintas variaciones de Condorcet usan diferentes maneras de resolver el empate. Consulte Cloneproof Schwartz Sequential Dropping («el método Schulze») para más detalles. La variación de Debian está articulada en la constitución, en concreto, en A.6.

El secretario del proyecto Debian