¿Cómo se asegura el equipo de Ubuntu que los errores no volverán a aparecer?
Lo he visto varias veces. Un paquete no se puede utilizar después de la instalación.
Sí, a veces los errores se solucionan muy rápido.
Pero no veo ningún esfuerzo para mejorar las pruebas automatizadas, para que el error no vuelva a aparecer.
Aquí hay dos ejemplos que me afectaron durante las últimas dos semanas:
- https://bugs.launchpad.net/ubuntu/+source/vsftpd/+bug/1219857
- https://bugs.launchpad.net/ubuntu/+source/python3.4/+bug/1290847
Hay más ejemplos, pero enumerarlos no es parte de la pregunta.
Un comentario de la vsftppágina de errores:
Ayúdenos probando este nuevo paquete. Verhttps://wiki.ubuntu.com/Testing/EnableProposedpara obtener documentación sobre cómo habilitar y utilizar -proposed. Sus comentarios nos ayudarán a hacer llegar esta actualización a otros usuarios de Ubuntu.
Está bien, pero "probar" en la cita anterior esmanualpruebas.
Para garantizar la calidadautomatizadose necesitan pruebas.
Para mí, las pruebas manuales son una pérdida de tiempo. Por otro lado, la creación de pruebas automatizadas garantiza la calidad.
Aquí nuevamente la pregunta:
¿Cómo se asegura el equipo de Ubuntu que los errores no vuelvan a aparecer?
Historia de esta pregunta
Primero, el título era "¿Cómo se asegura el equipo de Ubuntu de que los errores no vuelvan a aparecer?". Ahora es "¿Cómo realiza el equipo de Ubuntu pruebas automatizadas?". Esto se hizo porque creo que las pruebas manuales no son una solución. No rechace las respuestas que solo explican la forma en que se realizan las pruebas manuales.
Respuesta1
Ubuntu tiene pruebas automatizadas. Por ejemplo, las pruebas automatizadas se utilizan para evitar que el primer ejemplo de error vuelva a ocurrir. Fui yo quien solucionó el primer error de vsftpd que mencionaste y, mientras lo hacía, también agregué una prueba automatizada para evitar que vuelva a suceder lo mismo. Puedes ver esto en la entrada del registro de cambios que se publicó en el error:
vsftpd (3.0.2-1ubuntu2.14.04.1) trusty; urgency=medium
* d/p/ubuntu-seccomp-gettimeofday.patch: permit gettimeofday() for logging
calls (LP: #1219857).
* Add dep8 smoke test.
-- Robie Basak <[email protected]> Tue, 29 Apr 2014 15:33:07 +0000
No sé por qué considera el error como un ejemplo de falta de pruebas automatizadas, ya que hago varias menciones a esto en el error. Por ejemplo, dije "se agregó la prueba dep8 para detectar esto en el futuro" y "La prueba dep8 incluida verifica automáticamente la solución de este error" en el resumen.
Recuerde que Ubuntu es una distribución: es una agregación integrada de muchos proyectos externos que llamamos upstreams. Ubuntu no sería posible sin el trabajo de otros en el ecosistema más amplio del software libre y, de la misma manera, a menudo dependemos de los autores originales para que proporcionen pruebas, ya que ellos son los expertos en su software.
Además, como somos una combinación de diferentes proyectos, una única infraestructura de pruebas automáticas no tiene sentido. Diferentes áreas tienen diferentes necesidades. Por lo tanto, nuestra estrategia de prueba está bastante extendida para satisfacer estas necesidades y cubre pruebas tanto manuales como automatizadas a través de varias infraestructuras diferentes.
Cuando los proyectos ascendentes proporcionan pruebas automatizadas, las ejecutamos como parte de la compilación del paquete. La compilación del paquete falla si las pruebas no pasan. Asegurarnos de que cualquier prueba automatizada disponible esté habilitada de esta manera es parte de nuestrorequisitos para la inclusión principal:Si el paquete incluye un conjunto de pruebas y no hay ninguna razón obvia por la que no pueda funcionar durante la compilación (por ejemplo, necesita privilegios de root o acceso a la red), se debe ejecutar durante la compilación del paquete, y un conjunto de pruebas fallido debería fallar en la compilación.
Además, ejecutamos "pruebas automáticas de paquetes instalados" basadas en una especificación llamadadep8, que está diseñado para probar que la integración entre paquetes funciona correctamente. Las actualizaciones de paquetes que hacen retroceder las pruebas dep8 no pasan a la versión de desarrollo hasta que se solucionan.
Estoy menos familiarizado con las pruebas automatizadas realizadas por los equipos de escritorio y teléfono, pero sé que existen más mecanismos porque he visto referencias a ellos a lo largo de los años, y esto incluye pruebas automatizadas de GUI, que creo que son bastante impresionantes. Agradezco otra respuesta que cubra las pruebas automatizadas de escritorio y teléfono.
Respuesta2
De varias maneras.
Muchos ojos.
Ubuntu es de código abierto, lo que significa que cualquiera puede mirar el código y ver cuál es el problema. Las personas que estén interesadas en ver el código a menudo encontrarán errores en él o en su uso, yreportarlos en la plataforma de lanzamientoyel público puede incluso arreglarlos.
Cuando lo haya probado y haya sugerido la solución, solicitará una fusión con el paquete principal de Ubuntu. Otros desarrolladores revisan este cambio y, si se aprueba, lo agregarán.
Debido a que cualquiera puede arreglarlos, se detectan rápidamente y se revisan, es menos probable que permanezcan por un tiempo. Esto lleva al siguiente punto.
Estos ojos también incluyen ojos de computadora:
El proceso de control de calidad ascendente debe documentarse/demostrarse y vincularse desde el error de seguimiento de SRU. En otros casos en los que dichas pruebas automáticas ascendentes no estén disponibles...
Lo que demuestra que normalmente se realizan pruebas automáticas.
Lanzamientos beta
Antes de que Ubuntu se lance al público, existen versiones beta. Actualmente es la Beta 15.10, por serlanzado el 22 de octubre de 2015. Mucha, mucha gente habrá estado usando, revisando y corrigiendo errores antes de su lanzamiento (por ejemplo).5 meses 22 díasen este caso).
Esto significa que cualquier error se elimina rápidamente (debido a Many Eyes) y los usuarios típicos no se ven afectados porque se soluciona antes de su lanzamiento oficial.
Escritores de códigos expertos
Las personas que son buenas escribiendo código de alta calidad son las personas que escriben el código. No hay una sola persona sentada escribiendo Ubuntu así:
Hay gente de todo el mundo y gente empleada por Canonical, la empresa detrás de Ubuntu. Todas estas personas contribuyen con un poco de código nuevo. Si escribo 2000 líneas de código, habrá muchos errores. Si 200 personas escriben sólo 10, habrá muchas menos.
Cimentaciones estables
Hasta donde yo sé, Ubuntu no se reescribe desde cero cada vez que hay una nueva versión. En cambio, la siguiente versión comienza como la versión actual (es decir, el 30/04/2015, tanto la 15.10 como la 15.04 eran iguales) y se agregan nuevas funciones a partir de ahí.
Si tiene una buena base desde la cual trabajar, entonces tendrá menos código que escribir y podrá confiar en lo que ya existe. Si puede confiar en lo que hay allí, entrarán menos errores.
Software de versionado y grabación
Si el mismo error aparece más de una vez (en diferentes versiones, o la solución no funcionó, o el error volvió debido a otro parche), entonces tienen la documentación para explicar cómo se solucionó y pueden solucionarlo nuevamente. .
Hasta donde yo sé, no existen pruebas automatizadas. Pero ¿qué es una prueba automatizada? Si se compila, ¿es ese? No se puede decir simplemente "pruebas automatizadas" sin explicar de qué se trata.
Respuesta3
No escriba código con errores. jajaja ok. Perdí la voluntad de escribir una respuesta detallada a esto. Aquí hay un artículo decente: https://www.iiitd.edu.in/~jalote/papers/CommonBugs.pdf
y aquí hay un buen libro sobre cómo hacererrores en c++
La mejor respuesta podría ser simplemente realizar algunas tareas de desarrollo de software y ver usted mismo de dónde provienen los problemas. Manejar entradas/resultados inesperados es un problema bastante grande en mi experiencia. Luego están los errores posteriores. Como si alguien encontrara una vulnerabilidad en iostream.h y cada pieza de software que llame a esa biblioteca también pueda tener ese error, al menos necesita ser revisada.
En cuanto a las pruebas automatizadas, existen, pero también tienen limitaciones. No conozco una solución única que funcione en todos los idiomas. Si estás realmente interesado, escríbenos un depurador de código genético con algo de IA. Hasta donde yo sé, todo esto todavía está en su infancia. Aquí hay algunos trabajos de estudiantes de doctorado: https://www.cs.cmu.edu/~clegoues/docs/legoues-icse09.pdf