Server-tools: [RFC] Herramientas de servidor divididas para v11

Creado en 2 oct. 2017  ·  22Comentarios  ·  Fuente: OCA/server-tools

Traer esto desde un hilo de la lista de correo para la discusión final.

De @dreispt (hay más en el hilo, pero este es el que sigue siendo relevante en este momento y debería discutirse):

Hola,

Creo que el repositorio se puede subdividir en varios más enfocados.

Propongo mantener OCA / serverl-tools principalmente para funciones relacionadas con tareas de configuración y administración.
Las otras características se pueden mover a algunos nuevos repositorios derivados.

Puedo pensar en cuatro nuevos repositorios para crear como spin-offs:

  • OCA / server-auth (10 módulos): relacionado con la autenticación
  • OCA / servidor-backend (5 módulos): extensiones de servidor ORM, nuevos campos
  • OCA / marca del servidor (8 módulos y contando): Relacionado con la (des) marca
  • OCA / server-ux (11 módulos): características del lado del servidor para la usabilidad y la experiencia del usuario relacionadas

Apoyando la división anterior, y como punto de partida para la discusión, preparé esta hoja de cálculo:
https://docs.google.com/spreadsheets/d/1Xg95cW4TFMf_Lo5i_CZC_qOOfN8RgxPRc0LJTLTkdUI/edit?usp=sharing

cc @pedrobaeza @hbrunn @ OCA / tablero

question

Comentario más útil

gracias @lasley y @pedrobaeza

Todos 22 comentarios

Traer esto de nuevo estaba en mi lista, muchas gracias por mencionarlo Dave.
La experiencia nos dice que los repositorios enfocados tienen una mejor dirección y mantenedores más motivados.
Este repositorio cubre demasiados temas diferentes para que se mantenga de manera efectiva.
También tiene signos de ser demasiado grande, teniendo en cuenta la cantidad de módulos existentes y PR abiertos.

La lista de productos derivados propuestos es bastante antigua, por lo que es posible que necesiten una actualización.

@dreispt No veo consenso, y al mismo tiempo veo que las relaciones públicas de v11 están ocurriendo mientras hablamos. Propongo posponer este tema hasta la v12, ya que parece que este tipo de cambios estructurales deben planificarse con mucha anticipación a una nueva versión.

Desafortunadamente, tengo que estar de acuerdo en que esta conversación comienza demasiado tarde: necesitamos planificar ahora la estructura del repositorio para la v12 AHORA.

Bien, he cambiado el nombre del problema en consecuencia.

No, se puede hacer perfectamente en v11, y más a medida que se vacia el repositorio. Estoy creando los repositorios al día siguiente.

Mencioné este tema en junio de agosto. Mi punto de vista es que deberíamos hacerlo ahora o nunca se hará.

Si @pedrobaeza crea los

@jbeficent No es demasiado tarde, las ramas v11 todavía están vacías.
AFAICR no hubo oposición a este movimiento, simplemente no se implementó.
Quizás @lasley tenga un enlace para la discusión.

@dreispt no hay problema. ¡¡¡Estamos ansiosos por comenzar a avanzar hacia la v11 !!! Esperaré a @pedrobaeza

¡Estoy en ello!

Bien, he creado todos los nuevos repositorios. Puedes empezar a presionar hacia ellos. Cerrando este tema e incluyendo el documento con el mapeo sobre el tema migratorio.

¡¡Gracias!!

gracias @lasley y @pedrobaeza

¿También queremos pedirle a las personas que proponen nuevos módulos para herramientas de servidor en versiones inferiores que muevan sus RP allí? Tendría sentido en mi humilde opinión
(editar: por supuesto, solo los RP no fusionados que realmente introducen un nuevo módulo)

Bueno, no he creado ramas para versiones inferiores, pero si crees que es interesante, adelante.

¿Lo anunciamos en el ML de contribuyentes?

Sí, puede ser interesante. Y debería ser parte del próximo boletín.

la primera vez que revise un PR de este tipo, crearé la sucursal; no veo una razón para hacerlo de antemano ahora

Vale, de acuerdo

Y debería ser parte del próximo boletín.

Creé un ticket para que no nos olvidemos del boletín. Buena idea

Para ayudar a las personas con lo que va a dónde, deberíamos tener problemas de migración v11 con la lista de módulos que se pueden migrar en cada uno de los repositorios.

La actualización de la comunicación ML debe hacerse lo antes posible. En el próximo boletín también lo mencionaremos, con un enlace al mensaje ML.

¿Fue útil esta página
0 / 5 - 0 calificaciones