Celery: Cycle de sortie du céleri

Créé le 6 août 2018  ·  32Commentaires  ·  Source: celery/celery

Il n'y a pas de _cycle de publication_ raisonnable pour Celery .
Si quelque chose est cassé, il peut l'être dans la version stable pendant très longtemps, même s'il est en fait corrigé à master .

Étapes à reproduire

  • Correction d'un bug de Celery
  • Fusionner le correctif dans la branche master
  • Fermer le problème le GitHub

Comportement prévisible

Le problème est clos, la version corrigée est publiée.

Comportement réel

Le problème est clos, la version corrigée n'est pas publiée depuis des lustres.
Les gens rencontrent à nouveau ce bogue, deviennent confus et signalent au problème fermé que le bogue n'est pas corrigé.

Exemples

  • #2649
  • #4500
Project Governance Major

Commentaire le plus utile

Notre projet attend la prochaine version pour le support de Python 3.7. S'il y a une façon dont nous pouvons vous aider avec le processus, faites-le moi savoir.

Tous les 32 commentaires

Notre projet attend la prochaine version pour le support de Python 3.7. S'il y a une façon dont nous pouvons vous aider avec le processus, faites-le moi savoir.

Aidez-nous à trouver un sponsor pour maintenir le projet de céleri. c'est la chose la plus nécessaire pour consacrer du temps à cet énorme projet.

@auvipy définit "sponsor" :) De l'argent, du temps ? Beaucoup de gros joueurs utilisant le céleri.

Une approche possible est les versions basées sur le temps, où tout dans le master est simplement expédié (une fois/mois ?). Les corrections de bugs majeurs ou les correctifs de sécurité sont immédiatement expédiés. Vous pouvez obtenir une boucle de rétroaction étroite avec la base d'utilisateurs avec des versions plus rapides. Les gens peuvent épingler des versions dans leur projet selon leurs besoins (nous le faisons) pour éviter un désabonnement inattendu.

Je passe du temps à corriger les bogues, aux améliorations dont mon entreprise a besoin et à essayer de lancer des versions importantes...

@robertknight Sous Problèmes, cliquez sur Jalons, choisissez le prochain jalon et fermez les problèmes en suspens. En règle générale, il y a une douzaine de bogues signalés sans correctif, problèmes de documentation, etc. Voyez-vous si vous pouvez en résoudre certains ?

En entrant, je ne suis pas très pressé de passer à python 3.7 même si ce serait bien. Je cherchais des réponses autour de la version 4.3. Rien. Je comprends et je comprends que le manque d'argent est un problème sur un si gros projet, car il ne peut en être autrement, mais je pense toujours que les choses devraient être faites de manière transparente en disant à tout le monde quels sont les plans à court et à long terme pour Celery. Il n'y a rien de tel que les dernières versions parlent d'elles-mêmes et même si ça me va, je me sentirais plus à l'aise de savoir où mène le projet. Comme le projet principal est vraiment compliqué et a beaucoup de choses à maintenir, comment voyez-vous l'avenir du céleri ? Personnellement, je ne pense pas qu'il soit suffisant d'investir de l'argent dans le projet, car le monde du python change et évolue rapidement, au moins certaines choses devraient être revues et une stratégie devrait être créée.

merci à tous pour vos contributions. à part les problèmes ouverts ici, d'autres choses sont sur mon plan pour l'avenir du céleri,

  1. Libérez le céleri 4.3 dès que possible d'ici octobre.
  2. Supprimez python 2 de la branche master et faites de la branche celery 4.x un LTS avec correction de bogue uniquement jusqu'à la fin de 2019.
  3. adoptez asyncio et son écosystème dans la mesure du possible. révision majeure nécessaire.
  4. Découvrez une alternative asynchrone pour le billard ou réécrivez le billard pour le rendre asynchrone [entrées recherchées]
  5. implémentez quelque chose de natif comme redbeat pour le battement de céleri distribué.
  6. Support Kafka et refonte associée.
  7. Adoptez progressivement les tests basés sur les propriétés et améliorez la couverture des tests.
  8. Améliorez la documentation et corrigez les bogues ouverts.
  9. ajouter d'autres......

Ce sont mes priorités et je vais commencer à travailler pour ces 8 premiers et peut-être que d'autres membres de l'équipe et des membres de la communauté contribueront également à la mise en œuvre des demandes de fonctionnalités et à la suppression des bogues ouverts.
Nous avons également plus de fonctionnalités dans le plan, mais ce sont des priorités minimales pour le moment.

n'hésitez pas à partager vos avis.

Voulons-nous énumérer les problèmes liés à ces fonctionnalités quelque part dans la documentation afin que les gens puissent facilement voir quel est le plan ?
Je sais que pour le n ° 5, nous avons : https://github.com/celery/celery/issues/4815
Pas sûr du reste.

peut-être pouvons-nous créer une section de feuille de route et lier les problèmes liés avec de petites descriptions ? et ajouter une feuille de route dans le fichier readme et la documentation pour la rendre plus visible ?

ça semble être une bonne idée

Je pense qu'il est toujours logique de parler des cycles de publication et du déroulement du projet. Je pense que la future feuille de route et les cycles de publication ne sont que faiblement couplés. Une cadence de publication stable nous donnera un mécanisme pour envoyer des correctifs régulièrement, tandis que la feuille de route aidera à cartographier les travaux futurs sur les cycles de publication. Plus de financement (en argent ou en temps) ne fera que « compresser » la feuille de route.

Je pense que le wiki pourrait être mis à jour avec la feuille de route proposée (au lieu d'encombrer le fichier readme), puis les jalons des problèmes GitHub pourraient être liés, donc c'est clair ce qui a déjà un ticket et ainsi de suite.

Je pense aussi que le Wiki semble être un bon endroit pour documenter la feuille de route.

Pouvons-nous également ajouter un autre élément?
Qu'en est-il de l'ajout de la prise en charge des files d'attente de tâches Redis ?

Pourquoi pas? ne sont-ils pas déjà pris en charge ?

@xirdneh Que veux-tu dire ?

Désolé pour la réponse tardive. Peut-être que je suis un peu confus à propos de celui-ci.
Je pensais que le céleri utilisait le pub/sub de redis, ce qui signifie que les messages sont livrés aux abonnés dès qu'ils arrivent.
Mais nous pourrions également utiliser des files d'attente FIFO dans Redis pour que cela fonctionne davantage comme une file d'attente et pour alimenter le rythme du céleri.
Cette dernière partie est déjà mentionnée dans #4815
S'il vous plaît, corrigez-moi si je me trompe sur l'un de ces @auvipy @thedrow Merci :)

Ok, je crois que je me trompe et Kombu utilise LPUSH et LPOP pour gérer les messages. Je suppose que je pensais à autre chose, mais je suis retourné au code pour le vérifier. Désolé pour ça.

Haha pas de soucis :dagger:

Bonjour. J'ai lu attentivement ce fil, mais je ne vois aucune conclusion concernant le cycle de publication. Comme @mariokostelac l'a fait remarquer, la maintenance et l'ajout de fonctionnalités nécessitent du travail, mais d'un autre côté, publier une nouvelle version lorsque les modifications sont déjà fusionnées sur la branche master ne devrait pas nécessiter autant de travail, pourtant aucune version n'a été publiée depuis quelques mois maintenant. C'était le sujet initial de ce problème soulevé par @Jamim . Par exemple, dans notre entreprise, le seul bloqueur pour l'utilisation de python 3.7 est qu'il n'est pas pris en charge par le céleri. Si je comprends bien, la branche master contient des modifications qui permettent d'utiliser le céleri avec python 3.7 . Y a-t-il une date prévue pour la publication de ces changements ?

@antoine-gallix Probablement @auvipy peut me corriger si je me trompe. Mais je pense que nous ne pouvons pas faire une version prenant en charge python 3.7 tant que nous n'aurons pas fait d'autres tests avec 3.7 et que nous ne l'aurons pas ajouté au flux de travail CI.
Avez-vous pu tester le dernier master avec votre projet et vous assurer qu'il fonctionne correctement ?

En fait, les tests échouent lors de l'exécution avec 3.7 et nous devons corriger https://github.com/celery/py-amqp/issues/206.
Il s'agit d'un projet open source avec très peu de dons. Nous y travaillons pendant notre temps libre.
Des contributions sont nécessaires pour améliorer et soutenir ce projet.
Nous ne pouvons pas vraiment faire de délais. Nous espérons publier dans les mois à venir si les contributions pour prendre en charge Python 3.7 arrivent.

@thedrow C'est tout à fait compréhensible. Merci pour les précisions.

Pouvons-nous trouver quelque part une liste de contrôle de ce qui manque afin de terminer la prochaine version ? Cela nous aiderait à trouver les choses avec lesquelles nous pouvons aider et quel est le statut.

Salut @davidbarton ,
Je crois que vous pourriez regarder les jalons .

@auvipy Mon entreprise a un client qui a besoin du support Kafka. Nous serions intéressés par le financement d'un développeur de céleri pour l'aider à y parvenir. Heureux de parler plus la semaine prochaine si vous le souhaitez.

@ewenger me ping à [email protected]

Salut Messieurs, pourrais-je m'attendre à une date de sortie pour le céleri 4.3.
J'attends les correctifs suivants
https://github.com/celery/celery/issues
https://github.com/celery/celery/issues/4995

Pour ceux qui sont sur ce fil, Celery 4.3 a été officiellement publié

Nous allons bientôt documenter le cycle de publication et la politique de support.
Restez à l'écoute.

Nous allons bientôt documenter le cycle de publication et la politique de support.
Restez à l'écoute.

où puis-je trouver des infos sur la sortie à venir ? Merci.

Nous allons bientôt documenter le cycle de publication et la politique de support.
Restez à l'écoute.

où puis-je trouver des infos sur la sortie à venir ? Merci.

vérifier les jalons Github

céleri publie maintenant des versions mineures de corrections de bogues plus fréquentes.

À mon humble avis, nous devrions nous en tenir aux versions basées sur SemVer et, si possible, à une version continue ou à des correctifs / versions mineures hebdomadaires / bimensuelles / mensuels avec une petite nouvelle fonctionnalité

Cette page vous a été utile?
0 / 5 - 0 notes