QA/Bibisect/Tutorial sobre bisección binaria o bibisección

TDF LibreOffice en español Document Liberation Project Blogs comunitarios Weblate Nextcloud Redmine Preguntas y respuestas Donar

• Inicio
• Desarrollo
• Diseño
• Control de calidad
• Eventos
• Documentación
• Sitio web
• Regionalización
• Accesibilidad
• Mercadotecnia
• Diversity
• Wiki Help

• Informes de error
• Cómo confirmar
• Proyectos
• Pruebas antirregresiones
• Pruebas automatizadas
• Bisección binaria
• Reuniones
• Preg. Frecuentes

Introducción

Este tutorial le mostrará cómo encontrar el cambio de código que causó un error de regresión. Es una buena idea, como su primer paso de aprendizaje, pasar por una investigación clara, porque a veces la búsqueda binaria por bisección (bibisección o bisección binaria) y sus resultados pueden ser complicados.

Video

A continuación verá un videotutorial realizado bajo Windows 10 y que utiliza PowerShell 7. (Hay pocos diálogos en inglés. No hay subtítulos, pero puede leer las versiones en inglés y en español ).

• I download the git setup / Descargo lo necesario para configurar git
• The second option, for line endings, is what it's used in LibreOffice development / La segunda opción, para finales de líneas, es lo se usa en el desarrollo de LibreOffice
• I give the command for downloading the git bundle / Proporciono la instrucción para descargar el paquete extra para git
• I cloned the repository from the bundle / He clonado el repositorio del paquete extra
• I remove the bundle / He eliminado el paquete extra
• I enter the bibisect directory and give the command to checkout the oldest commit and launched LibreOffice with the problematic file / Ingreso al directorio de bibisección y proporciono la instrucción para hacer el «ckeckout» del «commit» más antiguo
• Now I checkout the latest commit and take a look at the file again / Ahora hago el «checkout» del «commit» más reciente y reviso el documento otra vez
• Now I start the bisecting process / Ahora inicio el proceso de bibisección
• The file refused to open, so I mark the commit as bad / Como el archivo no pudo abrirse, marco el «commit» como malo
• Here the file opens just fine, so I mark the commit as good / Aquí abre bien el archivo, así que marco el «commit» como bueno
• Finally, we have the commit that is blamed for the problem / Finalmente, tenemos el «commit» que es culpable del problema.

Prerrequisitos

Para trabajar en la bibisección o bisección binaria, necesita familiarizarse con el papel que juegan los directorios⁠ y las rutas⁠ y cómo navegar en un sistema jerárquico de archivos⁠. Es absolutamente crítico comprender cómo averiguar la localización actual en el sistema de archivos, como moverse a través de él, en dónde se guardan los archivos descargados y cómo mover archivos a diferentes directorios. De otra manera, desperdiciará muchas horas…

Cuando se sienta cómodo con el concepto de archivos y directorios en el contexto de las aplicaciones gráficas y los gestores de archivos, no le costará mucho aprender a manejarse en la línea de órdenes (también conocida como línea de comandos). La Red de Desarrolladores de Mozilla (Mozilla Developer Network) ha desarrollado un curso de iniciación a la línea de órdenes [1], que sirve para los principales sistemas operativos. El MIT (Instituto de Tecnología de Massachussets) tiene más cursos enfocados a Unix/Linux para el «shell» [2] y para la línea de órdenes [3]. El curso sobre el «shell» del MIT es útil todavía como curso general, pues macOS es un derivado de Unix y PowerShell acepta muchos de los comandos estándar de Unix. Note que todos estos cursos, por el momento, solo están disponibles en inglés.

Preparación

Investigaremos un «bug» que evita que se abra un documento. Validar y probar el «bug» no puede ser más simple: la única acción requerida es tratar de abrir el documento.

Desafortunadamente, debido a asuntos de compatibilidad retroactiva en el ámbito del sistema operativo, el repositorio de bibisección específico en este tutorial no funciona con las recientes versiones de Linux y macOS. Los validadores de Linux y macOS pueden hacer, en cambio, lo siguiente y adaptar los pasos del tutorial para que coincidan con los del «bug» elegido.

1. Vaya a la búsqueda avanzada de bugs en Bugzilla (en inglés)
2. En el campo «Summary», ingrese fileopen crash (sin las comillas y en inglés)
3. Elija --- y FIXED (ambos sin comillas) en «Resolución». Use la tecla <keycode>Ctrl</keycode> para seleccionar más de un elemento en la lista.
4. Añada las palabras clave bisected, regression (sin comillas) en el campo «Keywords» de la sección «Detailed Bug Information»
5. En la sección «Custom Search», seleccione Version (sin comillas) en la segunda lista desplegable y matches regular expression (expresiones regulares o «regex») en la tercera; luego, ingrese el patrón de inicio con que coincida con una versión más reciente. Por ejemplo, use ^7 para incluir todas las versiones que comiencen con 7 o use ^7\.6 para limitar a una versión mayor más específica.

Finalmente, pulse el botón «Search».

1. Clone the respective bibisect repository and test the issue with it (Linux, macOS)

Para tener una idea de cuál es el intervalo de versiones donde apareció el bug, normalmente necesitaría probar con múltiples repositorios de bibisección o usar diferentes versiones instaladas en paralelo. Para hacer las cosas simples en este tutorial, comenzaremos con el supuesto de que el «bug» apareció en el intervalo de versiones de la serie 6.1 (desde la rama 6.0 hasta la rama 6.1, pasando por las versiones menores 6.1.x).

Para configurar el ambiente de trabajo de bibisección en Windows, Linux o macOS, instale git. En el caso de la instalación en Windows, es importante seleccionar la opción “Checkout as-is, commit Unix-style line endings” (“Hacer checkout tal cual, hacer «commit» con finales de línea tipo Unix”). Esto es necesario si alguna vez usted participa en el desarrollo de LibreOffice. (Vea el video de arriba, donde en el segundo 44 se muestra cómo habilitar las casillas para seleccionar esta opción).

A continuación, desde la línea de órdenes del «shell», descargue el repositorio 6.1.

Windows (Nota: Lea todas las instrucciones que vienen en el enlace; solo el paso 1 se hace de manera diferente al usar PowerShell).

Descargue la aplicación para usar PowerShell en Windows. (No use el PowerShell 5, sino el último disponible):

Invoke-WebRequest -Uri https://bibisect.libreoffice.org/win32-6.1.git-bundle -OutFile win32-6.1.git-bundle -Resume

Linux

macOS

La descarga y el procesamiento del repositorio podría tomar un tiempo relativamente largo (quizás una hora, dependiendo de su computadora).

Cuando lleve a cabo los pasos para la descarga y el clonado, asegúrese de estar trabajando en el directorio correcto. Por tanto, si hace una pausa y apaga su computadora, debe recordar cambiar al directorio correcto la próxima vez que la encienda.

Note que en macOS podría tener que hacer clic con el botón secundario y seleccionar abrir en Finder para verificar la aplicación la primera vez que use un nuevo repositorio de bibisección.

Bibisección (bisección binaria)

1. Descargue el adjunto (attachment) 157140 desde tdf#130093. Para el resto de los pasos, se asume que el documento está en su directorio habitual de descargas.
2. En la línea de órdenes del «shell», use la instrucción cd para ir al directorio del repositorio de bibisección.
3. Ejecute las instrucciones encadenadas para hacer «checkout» del «commit» más antiguo en el repositorio y tratar de abrir el documento problemático:
   Windows:

   git checkout oldest && instdir\program\soffice 'C:\users\username\downloads\Lotus testfile.lwp'

   
   Linux:

   git checkout oldest && instdir/program/soffice ~/Downloads/Lotus\ testfile.lwp

   
   macOS:

   git checkout oldest && LibreOffice.app/Contents/MacOS/soffice ~/Downloads/Lotus\ testfile.lwp

4. Observe cómo el documento se abre sin problemas.
5. Ejecute las mismas instrucciones pasadas, pero remplace oldest con master. En la línea de órdenes del «shell», puede acceder a las instrucciones encadenadas del paso anterior usando las teclas con flechas. Use las teclas «Arriba», «Abajo», «Inicio» y «Fin» y modifique la instrucción.
6. Observe cómo obtiene un error general de entrada/salida cuando usa el documento en el «commit» más reciente del repositorio.
7. Si durante el proceso obtiene un error que indica que los cambios locales de algunos archivos Python pueden ser sobrescritos por el «checkout», use esta instrucción en la línea de órdenes del «shell» para descartar los cambios:

   git checkout .

8. Nuevamente en la línea de órdenes del «shell», regrese a las instrucciones encadenadas, pero ahora remplace completamente la primera con la siguiente instrucción:

   git bisect start master oldest

9. Traiga las instrucciones encadenadas pasadas y, SOLO SI EL DOCUMENTO ABRE BIEN, remplace la primera instrucción con

   git bisect good

   
   SI VE EL ERROR O SI FALLA EL PROGRAMA AL ABRIR EL DOCUMENTO, remplace la primera instrucción con

   git bisect bad

10. Continúe esta danza de buenos y malos hasta que vea un bloque de texto como este:

   a8220993df5ae8b0e673e536c0d9dd7b458e55db is the first bad commit
   commit a8220993df5ae8b0e673e536c0d9dd7b458e55db
   Author: Norbert Thiebaud <nthiebaudgmail.com>
   Date:   Mon Feb 12 13:20:52 2018 -0800

       source sha:22fc8c634c5f9b09d45aff0403503f4d8226328d

       source sha:22fc8c634c5f9b09d45aff0403503f4d8226328d

Análisis

El resultado del «commit» malo proviene del repositorio 6.1 de Windows. El «commit» malo se refiere a la compilación binaria en el propio repositorio. El «commit» causante está señalado con la cadena hash después de source sha:. La persona indicada por Author: es quien creó el repositorio de bibisección y no tiene nada que ver con el «bug» de la regresión.

Si quiere verificar que el resultado es correcto, puede hacer un «checkout» para el «commit» binario (el hash exacto depende del repositorio que se use):

   git checkout a8220993df5ae8b0e673e536c0d9dd7b458e55db

Trate de abrir el documento (debería ver el error de lectura). Luego, haga «checkout» del «commit» anterior con la siguiente instrucción:

   git checkout HEAD^

Ahora debe ser capaz de abrir el documento.

Puede ver los detalles del cambio de código si toma la cadena source sha, la pone en una URL y visita el enlace:

https://git.libreoffice.org/core/commit/22fc8c634c5f9b09d45aff0403503f4d8226328d

En los cambios de código podemos ver el «bug» tiene que ver con el módulo lotuswordpro, lo cual está en línea con el tema en cuestión.

Cómo hacer públicos los resultados

A veces, una regresión ya ha sido informada y analizada. Esto significa que siempre deberíamos hacer una búsqueda en Bugzilla antes de declarar nuestros resultados.

1. Vaya a la búsqueda avanzada en Bugzilla (en inglés).
2. Mantenga presionada la tecla <keycode>Ctrl</keycode> y haga clic con el botón primario sobre los tres guiones --- en el campo «Resolution:». Con esto podrá buscar tanto los informes abiertos como los cerrados.
3. Expanda la sección «Detailed Bug Information».
4. Pegue la cadena source sha: en el campo «Comment».
5. En el campo «Keywords», ingrese regression y haga clic en el botón «Search».

En caso de no encontrar ningún informe, haga lo siguiente en el informe para el que solicitó la bibisección:

1. Elimine la palabra clave bibisectRequest del campo «Keywords» y ahí mismo adicione la palabra clave bibisected.
2. Si ha identificado al «commit» que causa la regresión (como en este tutorial), también agregue la palabra clave bisected.
3. Adicione el correo electrónico del desarrollador involucrado en el bug a la lista CC del informe. (Nota: Recuerde que el autor de los «commits» del repositorio de bibisección NO es el desarrollador involucrado). Para ver el correo electrónico del desarrollador, debe ver los detalles del «commit» del código, como se describe en la sección Análisis de arriba.
4. Agregue también el nombre del desarrollador involucrado en el bug al campo «Regression By». Si no encuentra este campo, pida a alguno de los miembros de The Document Foundation para que le añadan a usted en el grupo Contribuidores en la aplicación de Bugzilla (y pueda ver a los otros).
5. En el campo de comentarios del informe, mencione qué repositorio de bibisección usó, muestre el «commit» causante e incluya el texto Adding Cc: to <nombre del desarrollador involucrado>.