Articulo obtenido de Read.cash
Idioma: Inglés
Autor: @freetrader
Título original: BCHN lead maintainer report 2020-03-14
¡Hola comunidades de usuarios de Bitcoin Cash y Bitcoin Cash Node!
Han pasado más de 2 semanas desde el lanzamiento inicial (v0.21.0) de Bitcoin Cash Node, y hoy quiero tomarme un tiempo para informarle sobre lo sucedido desde entonces, y las actividades en las que hemos estado ocupados y estamos trabajando / planificación en este momento.
Con suerte, estos informes se convertirán en una publicación mucho más regular a medida que las cosas se calmen un poco y agilicemos nuestros procesos de proyecto.
Proyecto de captación
Desde su lanzamiento, al menos 3 grupos de minería tienen bloques minados que señalan el soporte del Nodo de Efectivo de Bitcoin (e implican su desacuerdo con el IFP):
pool.bitcoin.com
ASICseer
SBI Crypto
Han surgido varios sitios para monitorear la adopción de /BCHN/mineros / piscinas de señalización:
https://bitcoincash.network/voting/ (al momento de escribir, 6.9% sobre los últimos bloques de 2016 en el período 624961 - 626976)
https://cash.coin.dance/blocks ha agregado un diagrama sobre los últimos 1000 bloques, está al 9,3% al momento de escribir
La señalización de blockchain muestra que el soporte para BCHN entre el hashpower está aumentando constantemente.
Resumen Financiero
El proyecto actualmente está recaudando fondos a través de su dirección de donación de múltiples firmas bitcoincash: prnc2exht3zxlrqqcat690tc85cvfuypngh7szx6mk
Fuente: https://bitcoincashnode.org/
Al momento de escribir, esta dirección contiene 141.0527805 BCH, y aún no se han gastado fondos de la billetera, excepto un gasto inicial poco después de configurarlo:
-0.00000535 BCH: registro de cashaccount
BitcoinCashNode#59780; 🎈
Se recibió una cantidad adicional (1.13385917 BCH) para la dirección 1 ( bitcoincash:pp03e95qz7yene7v4vdx2vfsqx4qsq4wfvw8z3pkjfde la billetera multigrado. Esto se recibió de los fondos de donación recaudados y mantenidos en nombre de BCHN por Coin.dance, quien solicitó una dirección dedicada a la cual transferir estos fondos de retención.
Hay algunos fondos donados al proyecto voluntariamente por grupos mineros que utilizan el Nodo de Efectivo de Bitcoin.
Actualización de elementos de trabajo del proyecto
Primero algunas estadísticas breves de nuestro repositorio de Gitlab :
Desde el inicio:
Cuestiones : 51 planteadas, 18 cerradas, 33 abiertas
Solicitudes de fusión : 100 planteadas, 86 fusionadas, 10 cerradas (léase: rechazadas o abortadas), 4 abiertas
Recordatorio: utilizamos Gitlab para el repositorio de trabajo, Github es solo un espejo para nuestros lanzamientos y versiones etiquetadas del código.
Con respecto a los planes anunciados previamente del proyecto, se han realizado progresos en los siguientes elementos:
Actualizaciones de documentación :
documentos relacionados con el desarrollador / compilación
(gitian, CONTRIBUTING, ninja build docs, cambio de nombre en documentos Doxygen de nivel superior y enlace a https://bitcoindoxygen.art/ )creación de un nuevo documento que describe nuestras reglas de trabajo de Gitlab y el significado de las etiquetas / etiquetas
actualización de la política de divulgación de seguridad
eliminación de referencias obsoletas (Segwit, BIP9, BIP145) en las salidas de ayuda de la interfaz RPC
"Poner en marcha un proceso de desarrollo que sea completamente abierto y atractivo para el público y los nuevos desarrolladores, evaluadores y otros profesionales y aficionados que quieran ayudar a Bitcoin Cash Node" :
Gracias a la generosa ayuda de Alexander Levin de ASICseer, se han establecido puentes entre nuestra holgura de desarrollo y Telegram e IRC, ahora hay un mayor flujo de información.
Alexander también ha ayudado a configurar el registro de canales públicos en nuestra holgura en http://logs.bchnode.org/ . Esperamos que haya más mejoras en el registro, como mostrar desde qué canal se originó un mensaje registrado, pero esto requiere algunas resoluciones de tickets de soporte del proveedor que estamos esperando.Tenemos canales públicos dedicados en nuestro Slack para interactuar con la comunidad:
# dev-general <- nuestro canal principal de desarrollo, abierto a cualquiera
# dev-newbie <- nuestro canal de desarrolladores novatos, visitado por nuestros desarrolladores senior de forma semi-regular. Cualquiera puede preguntar y aprender aquí.
# support-general <- en caso de que necesite más soporte interactivo que a través de problemas de Gitlab, ¡cualquiera es bienvenido aquí!
#testing <- canal de prueba utilizado por el propio proyecto. Damos la bienvenida a cualquier probador de software para unirse, participar, observar, etc.
#quality <- nuestro canal principal de control de calidad, abierto a todos para plantear y discutir cualquier tema relacionado con el aseguramiento de la calidad de nuestro proyecto.
# general-debate <- canal de discusión general, abierto en cualquier tema relacionado con el proyecto que no se ajuste mejor a otros canales. Siéntase libre de preguntar sobre cualquier cosa aquí.
# introducción <- para que los miembros de nuestro Slack se presenten.
"Identificar las lagunas existentes en las pruebas de software , así como las deficiencias de las herramientas y métodos de verificación, y formular planes apropiados para mejorar la garantía de calidad" :
Estoy empezando a trabajar en un plan de verificación y validación de software (VVP) adecuado para este proyecto. Este plan identificará roles y actividades relacionadas con el proceso de V&V, y será un documento vivo que se comprometerá con el repositorio después de la revisión.
Es probable que sea seguido poco después por planes que cubran otras partes del ciclo de vida del software (desarrollo, mantenimiento, proceso de control de calidad, etc.). Documentar estos aspectos del proyecto probablemente será una actividad de varios meses, ya que simultáneamente estaremos ocupados en muchas otras cosas (no tenemos el lujo de detener el desarrollo continuo para pulir primero nuestros planes y procesos a la perfección).
He comenzado a recopilar listas de verificación de revisión en base a las cuales construiremos una base de datos de listas de verificación de control de calidad para usar durante varias actividades del proyecto (comenzando desde los requisitos, los planes de prueba y la revisión del código y expandiéndolo para cubrir el diseño, la implementación y la configuración / administración de versiones)
"Configuración de procesos de creación y lanzamiento reproducibles más eficientes" :
Después del lanzamiento inicial, obtuvimos una idea de dónde necesitamos mejorar (por ejemplo, formatos hash de compilación comunes), y planeamos realizar un lanzamiento menor en la próxima semana o dos para practicar y perfeccionar un poco nuestro proceso de lanzamiento.
"Revisando nuestra infraestructura de proyecto (sembradoras, semillas) y buscando configurar un mejor alojamiento de archivos para nuestros paquetes de lanzamiento " :
Revisaré nuestras semillas / sembradoras antes del próximo lanzamiento menor (1-2 semanas a partir de ahora).
"Configuración de la implementación continua de nuestro proyecto a través de la integración de Gitlab / Docker con miras a configurar pruebas adicionales, externas a Gitlab" :
Las compilaciones de Docker aún no están automatizadas a través de Gitlab. Josh Ellithorpe nos ha ayudado amablemente en la disposición de compilación Docker de la versión inicial. El proyecto ha registrado una cuenta de Docker y se necesitará un poco de trabajo para integrar nuestra tubería de Gitlab con Docker. Es posible que esto no se complete antes de la próxima versión menor; depende de los recursos del desarrollador.
"Establecer nuestro proceso de soporte y contacto" :
Hemos actualizado nuestro documento de política de divulgación de seguridad y contactado con varios otros proyectos para establecer una relación de divulgación mutua.
Hasta ahora, se han establecido relaciones con BCHD, Flowee y Knuth, con más esperanzas de seguir pronto.
"Establecimiento de un proceso responsable y transparente para financiar el mantenimiento y desarrollo continuos de Bitcoin Cash Node" :
Parte de esto es la información financiera que estoy comenzando con esta publicación, para mantener a todos al tanto del estado de la financiación del proyecto, nuestros ingresos y gastos y los planes en torno a eso. Hablando de planes, voy a trabajar en una propuesta de recaudación de fondos para la campaña Flipstarter, que requiere que se envíe un plan antes del 30 de marzo de 2020. Se proporcionará más información sobre nuestro plan a medida que avance en forma revisable. Tengo una oferta de asistencia para trabajar conmigo en esto desde @imaginary_username (¡gracias!)
"Defining further roles that the project seeks to establish, such as professional liaison with key users of our software and engagement with wider Bitcoin Cash user base":
A role for such a liaison position has been written up by @emergent_reasons, but I have not published on it yet as I expect it might flow into the Fundraising Proposal together with definition of some other roles that the project will seek to fill.
"Evaluating the amount of personnel available for the planned tasks and crafting an appropriate budget for the upcoming fundraiser":
This forms part of my proposal drafting work to be completed until 30 March - with the help of many project members on whose inputs I will depend.
Contact with other client teams regarding feature implementation
Xversion (Bitcoin Unlimited, champion: Greg Griffith)
Bitcoin Cash Node was approached by BU developer Greg Griffith with a request to implement the xversion protocol message in BCHN.
There was healthy discussion both internally and on the Gitlab issue tracker (ref. https://gitlab.com/bitcoin-cash-node/bitcoin-cash-node/-/issues/45) and it seems BCHN developers are not opposed to the latest proposition to implement xversion based on a service bit. More technical discussion and refinement of an adapted specification is expected, but the process also led me to formulate a rough set of guidelines for what BCHN needs from other clients who want to bring features across into it:
BCHN Lead maintainer's general "requirements" for accepting merge requests from other implementations:
(I have yet to formally describe these in our project documentation, and they are subject to review, but I'm listing here the common sense ones known at this time.)
Conforming to our coding style which is basically identical to Bitcoin ABC still, but we have internally agreed on a soft line length limit of 80 and a hard one of 132 for the C/C++ code - the rest stays the same as ABC for now (Python code etc)Accompanied by covering tests and appropriate documentationAccepted and validated upstream (in that case it means merged and tested in the other client). We will then verify it on BCHN and suggest adjustments that might be necessary technically.Our users must support the feature/fix that is proposed. This is ensured by raising such cross-port proposals via issues on our Gitlab tracker, where they can be seen and discussed by all our users, correctly assessed and prioritized.
Xthinner (independent, Jonathan Toomim)
Bitcoin Cash Node was approached by Jonathan Toomim to discuss whether Xthinner and parts of the stress testing tooling developed for it, could be incorporated in BCHN.
The discussion and thinking about it (on BCHN side) is still in early phases, but interesting observations have been made by Jonathan with regard to the rather slow, but also good coin selection algorithm used in the node code, which could be augmented by an alternative, faster but less optimal coin selector, useful in some situations (such as stress testing for bigger blocks).
Generally, I see a lot of potential for the cooperation between Bitcoin Cash Node and Jonathan on these features.
State of BCH specification repository & IFP (non-)consensus
As some of you might be aware, I and other developers raised objections when the IFP proposal - roughly as previously described by Jiang Zhuoer and implemented by Bitcoin ABC - was merged into the "Bitcoin Cash organization"'s specification folder in the bitcoincash.org repository on Github, against the expressed disagreement with the IFP by many in the Bitcoin Cash community.
Not only did the specification merge occur despite the protests, but also
against established convention not to merge extremely controversial consensus changes into what was supposed to be the commonly used repository for the regular hard-fork upgrade specifications
Eighteen (18) days after the feature freeze of the specification!
So I entered a Pull Request on Github to revert this IFP merger.
The discussion was subsequently locked and closed by the maintainer(s), who refused to reveal themselves despite my repeated enquiries about who made these decisions.
Additionally, I found out via automated email notification that my Github account (ftrader) had been removed from the Bitcoin Cash organization on 3 March, again by parties unknown and unwilling to acknowledge their responsibility. I raised an Issue on Github to ask about this, which has been ignored for the last five (5) days now.
Dos solicitudes de extracción de nuestro equipo de proyecto para agregar el cliente Bitcoin Cash Node a la lista de nodos completos en el sitio web bitcoincash.org también han sido rechazadas por razones espurias:
Este tratamiento de nuestro proyecto y las preocupaciones de la comunidad sobre el IFP por parte de "la organización Bitcoin Cash" nos animará a mí y a muchos de los que apoyan Bitcoin Cash Node y están en contra del IFP y no lo consideran parte de la actualización de mayo de 2020 , para buscar alternativas cuando se trata de un hogar para la especificación del protocolo Bitcoin Cash e información sobre implementaciones compatibles para la próxima actualización de la red en mayo.
Viendo hacia adelante...
Ayúdenme con su contribución a la dirección del proyecto BCHN, dándome su opinión en los comentarios a continuación y también participando en la Encuesta de la comunidad de Bitcoin Cash Node de marzo de 2020 : el uso inaugural del Sistema de consulta pública de BCHN .