Server-tools: [RFC] Split Server-Tools для v11

Созданный на 2 окт. 2017  ·  22Комментарии  ·  Источник: OCA/server-tools

Принесите это из ветки списка рассылки для окончательного обсуждения.

От @dreisptкое- что, но это тот, который все еще актуален сейчас и должен быть обсужден):

Здравствуйте,

Считаю, что репо можно разделить на несколько более целевых.

Я предлагаю оставить OCA / serverl-tools в основном для функций, связанных с задачами настройки и администрирования.
Остальные функции можно перенести в несколько новых дополнительных репозиториев.

Я могу придумать четыре новых репозитория, которые можно создать как дополнительные:

  • OCA / server-auth (10 модулей): связанные с аутентификацией
  • OCA / server-backend (5 модулей): расширения серверной ORM, новые поля
  • OCA / server-brand (8 модулей и их количество): (Де) связанные с брендингом
  • OCA / server-ux (11 модулей): функции на стороне сервера для удобства использования и взаимодействия с пользователем

Поддерживая вышеупомянутый раздел и в качестве отправной точки для обсуждения, я подготовил эту электронную таблицу:
https://docs.google.com/spreadsheets/d/1Xg95cW4TFMf_Lo5i_CZC_qOOfN8RgxPRc0LJTLTkdUI/edit?usp=sharing

cc @pedrobaeza @hbrunn @ OCA / доска

question

Самый полезный комментарий

спасибо @lasley и @pedrobaeza

Все 22 Комментарий

Поднять это снова было в моем списке, большое спасибо за то, что поднял это, Дэйв.
Опыт подсказывает нам, что у целевых репозиториев лучше направление и больше мотивированных сопровождающих.
Этот репозиторий охватывает слишком много разных тем, чтобы его можно было эффективно поддерживать.
Также есть признаки того, что он слишком велик, если посмотреть на количество существующих модулей и открытых PR.

Предлагаемый список дополнительных доходов довольно старый, поэтому может потребоваться его обновление.

@dreispt Я не вижу консенсуса, и в то же время я вижу, что PR к v11 происходит, когда мы говорим. Я предлагаю отложить эту тему до версии 12, так как кажется, что такого рода структурные изменения нужно планировать задолго до выхода новой версии.

К сожалению, я вынужден согласиться с тем, что этот разговор начинается слишком поздно: нам нужно сейчас спланировать структуру репозитория для v12.

Хорошо, я соответствующим образом переименовал проблему.

Нет, это можно сделать в версии 11 и даже больше, когда репо опустело. На следующий день я создаю репо.

Я поднял эту тему еще в июне- августе. Я считаю, что мы должны сделать это сейчас, иначе этого никогда не будет.

Если @pedrobaeza создает репозитории, все в порядке. У нас есть некоторые PR, ожидающие слияния с v11, и мы подождем, пока он закончит, чтобы решить, куда их поместить.

@jbeficent Еще не поздно, ветки v11 еще пусты.
AFAICR не возражал против этого шага, он просто не был реализован.
Может быть, у @lasley есть ссылка для обсуждения.

@dreispt без проблем. Нам так не терпится перейти на v11 !!! Буду ждать @pedrobaeza

Я на нем!

Хорошо, я создал все новые репозитории. Вы можете начать к ним подталкивать. Закрытие этой проблемы и включение документа с отображением по проблеме миграции.

Спасибо!!

спасибо @lasley и @pedrobaeza

мы также хотим попросить людей, предлагающих новые модули для серверных инструментов в более низких версиях, перенести туда свои PR? Имхо имхо
(редактировать: конечно, только не объединенные PR, которые действительно представляют новый модуль)

Ну, я не создавал ветки для более низких версий, но если вам это интересно, то продолжайте.

Будем ли мы рекламировать это в ML?

Да, это может быть интересно. И это должно быть частью следующего информационного бюллетеня.

первый раз просматриваю такой пиар создаю ветку - сейчас не вижу смысла делать это заранее

ОК, согласен

И это должно быть частью следующего информационного бюллетеня.

Я создал тикет, чтобы мы не забыли про информационный бюллетень. Отличная идея

Чтобы помочь людям с тем, что и куда происходит, у нас должны быть проблемы с миграцией v11 со списком модулей, исключенных для миграции, в каждом из репозиториев.

Пересматривая коммуникацию ML, это нужно сделать как можно скорее. В следующем информационном бюллетене мы также упомянем об этом со ссылкой на сообщение ML.

Была ли эта страница полезной?
0 / 5 - 0 рейтинги