No mantenedor sube a Hackage

Question

Tengo un paquete en Hackage que depende del paquete de un tercero, que no se basa en las versiones más nuevas de GHC (> = 7.2). El problema con el otro paquete se puede resolver con solo un parche de una línea (un pragma LANGUAGE). Envié el parche al upstream dos veces, pero no recibí ningún comentario. El problema es que mi paquete no se puede instalar ni hasta que se resuelva la dependencia.

Pude haber cargado la versión fija del paquete depenency (con un bache de versión menor), pero me gustaría saber cuál es la actitud de la comunidad con respecto a esas cargas que no se mantienen. De nuevo, no quiero cambiar la interfaz de la biblioteca, solo agrego un nuevo indicador de compilación para que se pueda volver a compilar.

• ¿Se permiten y toleran las subidas de elementos no responsables del mantenimiento a Hackage?
• ¿Cuándo un tenedor del paquete en Hackage es un mejor enfoque?

Answer 1

archivos del paquete por parte de no mantenedores están permitidos (puede haber problemas de licencia, pero la mayoría de los paquetes si no todos en hackage tener licencias que permiten esto), pero por supuesto que no se realiza. Se toleran si se hacen de buena fe y con un procedimiento razonable. Si se contacta con el responsable y no recibe ninguna respuesta en un plazo de n semanas (donde no estoy seguro de cuál es el valor apropiado de n, no menos de 3, diría), cargar una nueva versión usted mismo se convierte en una opción, Discutir eso en las listas de correo parece sin embargo más prudente. Si el paquete parece abandonado, incluso hacerse cargo del mantenimiento -por supuesto, una vez más ponerse en contacto con el mantenedor, darle tiempo a él/ella para responder- puede ser la acción adecuada, pero eso definitivamente debería discutirse con la comunidad (haskell-cafe o lista de correo, por ejemplo). Ya sea que prefiera una carga que no sea mantenedor o un tenedor debe dejarse a su juicio, personalmente tiendo a creer que los tenedores pisan menos los dedos de los pies.

Pero una respuesta mejor fundada sería posible si supiéramos qué paquete se trata y podríamos ver la situación concreta.

Answer 2

Un forking es intrusivo para un paquete que sospecha que se mantiene pero el autor falta temporalmente. Por intrusivo, quiero decir que otros programadores pueden recoger su tenedor y luego no volver a la línea principal una vez que el autor original ha reanudado el trabajo en la línea principal.

Para los paquetes en los que el autor original ha salido de la comunidad Haskell, mi opinión personal es que es mejor tirar el paquete si va a desarrollarlo más. La bifurcación evita problemas de sucesión, como los que ocurrieron con Parsec, donde muchos desarrolladores no quisieron actualizar porque el sucesor fue más lento y menos documentado que el original durante un tiempo.

En todos los casos, preguntar en el Café es lo mejor, independientemente de si la gente ha elegido no seguirlo, sigue siendo el centro de la comunidad Haskell.

Para el caso particular en la pregunta, si bien es bueno si las cosas en Hackage se compilan, no hay ninguna regla que diga que deben hacerlo. Un paquete que depende de un paquete roto simplemente podría poner instrucciones de cambio para la dependencia interrumpida en su página frontal, es decir, "Este paquete depende de LambdaThing-0.2.0 que está roto, para arreglar LambdaThing agregar ... al archivo Lambda. hs "

Answer 3

Yo diría que es una muy buena idea consultar las listas de correo con respecto al paquete específico y la persona específica que falta. Tomé el control del paquete haskell-src-meta de su propietario original, pero solo después de consultar con las listas e IRC, quien me aseguró que Matt Morrow había estado desaparecido durante meses y nadie sabía por qué.

En mi opinión, la propiedad del paquete probablemente solo debería cambiarse si hay consenso para hacerlo, o al menos debería haber esfuerzos para encontrar uno. En la versión de desarrollo del software Hackage, entiendo que hay controles de acceso para que solo los administradores puedan realizar este tipo de intervención.