/programación de firmas

Hola @sparciii -- Sombra de mejoras 1.18 aquí. Quería verificar y ver si cree que esta mejora se graduará a alfa|beta|estable en 1.18.

El calendario de lanzamiento actual es:
Lunes 6 de enero: comienza el ciclo de lanzamiento
Martes, 28 de enero EOD PST - Congelación de mejoras
Jueves, 5 de marzo, EOD PST - Code Freeze
Lunes, 16 de marzo: los documentos deben completarse y revisarse
Martes 24 de marzo: lanzamiento de Kubernetes 1.18.0

Para ser incluida en el lanzamiento, esta mejora debe tener un KEP fusionado en el estado de implementación. El KEP también debe tener definidos los criterios de graduación y un Plan de Pruebas.
Si desea incluir esta mejora, una vez que comience la codificación, enumere todos los PR k/k relevantes en este problema para que se puedan rastrear correctamente. 👍

Seguiremos las mejoras aquí: http://bit.ly/k8s-1-18-enhancements
¡Gracias!

Como recordatorio @sparciii :

Martes, 28 de enero EOD PST - Congelación de mejoras

Mejoras La congelación es en 7 días. Si busca la inclusión en 1.18, actualice como se solicitó anteriormente.

¡Gracias!

¡Gracias @kikisdeliveryservice por el recordatorio! Consultaré en el canal de holgura y en el próximo horario de atención para recibir comentarios si este KEP es una solicitud razonable.

según la discusión con @Huang-Wei, mantendremos este KEP y cerraremos https://github.com/kubernetes/kubernetes/pull/84405 a favor de enviarlo al subrepo https://github.com/kubernetes- sigs/scheduler-plugins donde el código se adherirá al marco del programador.

@sparciii , ¿intentará hacer 1.18 para alfa? Solo házmelo saber para que podamos rastrearlo.

¡Gracias!

@kikisdeliveryservice no . Pertenece a un sub-repo.

En realidad, una pregunta general que quiero hacer es: si el KEP apunta a un sub-repositorio (kubernetes-sigs/xyz), ¿deberíamos usar k/enhancement para alojar el KEP?

Hola @Huang-Wei,

En primer lugar, consulte aquí: https://github.com/kubernetes/enhancements#is -my-thing-an-enhancement

En segundo lugar, algunas preguntas/cosas en las que pensar para mejoras fuera de k/k: ¿los usuarios de k/k confiarán en esta función? ¿Necesitará comunicar esto/necesitará apoyo del equipo de lanzamiento? ¿Tu trabajo seguirá y estará limitado por los ciclos de publicación?

¿Parece que este trabajo será un complemento opcional? ¿Pasarás por las versiones alfa/beta/estable?

Gracias @kikisdeliveryservice . Sí, es más un complemento opcional que se alojará fuera de k/k, creo que debería administrarse como una discusión de documento de diseño en https://github.com/kubernetes-sigs/scheduler-plugins. Sin embargo, podemos aprovechar el esquema de la plantilla KEP.

cc/ @denkensk @alculquicondor

SGTM

Los problemas se vuelven obsoletos después de 90 días de inactividad.
Marque el problema como nuevo con /remove-lifecycle stale .
Los problemas obsoletos se pudren después de 30 días adicionales de inactividad y finalmente se cierran.

Si es seguro cerrar este problema ahora, hágalo con /close .

Envíe comentarios a sig-testing, kubernetes/test-infra y/o fejta .
/ciclo de vida obsoleto

/cerrar

@sparciii , siéntase libre de abrir un problema o relaciones públicas en https://github.com/kubernetes-sigs/scheduler-plugins si aún no lo ha hecho.

@alculquicondor : Cerrando este tema.