Les derniers développeurs de Tous Core d’Ethereum se sont habilités au processus, pas seulement au code: s’il faut honorer une fenêtre de 30 jours précédemment indiquée entre les versions des clients et la première fourche TestNet à mesure que la mise à niveau Fusaka augmente. Certains participants ont poussé à réaffirmer l’engagement afin que les équipes d’infrastructure et d’applications aient le temps de s’adapter; D’autres ont plaidé pour une flexibilité pour éviter un glissement de feuille de route plus large.
Le débat s’est déroulé dans un contexte de résultats de DevNet mixtes. Sur DevNet-3, un exercice non finalité prévu a connu longtemps, par Barnabas Busa de l’équipe Dev Ops. « Nous voulions faire environ deux jours en premier, et maintenant nous frappons le cinquième jour », a-t-il déclaré, notant comment la participation a baissé puis s’est glissée au-dessus de 50%. La finalité nécessite plus des deux tiers de la participation efficace totale en accord.
En revanche, un test séparé s’est rétabli rapidement après un redémarrage coordonné: « La chaîne s’est rétablie, je pense que deux heures », a déclaré Busa. La pression de forage teste comment les variables interagissent dans un incident en direct, ce qui peut aider Ethereum à récupérer en crise.
Avec des correctifs d’atterrissage dans les prochains jours, le plan à court terme consiste à restaurer DevNet-3 en pleine santé, à relancer le test, puis à faire tourner DevNet-5.
Mais le point d’éclair plus large prévoyait une discipline pour les réseaux publics. LightClient a souligné la promesse permanente: «Il dit 30 jours avant le premier testnet.» Il a mis en garde contre le déplacement des poteaux de but pour plus de commodité, sur la base de l’évaluation des développeurs de base du temps nécessaire par d’autres équipes qui ne sont pas présentes sur l’appel.
La préoccupation pratique est de savoir comment améliorer la cadence des fourches dures. La compression des écarts entre les tests peut accélérer les fourchettes, mais augmente le risque que les équipes en aval expédiaient des mises à jour précipitées. Le contre-argument est que les pipelines prolongés retardent tout le reste dans la file d’attente, dont la communauté Ethereum plus large pourrait être mécontente.
« Je ne pense pas que nous devrions choisir des délais en fonction de ce que la communauté veut nécessairement », a déclaré LightClient. «Les personnes qui expédiaient le logiciel ont déclaré vouloir 30 jours pour livrer des logiciels de haute qualité que la communauté va utiliser.»
Malgré cela, l’échange quelque peu épuré a dérivé vers le maintien du processus écrit à moins que les parties prenantes demandent explicitement un changement.
Il y avait également de la frustration de revisiter la même question à chaque cycle. « Je pense juste que c’est un très mauvais précédent de continuer à laisser les décisions changer », a déclaré LightClient, notant que les développeurs d’applications et les L2 ne sont généralement pas sur les appels de base et s’appuient sur des fenêtres prévisibles pour planifier leurs propres versions.
Pour l’instant, le consensus doit procéder comme si le tampon de 30 jours restait en vigueur, tout en sollicitant de manière proactive une nouvelle contribution, a déclaré le coordinateur Tim Beiko. «Nous devons préparer le calendrier avec ce qui est dans le [process] Document puis en parallèle Vérifiez avec les parties prenantes qui sont affectées. » Si une piste plus rapide a vraiment un large soutien, le groupe formaliserait cela par écrit.
