/ assign @apelisse

Parece que ainda precisamos de alguns documentos para preparar esse recurso para o lançamento @apelisse
Posso obter ajuda com isso? Se houver algo que eu possa fazer para ajudar, por favor me avise

Queremos, no mínimo, ter um RP de espaço reservado no repositório kubernetes / site. O processo é bastante simples: checkout release-1.11 branch, faça um placeholder commit, envie-o para seu fork e aumente um PR entre ele e o branch release-1.11 , com o status /hold .

MUITO OBRIGADO!!!!!

@apelisse Percebi a mudança de marco. Você está planejando retirar isso da versão 1.11?

Sim, não em 1.11. Estou atualizando o corpo.

Obrigado @apelisse!

Não temos certeza se é o lugar certo para comentar sobre isso, mas estamos trabalhando em nosso próprio tipo de "aplicação do lado do servidor" criando https://github.com/seibert-media/dimios
Embora este seja apenas um projeto de folga no qual esperamos construir nossa futura interação com o Kubernetes, nós dois tropeçamos em problemas com todo o processo de aplicação (discutido na folga com algumas pessoas), mas também pensamos em como abordar isso da melhor forma.

Embora eu ainda não tenha trabalhado diretamente nos K8s, posso imaginar contribuir para essa ideia / recurso se possível / desejado.

Você pode enviar isso como um e-mail para [email protected]? Podemos acompanhar lá.

@apelisse Não tenho permissão para postar mensagens no referido grupo ([email protected])

Talvez você precise ingressar no grupo primeiro: https://groups.google.com/forum/#!forum/kubernetes -wg-apply

Botão azul, "Entrar no grupo para postar" (canto superior esquerdo)

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

Esse recurso foi removido do marco anterior, portanto, gostaríamos de verificar e ver se há planos para isso no Kubernetes 1.12.

Em caso afirmativo, certifique-se de que este problema está atualizado com TODAS as seguintes informações:

• Descrição do recurso de uma linha (pode ser usada como uma nota de versão):
• Contato principal (cessionário):
• SIGs responsáveis:
• Link de proposta de design (repositório da comunidade):
• Link para e2e e / ou testes de unidade:
• Revisor (es) - (para LGTM) recomendam que mais de 2 revisores (pelo menos um do arquivo OWNERS da área de código) concordem em revisar. Revisores de várias empresas preferidos:
• Aprovador (provavelmente do SIG / área à qual o recurso pertence):
• Meta de recurso (qual meta é igual a qual marco):
  
  
  
  • Alvo de liberação alfa (xy)
  
  
  • Meta de lançamento beta (xy)
  
  
  • Alvo de liberação estável (xy)
  
  

Defina o seguinte:

• Descrição
• Cessionário (s)
• Rótulos:
  
  
  
  • estágio / {alfa, beta, estável}
  
  
  • sig / *
  
  
  • tipo / recurso
  
  

Observe que o congelamento de recursos ocorre em 31 de julho, após o qual qualquer problema de recurso incompleto exigirá que uma solicitação de exceção seja aceita no marco.

Além disso, esteja ciente dos seguintes prazos relevantes:

• Prazo do Docs (abrir espaço reservado para PRs): 21/08
• Congelamento do caso de teste: 28/08

Certifique-se de que todos os PRs para recursos também tenham notas de versão relevantes incluídas.

Frete feliz!

/ cc @justaugustus @ kacole2 @robertsandoval @ rajendar38

Acho que está tudo aí @justaugustus! Obrigado

Obrigado pela atualização, @apelisse!

Ei! @apelisse Eu sou o

@zparnold Mudou o marco de 1.12 para 1.13 :-). Você pode esquecer isso por enquanto, obrigado.

Vai ser alfa, seria bom documentar. Jenny disse que tentaria montar algo. [EDITAR: problema errado, ignorar]

Na terça, 21 de agosto de 2018 às 12h44, Antoine Pelisse [email protected]
escreveu:

@zparnold https://github.com/zparnold Alterou o marco de 1.12
a 1.13 :-). Você pode esquecer isso por enquanto, obrigado.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/kubernetes/features/issues/555#issuecomment-414797736 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAnglgxXgV0DuPpOq4P4UZZjMY8Fcx6Lks5uTGMDgaJpZM4TKb_j
.

Desculpe, vi isso em meu e-mail e confundi com o problema do recurso de simulação. Sim, a aplicação do lado do servidor não está iniciando em 1.12.

@lavalamp @apelisse Farei as alterações na planilha. obrigado por nos alertar! cc @justaugustus

Há algum problema ou RP que possamos rastrear para entender melhor o trabalho que está sendo feito para definir qual funcionalidade do 1.13 faz parte disso?

@spiffxp Não temos nenhum problema agora. temos um grupo de trabalho para isso e acompanhamos as tarefas em uma planilha. Vou tentar criar um problema para rastrear o progresso e aumentar a visibilidade, obrigado.

Não é esse o problema?

Para PRs, veja aqui: https://github.com/kubernetes-sigs/structured-merge-diff/pulls

Também procure no repositório principal, procure por "branch de recurso" no nome (por exemplo, Jenny tem uma alteração de API no momento).

Temos notas de nossa reunião quinzenal aqui: https://docs.google.com/document/d/1j_UqnJRvB7AywfZauHybVVNCOoDDA1AGWGxzPGE08ko/edit# (junte-se à lista de e-mails wg-apply se quiser ler)

Também temos gravações de reuniões, embora possamos estar por trás de publicá-las.

@lavalamp @apelisse qual é o nível de confiança desse recurso para chegar ao Alpha no 1.13? Esses 3 PRs são os únicos pendentes?

@lavalamp certo, meu Q era mais se alguma das coisas do branch de recursos iria pousar no master, caso contrário, não parece que isso deveria estar em nosso radar; as notas do wg-apply são bastante espartanas a esse respeito

Há o documento do

Com base em seu último comentário nas notas da reunião da

@spiffxp Sim, torná-lo alfa é o mesmo que mesclar a ramificação do recurso de volta ao mestre.

@AishSundar Não, ainda há muitos PRs a serem escritos. Veja os PRs fechados nesse repo para obter uma estimativa da velocidade recente. Além disso, precisaremos de mais PRs para o branch de recursos no repo principal.

Vocês dois podem me ajudar a entender por que esse nível de detalhe é necessário / útil? Ainda temos 3 semanas antes que qualquer coisa congele ou derrame, não? Se o branch não for mesclado até então, teremos que empurrar isso.

@lavalamp como este é um ciclo de lançamento curto, a equipe de lançamento está tentando avaliar, desde o início, a quantidade de trabalho pendente para cada recurso planejado e as chances de possíveis erros. Isso nos ajudará a rastreá-los melhor ao longo do ciclo

Definitivamente, ainda há algum trabalho a fazer para conseguir isso no 1.13 e as chances de que ele escorregue não são desprezíveis. No entanto, ainda queremos aproveitar a nossa chance e esperamos que as poucas semanas restantes sejam o suficiente para chegar à qualidade alfa.

Fico feliz em ajudá-lo a rastrear esse item de qualquer maneira possível e posso retornar a você regularmente para fornecer um status. Espero que ajude, obrigado.

@apelisse por enquanto, se você puder nos indicar a lista de PRs abertos e questões em aberto (para PRs não abertos), isso será ótimo. entraremos em contato no início de novembro para ver onde estamos. Obrigado.

@ kacole2 as FYI

Não estamos monitorando nosso trabalho por meio de questões específicas que precisam de PRs específicos escritos, o que seria bastante pesado para nós. Estamos usando esta planilha: https://docs.google.com/spreadsheets/d/1ZHTDyiQssYBzs7DQWQd70bNQybeyS0m-S1aIS_zo-78/edit?pli=1#gid = 0

(provavelmente você já está em algum grupo de e-mail que tem acesso)

Em um bate-papo offline com @spiffxp , parece que você está realmente tentando avaliar o risco; Acho que as perguntas acima não fazem sentido para esse esforço específico, visto que isso está acontecendo em um branch de recursos, que é provavelmente o motivo pelo qual estamos conversando um sobre o outro.

• Em termos de risco para a estabilidade, não iremos mesclá-lo se não encontrar a barra antes de a janela fechar, portanto, há muito pouco risco. Todas as nossas alterações estão no branch de recursos ou em outros repositórios, portanto, não deixaríamos o master meio quebrado se não o fizéssemos.
• Em termos de risco de não chegarmos na linha de chegada a tempo, sabemos que o tempo é curto e há uma boa chance de não conseguirmos o lançamento.

Olá @lavalamp e @apelisse , sou o organizador de documentos para a versão 1.13. Você poderia abrir um PR para os documentos deste aprimoramento em relação ao ramo dev-1.13 do k / website e enviar-me um link? Se você já tem um PR do docs aberto, ou se não requer docs no k / website, por favor me avise.

O prazo para os PRs de substituição para a versão 1.13 é 8 de novembro. Portanto, é importante fazer um PR de documentos o mais rápido possível.

Se você tiver alguma dúvida sobre isso, será um prazer ajudar. Você também pode me enviar uma mensagem no slack (também estou lá).

Obrigado!

@tfogo Obrigado pela sua ajuda! Eu o criei aqui: https://github.com/kubernetes/website/pull/10812

Olá, @lavalamp e @apelisse - Sou o Enhancements Shadow para 1.13. Lendo este tópico e considerando o método de rastreamento desse recurso, você poderia, por favor, atualizar a equipe de lançamento com a probabilidade desse aprimoramento chegar ao lançamento 1.13?

O código secreto começa em 9/11 e o congelamento de código é em 15/11.

Obrigado!

Olá @guineveresaenger , ainda há chances de perdermos o lançamento, mas estamos fazendo todo o possível para ter um recurso alfa de alta qualidade no 1.13!

@apelisse, podemos

@ kacole2

Encontramos alguns bugs no último segundo, então vamos mesclar isso como a primeira coisa para 1.14 quando o master for aberto.

Obrigado pela atualização @lavalamp.

@ kacole2 @tfogo @marpaia @ kbarnard10 como FYI

@apelisse @lavalamp Olá - sou o líder do aprimoramento para 1.14 e estou verificando este problema para ver que trabalho (se houver) está sendo planejado para o lançamento 1.14. O congelamento de aprimoramentos ocorre em 29 de janeiro.

Olá @claurence , estamos planejando lançar este recurso alfa neste ciclo! Acabei de atualizar a descrição para refletir o novo marco. Mais alguma coisa que eu preciso atualizar?

@apelisse parece bom! Vou adicionar isso à nossa planilha de rastreamento 1.14.

Qual seria a aparência da solicitação de API feita pelo cliente depois disso? Presumo que enviaria a definição de recurso local completa, mas ainda seria uma solicitação PATCH? Ou um PUT?

Estou muito animado com isso, pois elimina muita complexidade dos clientes personalizados.

Sim, receberá o objeto local no verbo PATCH, com um tipo de conteúdo específico.

A propósito, o link para a proposta de design está quebrado

Corrigido, obrigado, boa pegada.

Este parece ser o link mais recente https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/0006-apply.md

A propósito, todos os documentos do Google de design vinculados não podem ser vistos publicamente.

Olá Felix, esse doc precisa de uma limpeza massiva. Vou cuidar disso logo após o congelamento do código (ou antes, se tivermos tempo extra). Obrigado!

Estou de volta, talvez possa atualizar o KEP.

/ assign lavalamp

Olá @apelisse! Eu sou uma das sombras de lançamento de documentos v1.14.

Este aprimoramento requer novos documentos (ou modificações)?

Apenas um lembrete amigável de que estamos procurando um PR contra k / website (branch dev-1.14) com vencimento até sexta-feira, 1º de março. Seria ótimo se fosse o início da documentação completa, mas até mesmo um PR de espaço reservado é aceitável. Deixe-me saber se você tiver alguma dúvida!

Obrigado pelo lembrete @ cody-clark, definitivamente precisamos de documentação!

Perfeito! Vou marcá-lo na folha de rastreamento. Obrigado pela resposta rápida, @apelisse!

@apelisse examinando o KEP para este aprimoramento Não vejo nenhum plano de teste - alguém pode ajudar o PR nos planos de teste para este aprimoramento? Essas informações são úteis para saber se esse recurso está pronto para a versão e são especialmente úteis para o CI Signal.

Se não tivermos planos de teste, este aprimoramento estará em risco de ser incluído na versão 1.14

@claurence Eu atualizei a descrição, me diga se você esperava algo diferente! Obrigado!

Olá, sombra de realce 1.14 aqui. O Code Freeze é 7 de março e todos os PRs devem ser combinados até lá para fazer a versão 1.14. Quais K / K PRs abertos você ainda precisa fundir? Obrigado

Ei @lledru , temos alguns PRs em andamento que devem ser mesclados em uma semana ou assim. Nenhum deles está realmente bloqueando o lançamento e nós absolutamente poderíamos lançar no estado atual!

olá @apelisse ,
Você pode enviar um PR contra o KEP com o plano de teste?
Essas informações são úteis para saber se esse recurso está pronto para a versão e são especialmente úteis para o CI Signal.
Se não tivermos planos de teste, este aprimoramento estará em risco de ser incluído na versão 1.14
Muito obrigado.

Ei @apelisse , o prazo final da documentação foi na última sexta-feira, 1º de março (para abrir um espaço reservado para PR). Você tem algum PRs em andamento para os documentos dev-1.14? Ainda está visando 1,14?

Criamos o marcador de posição da documentação: https://github.com/kubernetes/website/pull/12898. Não tenho certeza se está correto, mas pelo menos existe :-)

@lledru Obrigado pelo lembrete, @jennybuckley está trabalhando na atualização do KEP.

@lledru Aqui está: # 878

@apelisse algum trabalho planejado aqui para 1.15 ou ficar em Alpha?

Sim, está indo para a versão beta 1.15, espero

Obrigado @apelisse. Quando chegar a hora certa, diminua os PRs k / k associados aos critérios de graduação beta que são chamados no KEP

/ milestone v1.15
/ stage beta

Ei @apelisse. Posso ver que você teve um PR de espaço reservado para 1.14, mas precisamos de um PR contra k / website (branch dev-1.15) com vencimento até quinta-feira, 30 de maio. Seria ótimo se fosse o início da documentação completa, mas até mesmo um PR de espaço reservado é aceitável. Deixe-me saber se você tiver alguma dúvida!

@simplytunde @apelisse Eu cuidarei disso, pois ainda tenho algumas coisas para colocar na documentação para minha tarefa "limpar campos gerenciados".

Obrigado @kwiesmueller, diga-me se posso ajudar!

Feito: https://github.com/kubernetes/website/pull/14300
Podemos usar isso como um espaço reservado para PR e para outras coisas que podemos querer adicionar para 1.15

Estou além do limite para isso pousar (mês que vem?).
Já existe uma maneira de experimentar (no Minikube)?

Olá, @apelisse @kwiesmueller . O Code Freeze é quinta-feira, 30 de maio de 2019 @ EOD PST . Todos os aprimoramentos que vão para o lançamento devem ser de código completo, incluindo testes , e ter documentos PRs abertos.

Liste todos os PRs k / k atuais para que possam ser rastreados durante o congelamento. Se os PRs não forem mesclados por congelamento, esse recurso será suspenso para o ciclo de lançamento 1.15. Somente problemas de bloqueio de liberação e PRs serão permitidos no marco.

Se você souber que isso vai escorregar, responda e nos informe. Obrigado!

Eu realmente não vejo como isso seria feito por congelamento de código. Eu acho que você pode marcá-lo para 1,16: - /

😭

@felixfbecker Você pode usar qualquer kubernetes 1.14 ou posterior com o recurso ServerSideApply habilitado para experimentá-lo.

No minikube, seria algo como ... minikube start --feature-gates=ServerSideApply=true pelo que eu entendi!

Lamentamos, mas temos um problema de escalabilidade que precisamos resolver primeiro.

/ marco claro

Ele habilita tudo o que foi lançado no 1.14 mais o que fundimos no master desde então.
Eu adoraria saber mais sobre os recursos que você deseja, o que você está construindo com eles e o que você não gosta no recurso! Sinta-se à vontade para me pingar no slack (apelisse @)

Esse último comentário foi dirigido a mim?

@felixfbecker e outra pessoa que deletou sua postagem ;-)

@felixfbecker Fui eu. Desculpe por ter excluído minha postagem, pois encontrei a resposta depois de tropeçar neste tópico 🙂

Olá @apelisse , sou a Sombra de Aprimoramento 1.16. Este recurso graduará os estágios alfa / beta / estável no 1.16? Informe-me para que possa ser adicionado à planilha de rastreamento 1.16 e eu possa atualizar o marco e as tags de estágio

Assim que a codificação começar ou se já tiver começado, liste todos os PRs k / k relevantes nesta edição para que possam ser rastreados corretamente.

As datas dos marcos são Enhancement Freeze 7/30 e Code Freeze 29/8.

Obrigada.

Sim, estamos planejando lançar esse recurso como Beta.

/ remove-label rastreado / não
/ rótulo rastreado / sim
/ milestone v1.16

Ei, @apelisse @lavalamp , sou o líder de lançamento de documentos

Este aprimoramento (ou o trabalho planejado para v1.16) requer novos documentos (ou modificações)?

Apenas um lembrete amigável de que estamos procurando um PR contra k / website (branch dev-1.16) com vencimento até sexta-feira, 23 de agosto. Seria ótimo se fosse o início da documentação completa, mas até mesmo um PR de espaço reservado é aceitável. Deixe-me saber se você tiver alguma dúvida!

Há uma versão limitada do aplicativo do lado do servidor disponível na v 13 (é onde meu cluster está)? Algumas trocas acima parecem sugerir que sim. Meu caso de uso é para criar pods / deplyments / serviços no loop de reconciliação de um operador. Usar api / core <> Pod etc. é entediante e sujeito a erros, e poder usar uma API de servidor para aplicar o yaml seria muito mais limpo para mim. Obrigado por qualquer sugestão ..

@champak , você pode experimentá-lo ativando o gate de recurso "ServerSideApply" seu apiserver, mas tenha em mente que este ainda é um recurso alfa.

O congelamento do código

@ kacole2 Sim, temos alguns:

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

Também precisamos de outro PR trivial para habilitar o recurso.

Quais são os critérios para algo entrar na versão beta? Eu tentei a aplicação do lado do servidor, mas não parece realmente utilizável como um substituto para a aplicação do lado do cliente que kubectl faz: https://github.com/kubernetes/kubernetes/issues/80916

@felixfbecker Desculpe, isso escapou das rachaduras! Obrigado por experimentar. Concordo que algo está errado e precisamos corrigi-lo para a versão beta.

Mas, em geral, parece que você espera que esta seja uma extensão da aplicação do lado do cliente; na verdade, é mais como um sistema paralelo - use um ou outro. O mecanismo geral de transição é seguir o conselho de Jenny em seu bug. Fizemos isso para fornecer uma experiência muito segura - você pode escolher exatamente o comportamento que deseja.

Forneceremos uma experiência de transição perfeita quando descontinuarmos a aplicação do lado do cliente.

Olá @apelisse , parece que https://github.com/kubernetes/kubernetes/pull/81816 não foi mesclado antes do congelamento do código e não está no Tide Merge Pool . Este recurso será alterado a partir da v1.16. Se você ainda deseja que isso faça parte da versão 1.16, registre uma exceção

O prs obrigatório foi mesclado, agora é a versão beta.

Na sexta-feira, 30 de agosto de 2019, 4:58 Kendrick Coleman [email protected]
escreveu:

Olá @apelisse https://github.com/apelisse parece que
kubernetes / kubernetes # 81816
https://github.com/kubernetes/kubernetes/pull/81816 não mesclava antes
o código está congelado e não está no Tide Merge Pool https://prow.k8s.io/tide .
Este recurso será alterado a partir da v1.16. Se você ainda gostaria de
faça parte da versão 1.16, registre uma exceção
https://github.com/kubernetes/sig-release/blob/master/releases/EXCEPTIONS.md

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/kubernetes/enhancements/issues/555?email_source=notifications&email_token=AAE6BFRCLZC47AWM6AQMJE3QHEDOPA5CNFSM4EZJX7R2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5ROEEA#issuecomment-526574096 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAE6BFRKMWNNIOAIINJGBELQHEDOPANCNFSM4EZJX7RQ
.

@lavalamp , você se importaria de esclarecer? você está dizendo que https://github.com/kubernetes/kubernetes/pull/81816 não era obrigatório para esse recurso estar em beta?

@guineveresaenger Não é obrigatório que este recurso esteja em beta. Esse PR é para abordar questões de escalabilidade e pode ser mesclado em uma versão futura, não muda a API e apenas melhora o desempenho em clusters onde muitas coisas são gerenciadas por este novo recurso

@guineveresaenger Sim, é

obrigado por me avisar @lavalamp

Olá @lavalamp @apelisse - 1.17 Melhorias lideradas aqui. Gostaria de verificar e ver se você acha que este aprimoramento será alterado para alfa / beta / estável no 1.17.

A programação de lançamento atual é:

• Segunda-feira, 23 de setembro - Começa o ciclo de lançamento
• Terça-feira, 15 de outubro, EOD PST - Congelamento de melhorias
• Quinta-feira, 14 de novembro, EOD PST - Código Congelado
• Terça-feira, 19 de novembro - os documentos devem ser preenchidos e revisados
• Segunda-feira, 9 de dezembro - Kubernetes 1.17.0 lançado

Em caso afirmativo, liste todos os PRs k / k relevantes nesta edição para que possam ser rastreados corretamente. 👍

Obrigado!

/ marco claro

Olá @mrbobbytables , estamos planejando grandes melhorias para este recurso para o próximo lançamento, mas não planejamos mudar para o GA ainda. Obrigado.

@apelisse observou - obrigado pela resposta rápida! 😄

Os problemas ficam obsoletos após 90 dias de inatividade.
Marque o problema como novo com /remove-lifecycle stale .
Problemas obsoletos apodrecem após 30 dias adicionais de inatividade e, eventualmente, fecham.

Se for seguro encerrar este problema agora, faça-o com /close .

Envie feedback para sig-testing, kubernetes / test-infra e / ou fejta .
/ lifecycle stale

/ remove-lifecycle stale

Estamos trabalhando em uma versão "beta 2" desse recurso para 1.18, não temos certeza de como / se precisamos rastrear isso, mas feliz em seguir um processo.

Olá @apelisse , obrigado por destacar isso! Vamos rastreá-lo como uma mudança em beta na folha de melhorias. Haverá alguma mudança no KEP associado a isso? Ou será apenas relacionado a mudanças no código? Se você pudesse vincular todos os k / k PRs associados a isso para que possamos rastreá-lo, isso seria ótimo.

Se você estiver fazendo alguma alteração no KEP, o Congelamento de Aprimoramentos será em 28 de janeiro
O Code Freeze será em 5 de março .

Obrigado!

/ milestone v1.18

Podemos ter https://github.com/kubernetes/enhancements/pull/1442 mesclados até o dia 28.
Talvez até https://github.com/kubernetes/enhancements/pull/923.

E eu acabei de ver que https://github.com/kubernetes/enhancements/pull/1123 foi mesclada, então a implementação também pode chegar ao 1.18.

Olá, @apelisse - sou uma sombra do Docs na equipe de lançamento do 1.18.

Este trabalho de aprimoramento planejado para 1.18 requer novos documentos ou modificações nos documentos existentes?

Se não, você pode atualizar a Folha de Rastreador de Aprimoramento 1.18 (ou me avise e eu o farei)

Se atualizações de documentos forem necessárias, lembre-se de que os PRs de espaço reservado para k / website (branch dev-1.18) são devidos até sexta-feira, 28 de fevereiro.

Deixe-me saber se você tiver alguma dúvida!

No momento, estamos trabalhando nos documentos, obrigado pelo lembrete!

Ei @apelisse @kwiesmueller ,

Apenas um lembrete amigável de que o congelamento do código para 1.18 é em 5 de março de 2020 .

À medida que rastreamos o congelamento do código, liste / conecte-se a todos os PRs em que você está trabalhando para graduar este aprimoramento!

Obrigado pela lembrança!

Ei @apelisse @kwiesmueller ,

Circulando de volta conforme estamos nos aproximando do congelamento de código. Liste todos os k / k PRs em que você está trabalhando para que possamos rastrear melhor esse problema .

Acho que não vamos conseguir com as coisas em que estou trabalhando.
@apelisse pode ter alguns e provavelmente @julianvmodesto com dryrun e diff?

Criei o documento de espaço reservado PR: https://github.com/kubernetes/website/pull/19286

Olá @apelisse, lembrete amigável de que o congelamento de código para 1.18 é 5 de março . Faltam apenas alguns dias. Obrigado por abrir o PR de documentos acima ... você poderia criar um link para quaisquer PRs K / K relevantes para isso, para que possamos acompanhar melhor o progresso do aprimoramento conforme nos aproximamos do congelamento de código?

Muito obrigado!

Olá @apelisse , infelizmente https://github.com/kubernetes/kubernetes/pull/88875 não fundiu antes do congelamento do código (parece que ainda precisa ser aprovado). Neste ponto, você precisará registrar uma solicitação de exceção para este.

/ marco claro

O que está acontecendo com isso?

Ainda somos beta, trabalhamos em novas melhorias, mas ainda não estamos prontos para o GA. Nós lançaremos uma postagem no blog em alguns dias sobre isso!

Olá @apelisse - 1.19, líder de melhorias aqui, gostaria de verificar se você acha que esta melhoria seria graduada em 1.19.

A programação de lançamento atual é:

• Segunda-feira, 13 de abril: Semana 1 - Início do ciclo de lançamento
• Terça-feira, 19 de maio: Semana 6 - congelamento de melhorias
• Quinta-feira, 25 de junho: Semana 11 - Code Freeze
• Quinta-feira, 9 de julho: Semana 14 - os documentos devem ser concluídos e revisados
• Terça-feira, 4 de agosto: Semana 17 - Kubernetes v1.19.0 lançado

Olá, não estamos planejando promover esse recurso neste ciclo, obrigado!

Obrigado @apelisse pelas atualizações. Vou atualizar a folha de acompanhamento de acordo. : +1:

Os problemas ficam obsoletos após 90 dias de inatividade.
Marque o problema como novo com /remove-lifecycle stale .
Problemas obsoletos apodrecem após 30 dias adicionais de inatividade e, eventualmente, fecham.

Se for seguro encerrar este problema agora, faça-o com /close .

Envie feedback para sig-testing, kubernetes / test-infra e / ou fejta .
/ lifecycle stale

/ remove-lifecycle stale

Oi @apelisse

Melhorias liderar aqui. Algum plano de graduar isso em 1,20?

Obrigado,
Kirsten

Na verdade não, estamos planejando continuar melhorando o recurso existente, mas não há formatura programada para 1,20, obrigado!