Server-tools: [RFC] Split Server-Tools für v11

Erstellt am 2. Okt. 2017  ·  22Kommentare  ·  Quelle: OCA/server-tools

Bringen Sie dies aus einem Mailinglisten-Thread zur abschließenden Diskussion.

Von @dreispt (es gibt mehr im Thread, aber dies ist derjenige, der

Hallo,

Ich glaube, dass das Repo in mehrere fokussiertere unterteilt werden kann.

Ich schlage vor, OCA / Serverl-Tools hauptsächlich für Funktionen im Zusammenhang mit Konfigurations- und Verwaltungsaufgaben beizubehalten.
Die anderen Funktionen können auf einige neue Spinf-Off-Repos verschoben werden.

Ich kann mir vier neue Repos als Spin-offs vorstellen:

  • OCA / Server-Auth (10 Module): Authentifizierungsbezogen
  • OCA / Server-Backend (5 Module): Server-ORM-Erweiterungen, neue Felder
  • OCA / Server-Marke (8 Module und Zählung): (De) Branding bezogen
  • OCA / Server-UX (11 Module): Serverseitige Funktionen für Benutzerfreundlichkeit und Benutzererfahrung

Zur Unterstützung der obigen Unterteilung und als Ausgangspunkt für die Diskussion habe ich diese Tabelle vorbereitet:
https://docs.google.com/spreadsheets/d/1Xg95cW4TFMf_Lo5i_CZC_qOOfN8RgxPRc0LJTLTkdUI/edit?usp=sharing

cc @pedrobaeza @hbrunn @ OCA / board

question

Hilfreichster Kommentar

danke @lasley und @pedrobaeza

Alle 22 Kommentare

Das noch einmal anzusprechen war auf meiner Liste, vielen Dank, dass du es angesprochen hast, Dave.
Die Erfahrung zeigt, dass fokussierte Repositories eine bessere Ausrichtung und motiviertere Betreuer haben.
Dieses Repository behandelt zu viele verschiedene Themen, als dass es effektiv verwaltet werden könnte.
Es gibt auch Anzeichen dafür, dass es zu groß ist, wenn man die Anzahl der vorhandenen Module und offenen PRs betrachtet.

Die vorgeschlagenen Ausgründungen der Liste sind ziemlich alt, daher benötigen sie möglicherweise ein Update.

@dreispt Ich sehe keinen Konsens und gleichzeitig sehe ich, dass die PRs zu v11 auftreten, während wir sprechen. Ich schlage vor, dieses Thema bis Version 12 zu verschieben, da diese Art von strukturellen Änderungen anscheinend lange vor einer neuen Version geplant werden müssen.

Leider muss ich zustimmen, dass dieses Gespräch zu spät beginnt: Wir müssen jetzt die Repository-Struktur für v12 NOW planen.

OK, ich habe das Problem entsprechend umbenannt.

Nein, dies ist in Version 11 perfekt möglich, und mehr noch, wenn das Repo geleert wurde. Ich erstelle die Repos am nächsten Tag.

Ich habe dieses Thema bereits im Juni August angesprochen. Mein Standpunkt ist, dass wir es jetzt tun sollten, sonst wird es nie erledigt.

Wenn @pedrobaeza die Repos erstellt, ist dies in

@jbeficent Es ist noch nicht zu spät, die v11-Zweige sind noch leer.
AFAICR gab es keine Opposition gegen diesen Schritt, es wurde einfach nicht umgesetzt.
Vielleicht hat @lasley einen Link für die Diskussion.

@dreispt kein Problem. Wir sind so gespannt auf v11 !!! Ich werde auf @pedrobaeza warten

Ich bin dabei!

OK, ich habe alle neuen Repositorys erstellt. Sie können anfangen, zu ihnen zu schieben. Schließen dieses Problems und Einfügen des Dokuments in die Zuordnung zum Migrationsproblem.

Vielen Dank!!

danke @lasley und @pedrobaeza

Wollen wir auch Leute bitten, die Server-Tools in niedrigeren Versionen neue Module vorschlagen, um ihre PRs dorthin zu verschieben? Würde imho Sinn machen
(Bearbeiten: Natürlich nur nicht zusammengeführte PRs, die wirklich ein neues Modul einführen)

Nun, ich habe keine Zweige für niedrigere Versionen erstellt, aber wenn Sie es interessant finden, fahren Sie fort.

Sollen wir es im Mitwirkenden ML bewerben?

Ja, das kann interessant sein. Und es sollte Teil des nächsten Newsletters sein.

Wenn ich zum ersten Mal eine solche PR überprüfe, erstelle ich die Filiale - sehe keinen Grund, dies vorher zu tun

In Ordnung, einverstanden

Und es sollte Teil des nächsten Newsletters sein.

Ich habe ein Ticket erstellt, damit wir den Newsletter nicht vergessen. Gute Idee

Um den Leuten zu helfen, was wohin geht, sollten wir v11-Migrationsprobleme mit der Liste der Module haben, mit Ausnahme der Migration auf jedem der Repos.

Um die ML-Kommunikation neu zu bewerten, sollte dies so schnell wie möglich geschehen. Im nächsten Newsletter werden wir dies auch mit einem Link zur ML-Nachricht erwähnen.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen

Verwandte Themen

legalsylvain picture legalsylvain  ·  34Kommentare

lasley picture lasley  ·  20Kommentare

OCA-git-bot picture OCA-git-bot  ·  30Kommentare

kittiu picture kittiu  ·  5Kommentare

pedrobaeza picture pedrobaeza  ·  19Kommentare