Se sabe que Linus Torvalds es muy quisquilloso con los procedimientos y estándares que deben seguir quienes colaboran con el desarrollo del núcleo Linux. Y, no suele ser muy amable con quiénes no están a la altura.  Recordemos que en el pasado se retiró un tiempo de su rol para replantearse la manera en que se relacionaba con otras personas.

Está vez, quien incurrió en su desagrado, fue Paragon Software, la empresa detrás del driver NTFS3.  Anunciado para la versión 5.15 del núcleo Linux, mejorará el soporte para el sistema de archivos nativo de Windows.

Los sistemas de control de versión (SCV)

Para que esta historia se entienda, vamos a explicar algunos detalles que no todo el mundo tiene por que saber.

Los desarrolladores de proyectos de software muy complejos utilizan un software de control de versión (En general operado por un proveedor externo en la nube) Este software, permite hacer el seguimiento de quién, cuándo y qué realiza modificaciones.

Si no eres parte de los miembros del proyecto, puedes hacer una bifurcación (fork), es decir copiar los archivos del proyecto a tu propio repositorio y, en él realizar tus propias modificaciones. En el caso de que te guste el resultado puedes sugerirle al administrador del proyecto original que las incorpore, mediante la llamada pull request.

La liberación del controlador

El año pasado, Paragon Software anunció la liberación del código del controlador, que anteriormente comercializaba, comprometiéndose además a ocuparse del mantenimiento y actualización. Esto es una buena noticia ya que es mucho mejor que el que utilizábamos actualmente.

Según la propia empresa

La versión actual funciona con archivos normales/comprimidos/espaciosos y soporta acl, reproducción del diario NTFS. La mayor parte del código estaba en la rama linux-next desde el 13 de agosto, pero hay algunos parches, que estaban en la rama linux-next sólo por un par de días. Esperemos que esté bien – no se detectó ninguna regresión en las pruebas».

Después del anuncio de Paragon, el controlador NTFS3 tuvo que pasar por muchas rondas de revisión para mejorar la calidad del código y hacer que cumpla con los estándares de codificación del resto del núcleo.

Parece que finalmente lo logró.

Y así llegamos a la madre del borrego.

Linus resta a Paragon

Para poder incluir el controlador en la versión 5.15 del núcleo, Linus Torvalds le pidió a Paragon Software que realizara la pull request de la que hablábamos arriba. La empresa lo hizo, pero no en la forma en la que le gusta a Torvalds.

La primera observación del finlandés fue que la pull request debería haber sido firmada.

En un mundo perfecto, se trataría de una firma PGP que pudiera rastrear directamente hasta ti a través de la cadena de confianza, pero nunca lo he exigido

En segundo lugar, se quejó que la pull request se había realizado desde la interfaz web del servicio lo que produce mucho código basura.

Github es un sitio de alojamiento perfectamente bueno, y también hace una serie de otras cosas bien, pero las fusiones no es una de esas cosas

También protestó por la falta de información suficiente.

Para el creador de Linux «las fusiones del kernel de Linux deben hacerse de manera apropiada». Y añadió: «Eso significa mensajes de confirmación adecuados con información sobre lo que se fusiona y *por qué* se fusiona algo. Pero también significa una información adecuada sobre la autoría y el committer, etc. Todo lo cual GitHub estropea por completo».

Linus Torvalds sabe de lo que habla, el fue el creador de Git, el software en el que se basan servicios como GitHub, ahora propiedad de Microsoft.  Y, curiosamente fue por disconformidad con otro servicio

En realidad nunca quise hacer un programa de control de versión ya que los odiaba a todos…entonces llegó BitKeeper y realmente cambió mi forma de verlos. BK acertó en la mayoría de las cosas y tener una copia local del repositorio y la fusión distribuida fue algo muy importante. La gran cosa sobre el control de origen distribuido es que hace que uno de los principales problemas con los SCV s desaparezca – la política en torno a «quién puede hacer cambios».

BK demostró que se puede evitar eso dando a todo el mundo su propio repositorio. Pero BK también tenía sus propios problemas; había algunas decisiones técnicas que causaban problemas (los renombramientos eran dolorosos), pero el mayor inconveniente era el hecho de que, al no ser de código abierto, había mucha gente que no quería usarlo. Así que, aunque acabamos teniendo varios mantenedores del núcleo que utilizaban BK – era de uso gratuito para los proyectos de código abierto – nunca se hizo masivo Así que ayudó al desarrollo del núcleo, pero no era perfecto.

Así que en algún momento decidí que no podía seguir usando BK, pero que realmente no quería volver a los viejos y malos tiempos pre-BK. Lamentablemente, en ese momento, mientras que había algunos otros SCV que más o menos trataron de conseguir la cosa distribuida, ninguno de ellos lo hizo remotamente bien. Tenía requisitos de rendimiento que no eran ni remotamente satisfechos por lo que estaba disponible, y también me preocupaba la integridad del código y todo el flujo de trabajo, así que terminé decidiendo escribir el mío propio.