¿Qué tan útil es, en realidad, informar errores contra packages estables?

Si el error se soluciona en una versión más nueva (Prueba o inestable) del package, ¿hay alguna esperanza de que la solución llegue a Estable antes de la próxima versión principal? Me imagino que no, a less que tenga severidad Grave o similar.

¿Es realmente útil para los desarrolladores que trabajan en versiones que son quizás dos o incluso tres años más recientes? Me gustaría ser tan útil en el informe de errores como pueda, y con ese fin, me gustaría configurar una installation Sid en una máquina virtual para que pueda tratar de reproducir mis errores Estable antes de informarlos, pero incluso si el el error aún está presente en la versión más nueva, ¿realmente los desarrolladores prestarán mucha atención a un error informado contra Stable?

Supongo que hay muchas preguntas adicionales acerca de esto que no puedo express con palabras, pero básicamente, me encantaría saber de algunos desarrolladores si les estoy molestando o si informar errores sobre packages viejos es realmente útil. .

Para aclarar primero, hay una diferencia entre un package de distribución (binary) y el package fuente original. Mientras algunas distribuciones dividen repositorys en, por ejemplo, "testing", "inestable" y "estable", y algunos desarrolladores también mantienen una versión "estable", "inestable", "nocturna", etc., estos no son los mismos ( pero los numbers de versión sí corresponden).

También tenga en count que el "package fuente" aquí no se refiere al package -src la distribución. Se refiere a la fuente original distribuida independientemente de la distribución. Es decir, estos son packages que normalmente no usa directamente: la distribución los vuelve a empaquetar en su forma binaria (y -src ).

Por ejemplo, mantengo la fuente original de foobar ; el package fuente estable actual es 1.2.4 y el package fuente inestable actual, 1.2.5 . Debian (no yo) empaqueta esto para su distribución; su versión repo estable actual es 1.2.3 y su versión repo de testing actual es 1.2.5 . Yo (el desarrollador original) no soy responsable del package Debian, o qué versión fuente está en qué package repo. No hago la compilation o el empaquetado de la versión binaria de la distribución. Solo mantengo la fuente original.

Los informes de errores para estos también están separados. Como desarrollador original, puedo o no leer y responder a los errores reportados en un package de distribución. De lo contrario, y el problema debería preocuparme, el distribuidor de la distribución presentará un informe sobre la fuente original.

Si el error se soluciona en una versión más nueva (Prueba o inestable) del package, ¿hay alguna esperanza de que la solución llegue a Estable antes de la próxima versión principal?

Las reparaciones rara vez se respaldan, es decir, si su package distro estable es 1.2.3 y sabe que 1.2.5 tiene una solución, entonces, a less que la próxima distro estable sea 1.2.5, no contendrá la corrección. Es decir, si la distribución libera 1.2.4 como el siguiente establo, la solución de 1.2.5 no será retransferida a ella, por lo que el error seguirá allí.

Los errores que se relacionan con la fuente (WRT a los packages binarys, a veces no) requieren que el desarrollador original repare la fuente en una nueva versión, que luego se incorpora a la versión correspondiente del package de distribución. Hay algunas excepciones a esto ya que las distribuciones en algún momento parcharán las cosas por sí mismas y agregarán un sufijo a la versión para indicar (por ejemplo, 1.2.4-1 ) aunque no, creo, en los casos en que la solución está en una versión posterior de la fuente.

¿Es realmente útil para los desarrolladores que trabajan en versiones que son quizás dos o incluso tres años más recientes?

Eso depende de si el error ha sido reparado o no. El objective del control de versiones es que se solucione: no se cambia la versión 1.2.3 después de su lanzamiento, pase lo que pase. Si arreglas algo en 1.2.3, esa corrección aparecerá en la próxima versión. Si es algo que se ha roto durante años, ese lanzamiento puede ser 1.2.6, etc.

Entonces, si sabes que algo está arreglado en una versión posterior de la fuente, entonces sí, informarlo a los desarrolladores originales no tiene sentido. Sin embargo, si es el establo actual utilizado por su distribución y el error no se ha informado allí (recuerde, los errores reportados para la fuente y para el package no son los mismos), entonces debe informarlo e indicar que está solucionado. en una versión posterior de la fuente. Nuevamente, recuerde que las personas responsables de los packages de distribución y sus informes de errores no son los mismos que los desarrolladores originales. Así que, aunque es posible que ya haya solucionado el problema, es posible que los empaquetadores de distribución no lo sepan o no lo tengan en count. Aunque es probable que se hayan mantenido informados, al informarles el problema (no a mí), se lo ha señalado explícitamente, lo que puede motivarlos a actualizar el package estable (las diferentes distribuciones utilizan diferentes criterios para esto).

En primer lugar, el informe de errores generalmente es una buena idea, incluso si a menudo es un trabajo ingrato, como muchas cosas en el software libre.

Para tomar sus preguntas en order,

Si el error se soluciona en una versión más nueva (Prueba o inestable) del package, ¿hay alguna esperanza de que la solución llegue a Estable antes de la próxima versión principal?

Probablemente no. Normalmente, las correcciones con respaldo a estable son solo para fines de security.

¿Es realmente útil para los desarrolladores que trabajan en versiones que son quizás dos o incluso tres años más recientes?

Si encuentra un error en una versión estable, lo primero que debe hacer es tratar de reproducirlo para la versión actual de ese software, o al less una versión más reciente. A menudo estará disponible en inestable, por lo que puede intentar respaldar la versión inestable a estable, o simplemente probarla en un sistema inestable. Si el error se puede reproducir en la versión inestable, generalmente consulto con la list de correo del proyecto si otros pueden reproducirlo. A veces solo informo el error.

Tenga en count que incluso si la versión inestable es la versión más reciente, el error puede solucionarse en la versión de desarrollo, así que a less que esté probando la versión de desarrollo actual del software (normalmente disponible solo en el repository de software), puede ' Asegúrese de que el error no haya sido resuelto. Sin embargo, a menudo soy demasiado perezoso para probar en contra del código absolutamente vanguardista, en parte porque no se ha empaquetado, y me gusta trabajar con software empaquetado. Pero YMMV.

Si el error se solucionó en una versión más reciente del software, generalmente no lo informo. En teoría, uno puede hacerlo, pero a los desarrolladores iniciales ciertamente no les importará, y es muy poco probable que a los desarrolladores de Debian del software les importe.

Finalmente, escribes:

pero incluso si el error aún está presente en la versión más nueva, ¿los desarrolladores> prestarán mucha atención a un error informado contra Stable?

No entiendo lo que esto significa. Si el error está presente en una versión más reciente, infórmalo contra la versión más nueva. ¿Por qué informarlo contra la versión estable?