/assigner @apelisse

On dirait que nous avons encore besoin de documents pour préparer cette fonctionnalité à la sortie @apelisse
Pourrais-je obtenir de l'aide s'il vous plaît? Si je peux faire quelque chose pour vous aider, faites-le moi savoir

Au minimum, nous cherchons à avoir un espace réservé PR sur le dépôt kubernetes/site Web. Le processus est assez simple : extrayez la branche release-1.11 , faites un commit d'espace réservé, poussez-le vers votre fourche et augmentez un PR entre elle et la branche release-1.11 , avec le statut /hold .

MERCI BEAUCOUP!!!!!

@apelisse J'ai remarqué le changement d'étape. Envisagez-vous de retirer cela de la version 1.11 ?

Ouais, pas dans 1.11. Je mets à jour le corps.

Merci @apelisse !

Je ne sais pas si c'est le bon endroit pour commenter cela, mais nous avons travaillé sur notre propre type de "application côté serveur" en créant https://github.com/seibert-media/dimios
Bien qu'il s'agisse uniquement d'un projet de temps mort sur lequel nous espérons construire notre future interaction avec Kubernetes, nous avons tous les deux rencontré des problèmes avec l'ensemble du processus de candidature (discuté du temps mort avec certaines personnes), mais nous avons également réfléchi à la meilleure façon d'aborder cela.

Bien que je n'aie pas encore travaillé directement sur les K8, je pourrais imaginer contribuer à cette idée/fonctionnalité si possible/voulu.

Pouvez-vous l'envoyer par e-mail à [email protected] ? Nous pouvons faire un suivi là-bas.

@apelisse Je ne suis pas autorisé à poster des messages sur ledit groupe ([email protected])

Désolé, vous devrez peut-être d'abord rejoindre le groupe : https://groups.google.com/forum/#!forum/kubernetes -wg-apply

Bouton bleu, "Rejoindre le groupe pour publier" (en haut à gauche)

@apelisse @kubernetes/sig-api-machinery-feature-requests @kubernetes/sig-cli-feature-requests --

Cette fonctionnalité a été supprimée du jalon précédent, nous aimerions donc vérifier et voir s'il existe des plans pour cela dans Kubernetes 1.12.

Si tel est le cas, veuillez vous assurer que ce problème est à jour avec TOUTES les informations suivantes :

• Description de la fonctionnalité en une ligne (peut être utilisée comme note de version) :
• Contact principal (cessionnaire) :
• SIG responsables :
• Lien de proposition de conception (dépôt communautaire) :
• Lien vers e2e et/ou tests unitaires :
• Réviseur(s) - (pour LGTM) recommande d'avoir 2+ réviseurs (au moins un du fichier PROPRIÉTAIRES de la zone de code) acceptés pour réviser. Les évaluateurs de plusieurs entreprises ont préféré :
• Approbateur (probablement du SIG/de la zone à laquelle appartient la fonctionnalité) :
• Cible de fonctionnalité (quelle cible correspond à quel jalon) :
  
  
  
  • Cible de la version alpha (xy)
  
  
  • Cible de la version bêta (xy)
  
  
  • Cible de version stable (xy)
  
  

Définissez les éléments suivants :

• La description
• Cessionnaire(s)
• Étiquettes:
  
  
  
  • stade/{alpha,beta,stable}
  
  
  • sig/*
  
  
  • genre/caractéristique
  
  

Veuillez noter que le gel des fonctionnalités est le 31 juillet, après quoi tout problème de fonctionnalité incomplet nécessitera une demande d'exception pour être accepté dans le jalon.

De plus, veuillez tenir compte des délais pertinents suivants :

• Date limite des documents (espace réservé PR ouvert) : 21/08
• Gel du cas de test : 28/08

Veuillez vous assurer que tous les PR pour les fonctionnalités incluent également des notes de version pertinentes.

Bonne expédition !

/cc @justaugustus @kacole2 @robertsandoval @rajendar38

Je pense que tout est là @justaugustus ! Merci

Merci pour la mise à jour, @apelisse !

Salut! @apelisse Je suis le wrangler pour les Docs cette version. Y a-t-il une chance que je vous demande d'ouvrir un docs PR contre la branche release-1.12 en tant qu'espace réservé ? Cela nous donne plus de confiance dans la livraison des fonctionnalités de cette version et me donne quelque chose avec quoi travailler lorsque nous commençons à faire des révisions/modifications. Merci! Si cette fonctionnalité ne nécessite pas de documents, pourriez-vous mettre à jour la feuille de calcul de suivi des fonctionnalités pour en tenir compte ?

@zparnold Changement du jalon de 1.12 à 1.13 :-). Vous pouvez oublier cela pour le moment, merci.

Ce sera alpha, ce serait bien de documenter. Jenny a dit qu'elle essaierait de préparer quelque chose. [EDIT : mauvais problème, ignorer]

Le Mar 21 Août 2018 à 12:44 Antoine Pelisse [email protected]
a écrit:

@zparnold https://github.com/zparnold Changement du jalon de 1.12
à 1.13 :-). Vous pouvez oublier cela pour le moment, merci.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/kubernetes/features/issues/555#issuecomment-414797736 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAnglgxXgV0DuPpOq4P4UZZjMY8Fcx6Lks5uTGMDgaJpZM4TKb_j
.

Désolé, j'ai vu cela dans mon e-mail et je l'ai confondu avec le problème de la fonctionnalité de simulation. Oui, l'application côté serveur ne se lance pas dans la 1.12.

@lavalamp @apelisse Je vais faire les modifications dans la feuille de calcul. merci de nous avoir fait connaitre ! cc @justaugustus

Y a-t-il des problèmes ou des relations publiques que nous pourrions suivre pour mieux comprendre le travail en cours pour obtenir quelle fonctionnalité dans 1.13 dans le cadre de cela ?

@spiffxp Nous n'avons pas de problème pour le moment. nous avons un groupe de travail pour cela, et nous gardons une trace des tâches dans une feuille de calcul. Je vais essayer de créer un problème pour suivre les progrès et augmenter la visibilité, merci.

N'est-ce pas le problème ?

Pour les relations publiques, regardez ici : https://github.com/kubernetes-sigs/structured-merge-diff/pulls

Regardez également dans le dépôt principal, recherchez "branche de fonctionnalité" dans le nom (par exemple, Jenny a un changement d'API en ce moment).

Nous avons des notes de notre réunion bimensuelle ici : https://docs.google.com/document/d/1j_UqnJRvB7AywfZauHybVVNCOoDDA1AGWGxzPGE08ko/edit# (rejoindre la liste de diffusion wg-apply si vous voulez lire)

Nous avons également des enregistrements de réunions bien que nous soyons peut-être derrière leur publication.

@lavalamp @apelisse quel est le niveau de confiance de cette fonctionnalité pour passer à Alpha en 1.13 ? Ces 3 PR sont-ils les seuls en attente ?

@lavalamp à droite, mon Q était plutôt de savoir si l'un des éléments de la branche de fonctionnalité allait atterrir dans le maître, sinon il ne semble pas que cela devrait être sur notre radar; les notes wg-apply sont assez spartiates à cet égard

Il y a le document de feuille de route mentionné en avril, mais je ne sais pas si c'est toujours valable, et si oui, dans quelle phase nous sommes actuellement par rapport à viser

Sur la base de votre dernier commentaire dans les notes de réunion sig-api-machinery, j'essaie de déterminer quels éléments de travail nous devrions surveiller "pas sûr que nous atteindrons l'alpha à temps" et si "alpha" implique l'atterrissage de la fonctionnalité branche à maîtriser

@spiffxp Oui, passer en alpha revient à fusionner la branche de fonctionnalité dans master.

@AishSundar Non, il reste de nombreux PR à écrire. Regardez les PR fermés dans ce repo pour une estimation de la vitesse récente. De plus, nous aurons besoin de plus de PR pour la branche de fonctionnalité dans le référentiel principal.

Pouvez-vous m'aider à comprendre pourquoi ce niveau de détail est nécessaire/utile ? Il nous reste encore 3 semaines avant que quoi que ce soit ne gèle ou ne fonde, non ? Si la branche n'est pas fusionnée d'ici là, nous devrons repousser cela.

@lavalamp puisqu'il s'agit d'un cycle de publication court, l'équipe de publication essaie d'évaluer, dès le début, la quantité de travail en attente pour chaque fonctionnalité prévue et les risques de dérapages possibles. Cela nous aidera à mieux les suivre tout au long du cycle

Il reste certainement du travail pour obtenir cela en 1.13 et les chances que cela glisse ne sont pas négligeables. Cependant, nous voulons toujours tenter notre chance et espérons que les quelques semaines restantes seront suffisantes pour arriver à la qualité alpha.

Je suis heureux de vous aider à suivre cet article de toutes les manières possibles et je peux revenir vers vous régulièrement pour vous donner un statut. J'espère que ça aide, merci.

@apelisse pour l'instant si vous pouvez simplement nous indiquer la liste des PR ouverts et des problèmes ouverts (pour les PR non ouverts) ce sera génial. nous toucherons la base début novembre pour voir où nous en sommes. Merci.

@kacole2 comme pour

Nous ne suivons pas notre travail via des problèmes spécifiques qui nécessitent la rédaction de PR spécifiques, ce qui serait assez lourd pour nous. Nous utilisons cette feuille de calcul : https://docs.google.com/spreadsheets/d/1ZHTDyiQssYBzs7DQWQd70bNQybeyS0m-S1aIS_zo-78/edit?pli=1#gid =0

(vous êtes probablement déjà dans un groupe de messagerie qui a accès)

Dans une discussion hors ligne avec @spiffxp, il semble que vous

• En termes de risque pour la stabilité, nous ne le fusionnerons pas s'il ne rencontre pas la barre avant la fermeture de la fenêtre, il y a donc très peu de risque. Tous nos changements sont dans la branche de fonctionnalité ou d'autres dépôts, donc ce n'est pas comme si nous laissions master à moitié cassé si nous ne le faisons pas.
• En termes de risque de ne pas franchir la ligne d'arrivée à temps, nous sommes bien conscients que le temps presse et il y a de fortes chances que nous ne fassions pas la sortie.

Salut @lavalamp et @apelisse , je suis le docs wrangler pour la version 1.13. Pourriez-vous s'il vous plaît ouvrir un espace réservé PR pour les documents de cette amélioration contre la branche dev-1.13 de k/website et m'envoyer un lien ? Si vous avez déjà ouvert un docs PR, ou si cela ne nécessite pas de docs dans k/website, faites-le moi savoir.

La date limite pour les PR d'espace réservé pour la version 1.13 est le 8 novembre. Il est donc important de faire un PR docs dès que possible.

Si vous avez des questions à ce sujet, je suis heureux de vous aider. Vous pouvez également m'envoyer un message sur slack (je suis tfogo là aussi).

Merci!

@tfogo Merci pour votre aide ! Je l'ai créé ici : https://github.com/kubernetes/website/pull/10812

Salut @lavalamp et @apelisse - Je suis Enhancements Shadow pour 1.13. En lisant ce fil de discussion et en considérant la méthode de suivi de cette fonctionnalité, pourriez-vous s'il vous plaît mettre à jour l'équipe de publication avec la probabilité que cette amélioration fasse la version 1.13 ?

Le code slush commence le 9/11 et le gel du code est le 15/11.

Merci!

Salut @guineveresaenger , il y a encore des chances que nous manquions la sortie, mais nous faisons tout notre possible pour avoir une fonctionnalité alpha de haute qualité en 1.13 !

@apelisse pouvons-nous s'il vous plaît chronométrer la décision Go/NoGo au mercredi (11/14) la semaine prochaine. À ce stade du cycle, nous nous attendons à ce que toutes les améliorations de la 1.13 aient tous les PR de code et de test fusionnés ou très proches de la fusion. Je comprends que cette fonctionnalité est en cours de développement dans une branche de fonctionnalité. Mais avec le gel du code vendredi prochain (11/16), nous devons le fusionner dans master au moins mercredi matin pour obtenir des signaux CI stables pendant quelques jours de Master. Si ce n'est pas possible, nous devrons le pousser à 1,14. Merci

@kacole2

Nous avons trouvé quelques bugs à la dernière seconde, nous allons donc fusionner cela comme la première chose pour la 1.14 lorsque master s'ouvrira.

Merci pour la mise à jour @lavalamp.

@kacole2 @tfogo @marpaia @kbarnard10 comme pour

@apelisse @lavalamp Bonjour - Je suis le responsable de l'amélioration pour la version 1.14 et je vérifie ce problème pour voir quel travail (le cas échéant) est prévu pour la version 1.14. Le gel des améliorations est le 29 janvier.

Bonjour @claurence , nous prévoyons de sortir cette fonctionnalité en alpha ce cycle ! Je viens de mettre à jour la description pour refléter le nouveau jalon. Autre chose que je dois mettre à jour ?

@apelisse sonne bien ! Je vais l'ajouter à notre feuille de suivi 1.14.

À quoi ressemblerait la requête API effectuée par le client après cela ? Je suppose que cela enverrait la définition complète de la ressource locale, mais s'agirait-il toujours d'une demande PATCH ? Ou un PUT ?

Je suis vraiment enthousiasmé par cela, cela enlève beaucoup de complexité aux clients personnalisés.

Oui, il recevra l'objet local sur le verbe PATCH, avec un type de contenu spécifique.

Btw le lien vers la proposition de conception est rompu

Corrigé, merci, bonne prise.

Cela semble être le dernier lien https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/0006-apply.md

Btw, tous les documents de conception Google qui y sont liés ne sont pas visibles publiquement.

Salut Felix, ce document a besoin d'un nettoyage massif, je m'en occuperai juste après le gel du code (ou avant si nous avons du temps supplémentaire). Merci!

Je suis de retour, je peux peut-être mettre à jour le KEP.

/assigner lampe laval

Salut @apelisse ! Je suis l'une des ombres de la version v1.14 de la version docs.

Cette amélioration nécessite-t-elle de nouveaux documents (ou modifications) ?

Juste un rappel amical, nous recherchons un PR contre k/website (branche dev-1.14) dû d'ici le vendredi 1er mars. Ce serait formidable si c'était le début de la documentation complète, mais même un PR de substitution est acceptable. Faites moi savoir si vous avez des questions!

Merci pour le rappel @cody-clark, nous avons absolument besoin de documentation !

Parfait! Je vais le marquer dans la feuille de suivi. Merci pour la réponse rapide, @apelisse !

@apelisse examinant le KEP pour cette amélioration Je ne vois aucun plan de test - quelqu'un peut-il aider les relations publiques à tester les plans de cette amélioration ? Ces informations sont utiles pour connaître la préparation de cette fonctionnalité pour la version et sont particulièrement utiles pour CI Signal.

Si nous n'avons pas de plans de test, cette amélioration risque d'être incluse dans la version 1.14

@claurence J'ai mis à jour la description, dites-moi si vous vous attendiez à quelque chose de différent ! Merci!

Bonjour, ombre d'amélioration 1.14 ici. Code Freeze est le 7 mars et tous les PR doivent être fusionnés d'ici là à votre problème pour faire la version 1.14. Quels K/K PR ouverts avez-vous encore besoin de fusionner ? Merci

Salut @lledru , nous avons quelques PR en vol qui devraient être fusionnés dans la semaine environ. Aucun d'entre eux n'est vraiment bloquant pour la sortie et nous pourrions absolument sortir dans l'état actuel !

bonjour @apelisse ,
Pouvez-vous s'il vous plaît soumettre un PR contre le KEP avec le plan de test ?
Ces informations sont utiles pour connaître la préparation de cette fonctionnalité pour la version et sont particulièrement utiles pour CI Signal.
Si nous n'avons pas de plans de test, cette amélioration risque d'être incluse dans la version 1.14
Merci beaucoup.

Hey @apelisse , la date limite des docs était le vendredi 1er mars dernier (pour ouvrir un espace réservé PR). Avez-vous des PR en vol pour les documents dev-1.14 ? S'agit-il toujours de cibler 1,14 ?

Nous avons créé l'espace réservé à la documentation : https://github.com/kubernetes/website/pull/12898. Je ne suis pas sûr que ce soit correct mais au moins ça existe :-)

@lledru Merci pour le rappel, @jennybuckley travaille sur la mise à jour du KEP.

@lledru Voilà : #878

@apelisse des travaux prévus ici pour 1h15 ou rester à Alpha ?

Oui, j'espère que ça va en bêta 1.15

Merci @apelisse. Lorsque le moment est venu, déposez les k/k PR associés aux critères d'obtention du diplôme bêta qui sont indiqués dans le KEP

/jalon v1.15
/étape bêta

Salut @apelisse. Je peux voir que vous aviez un PR d'espace réservé pour 1.14 mais nous avons besoin d'un PR contre k/website (branche dev-1.15) dû d'ici le jeudi 30 mai. Ce serait formidable si c'était le début de la documentation complète, mais même un PR d'espace réservé est acceptable. Faites moi savoir si vous avez des questions!

@simplytunde @apelisse Je m'en occupe , car j'ai encore des trucs à mettre dans la doc pour ma tâche "effacer les champs gérés".

Merci @kwiesmueller, faites-moi savoir si je peux vous aider !

Terminé : https://github.com/kubernetes/website/pull/14300
Nous pouvons l'utiliser comme espace réservé PR et l'utiliser pour d'autres choses que nous pourrions vouloir ajouter pour 1,15

Je suis au-delà de la sortie pour que cela atterrisse (le mois prochain?).
Existe-t-il déjà un moyen de l'essayer (dans Minikube) ?

Salut @apelisse @kwiesmueller . Code Freeze est le jeudi 30 mai 2019 @ EOD PST . Toutes les améliorations apportées à la version doivent être complètes, y compris les tests , et les documents PR doivent être ouverts.

Veuillez répertorier tous les PR k/k actuels afin qu'ils puissent être suivis jusqu'au gel. Si les PR ne sont pas fusionnés par gel, cette fonctionnalité glissera pour le cycle de version 1.15. Seuls les problèmes de blocage de version et les PR seront autorisés dans le jalon.

Si vous savez que cela va glisser, veuillez répondre et nous le faire savoir. Merci!

Je ne vois vraiment pas comment cela se ferait par le gel du code. Je pense que vous pouvez le marquer pour 1.16 :-/

??

@felixfbecker Vous pouvez utiliser n'importe quel kubernetes 1.14 ou version ultérieure avec la fonctionnalité ServerSideApply activée pour l'essayer.

Dans minikube, ce serait quelque chose comme ... minikube start --feature-gates=ServerSideApply=true si j'ai bien compris !

Désolé, nous l'avons manqué, nous avons un problème d'évolutivité que nous devons d'abord résoudre.

/jalon clair

Il permet tout ce qui a été publié dans la 1.14 plus ce que nous avons fusionné dans le master depuis lors.
J'aimerais en savoir plus sur les fonctionnalités que vous souhaitez, ce que vous construisez avec et ce que vous n'aimez pas à propos de cette fonctionnalité ! N'hésitez pas à me faire un ping sur slack (apelisse@)

Ce dernier commentaire m'était-il destiné ?

@felixfbecker et quelqu'un d'autre qui a supprimé son message ;-)

@felixfbecker C'était moi. Désolé d'avoir supprimé mon message car j'ai trouvé la réponse après être tombé sur ce fil 🙂

Salut @apelisse , je suis la 1.16 Enhancement Shadow. Cette fonctionnalité va-t-elle passer les étapes alpha/bêta/stable dans la version 1.16 ? Veuillez me le faire savoir afin qu'il puisse être ajouté à la feuille de calcul de suivi 1.16 et que je puisse mettre à jour les balises de jalon et d'étape

Une fois le codage commencé ou s'il l'a déjà fait, veuillez répertorier tous les PR k/k pertinents dans ce numéro afin qu'ils puissent être suivis correctement.

Les dates clés sont Enhancement Freeze 7/30 et Code Freeze 8/29.

Merci.

Oui, nous prévoyons de publier cette fonctionnalité en version bêta.

/remove-label suivi/non
/étiquette suivie/oui
/jalon v1.16

Hé, @apelisse @lavalamp, je suis le responsable de la publication des documents v1.16.

Cette amélioration (ou le travail prévu pour la v1.16) nécessite-t-elle de nouveaux documents (ou modifications) ?

Juste un rappel amical, nous recherchons un PR contre k/website (branche dev-1.16) dû d'ici le vendredi 23 août. Ce serait formidable si c'était le début de la documentation complète, mais même un PR d'espace réservé est acceptable. Faites moi savoir si vous avez des questions!

Une version limitée de l'application côté serveur est-elle disponible dans la v 13 (c'est là que se trouve mon cluster) ? Certains échanges ci-dessus semblaient impliquer que cela pourrait être le cas. Mon cas d'utilisation concerne la création de pods/deplyments/services dans la boucle de réconciliation d'un opérateur. L'utilisation de l'api/core<>Pod, etc. est fastidieuse et sujette aux erreurs et pouvoir utiliser une API de serveur pour appliquer yaml serait beaucoup plus propre pour moi. Merci pour toute suggestion..

@champak , vous pouvez l'essayer en

Le gel du code

@kacole2 Oui, nous en avons :

• https://github.com/kubernetes/kubernetes/pull/81754
• https://github.com/kubernetes/kubernetes/pull/78738
• https://github.com/kubernetes/kubernetes/pull/81816

Nous avons également besoin d'un autre PR trivial pour activer la fonctionnalité.

Quels sont les critères pour qu'un élément entre en version bêta ? J'ai essayé l'application côté serveur, mais cela ne semble pas vraiment utilisable en remplacement de l'application côté client que kubectl fait : https://github.com/kubernetes/kubernetes/issues/80916

@felixfbecker Désolé d'avoir glissé entre les mailles du filet ! Merci de l'avoir essayé. Je suis d'accord que quelque chose ne va pas et nous devons le corriger pour la version bêta.

Mais en général, il semble que vous vous attendiez à ce qu'il s'agisse d'une extension du côté client, en fait, cela ressemble plus à un système parallèle - utilisez l'un ou l'autre. Le mécanisme général de transition consiste à suivre les conseils de Jenny dans votre bogue. Nous avons fait cela pour offrir une expérience très sûre - vous pouvez choisir exactement le comportement que vous souhaitez.

Nous fournirons une expérience de transition transparente lorsque nous désapprouvons l'application côté client.

Salut @apelisse, il semble que https://github.com/kubernetes/kubernetes/pull/81816 n'ait pas fusionné avant le gel du code et qu'il ne se trouve pas dans le pool de fusion de marée . Cette fonctionnalité va être supprimée de la v1.16. Si vous souhaitez toujours que cela fasse partie de la version 1.16, veuillez déposer une exception

Les prés obligatoires fusionnés, c'est maintenant la bêta.

Le vendredi 30 août 2019, 04:58 Kendrick Coleman [email protected]
a écrit:

Salut @apelisse https://github.com/apelisse on dirait que
kubernetes/kubernetes#81816
https://github.com/kubernetes/kubernetes/pull/81816 n'a pas fusionné avant
le code est gelé et il n'est pas dans le pool de fusion de marée https://prow.k8s.io/tide .
Cette fonctionnalité va être supprimée de la v1.16. Si vous souhaitez toujours
si cela fait partie de la version 1.16, veuillez déposer une exception
https://github.com/kubernetes/sig-release/blob/master/releases/EXCEPTIONS.md

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/kubernetes/enhancements/issues/555?email_source=notifications&email_token=AAE6BFRCLZC47AWM6AQMJE3QHEDOPA5CNFSM4EZJX7R2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63T5LNMVXWWEA2JKDN0
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAE6BFRKMWNNIOAIINJGBELQHEDOPANCNFSM4EZJX7RQ
.

@lavalamp voudriez-vous clarifier? dites-vous que https://github.com/kubernetes/kubernetes/pull/81816 n'était pas obligatoire pour que cette fonctionnalité soit en version bêta ?

@guineveresaenger Il n'est pas obligatoire que cette fonctionnalité soit en version bêta. Ce PR est destiné à répondre aux problèmes d'évolutivité et peut être fusionné dans une future version, il ne modifie pas l'API et n'améliore les performances que dans les clusters où de nombreuses choses sont gérées par cette nouvelle fonctionnalité

@guineveresanger Oui, c'est opt-in sur une base par objet dans la bêta 1, donc ce n'est pas nécessaire car il n'y a plus d'impact global sur les performances.

merci de me l'avoir signalé @lavalamp

Salut @lavalamp @apelisse -- 1.17 Les améliorations mènent ici. Je voulais vérifier et voir si vous pensez que cette amélioration passera à alpha/beta/stable en 1.17 ?

Le calendrier de diffusion actuel est le suivant :

• Lundi 23 septembre - Début du cycle de publication
• Mardi 15 octobre, EOD PST - Gel des améliorations
• Jeudi 14 novembre EOD PST - Gel du code
• Mardi 19 novembre - Les documents doivent être complétés et révisés
• Lundi 9 décembre - Sortie de Kubernetes 1.17.0

Si vous le faites, veuillez énumérer tous les PR k/k pertinents dans ce numéro afin qu'ils puissent être suivis correctement. ??

Merci!

/jalon clair

Salut @mrbobbytables , alors que nous prévoyons de grandes améliorations de cette fonctionnalité pour la prochaine version, mais nous ne prévoyons pas encore de passer à GA. Merci.

@apelisse a noté -- merci pour la réponse rapide ! ??

Les problèmes deviennent obsolètes après 90 jours d'inactivité.
Marquez le problème comme récent avec /remove-lifecycle stale .
Les problèmes périmés pourrissent après 30 jours supplémentaires d'inactivité et finissent par se fermer.

Si ce problème peut être résolu en toute sécurité maintenant, veuillez le faire avec /close .

Envoyez vos commentaires à sig-testing, kubernetes/test-infra et/ou fejta .
/cycle de vie périmé

/supprimer le cycle de vie périmé

Nous travaillons sur une version "bêta 2" de cette fonctionnalité pour la 1.18, nous ne savons pas comment/si nous devons suivre cela, mais nous sommes heureux de suivre un processus.

Salut @apelisse , merci de l'avoir souligné ! Nous le suivrons comme un changement au sein de la version bêta dans la feuille d'améliorations. Y aura-t-il des changements au KEP associés à cela ? Ou cela sera-t-il simplement lié à des changements de code ? Si vous pouviez lier tous les PRs k/k associés à cela afin que nous puissions le suivre, ce serait formidable.

Si vous apportez des modifications KEP, Enhancements Freeze sera le 28 janvier
Code Freeze aura lieu le 5 mars .

Merci!

/jalon v1.18

Nous pourrions fusionner https://github.com/kubernetes/enhancements/pull/1442 jusqu'au 28.
Peut-être même https://github.com/kubernetes/enhancements/pull/923.

Et je viens de voir que https://github.com/kubernetes/enhancements/pull/1123 a fusionné, donc la mise en œuvre pourrait également passer à la version 1.18.

Bonjour, @apelisse - Je suis l'ombre de Docs dans l'équipe de version 1.18.

Ce travail d'amélioration prévu pour la version 1.18 nécessite-t-il de nouveaux documents ou des modifications des documents existants ?

Sinon, pouvez-vous s'il vous plaît mettre à jour la feuille de suivi des améliorations 1.18 (ou faites-le moi savoir et je le ferai)

Si des mises à jour de la documentation sont nécessaires, rappelez que les PR d'espace réservé contre k/website (branche dev-1.18) sont dus avant le vendredi 28 février.

Faites moi savoir si vous avez des questions!

Nous travaillons actuellement sur la doc, merci pour le rappel !

Salut @apelisse @kwiesmueller ,

Juste un rappel amical que le gel du code pour la 1.18 est le 05 mars 2020 .

Alors que nous suivons le gel du code, veuillez répertorier / créer un lien vers tous les PR sur lesquels vous travaillez pour obtenir cette amélioration !

Merci pour le rappel!

Salut @apelisse @kwiesmueller ,

Retour en arrière alors que nous nous rapprochons du gel du code. Veuillez énumérer tous les PR k/k sur lesquels vous travaillez afin que nous puissions mieux suivre ce problème .

Je pense que nous n'y arriverons pas avec les trucs sur lesquels je travaille.
@apelisse pourrait en avoir et probablement @julianvmodesto avec dryrun et diff?

J'ai créé l'espace réservé doc PR : https://github.com/kubernetes/website/pull/19286

Hé @apelisse rappel amical que le gel du code pour la 1.18 est le 5 mars . C'est dans quelques jours. Merci d'avoir ouvert le PR docs ci-dessus... pourriez-vous créer un lien vers des PR K/K pertinents pour cela afin que nous puissions mieux suivre la progression de l'amélioration à mesure que nous nous rapprochons du gel du code ?

Merci beaucoup!

Hé @apelisse , malheureusement, https://github.com/kubernetes/kubernetes/pull/88875 n'a pas fusionné avant le gel du code (on dirait qu'il doit encore être approuvé). À ce stade, vous devrez déposer une demande d'exception pour celui-ci.

/jalon clair

Qu'est-ce qui se passe avec ça?

Nous sommes encore en version bêta, nous avons travaillé sur de nouvelles améliorations mais nous ne sommes pas encore prêts pour la disponibilité générale. Nous publierons un article de blog dans quelques jours à ce sujet !

Salut @apelisse -- Améliorations 1.19 Lead ici, je voulais vérifier si vous pensez que cette amélioration passerait en 1.19 ?

Le calendrier de diffusion actuel est le suivant :

• Lundi 13 avril : Semaine 1 - Début du cycle de publication
• Mardi 19 mai : Semaine 6 - Gel des améliorations
• Jeudi 25 juin : Semaine 11 - Gel du code
• Jeudi 9 juillet : Semaine 14 - Les documents doivent être complétés et révisés
• Mardi 4 août : Semaine 17 - Sortie de Kubernetes v1.19.0

Bonjour, nous ne prévoyons pas de promouvoir cette fonctionnalité ce cycle, merci !

Merci @apelisse pour les mises à jour. Je mettrai à jour la feuille de suivi en conséquence. :+1:

Les problèmes deviennent obsolètes après 90 jours d'inactivité.
Marquez le problème comme récent avec /remove-lifecycle stale .
Les problèmes périmés pourrissent après 30 jours supplémentaires d'inactivité et finissent par se fermer.

Si ce problème peut être résolu en toute sécurité maintenant, veuillez le faire avec /close .

Envoyez vos commentaires à sig-testing, kubernetes/test-infra et/ou fejta .
/cycle de vie périmé

/supprimer le cycle de vie périmé

Salut @apelisse

Les améliorations mènent ici. Avez-vous l'intention d'obtenir ce diplôme en 1.20 ?

Merci,
Kirsten

Pas vraiment, nous prévoyons de continuer à améliorer la fonctionnalité existante, mais il n'y a pas de remise des diplômes prévue pour la 1.20, merci !