Gitea: Diskussion der Gitea-Roadmap

Eine Plugin-Lösung (einschließlich Theme) zum Erweitern von gitea.

Wäre es möglich, dem Build-Prozess geeignete Betriebssystempakete hinzuzufügen? Ich habe versucht, etwas für Fedora zusammenzustellen, aber es scheint ein Durcheinander zu sein, zu verpacken. #31 Art von Gesprächen darüber, scheint aber immer noch offen zu sein.

Wir verwenden ansible, um den Tarball auf dem Debian-System bereitzustellen, das ist nicht sehr praktisch, aber es funktioniert. Repositorys für die gängigsten Distributionen wären schön, aber es muss eingerichtet und gewartet werden.

Ein paar Vorschläge:

• Option zur automatischen Integration von Drone CI/CD in Gitea während des Build-Prozesses.
• Mehr Konfigurierbarkeit der Site-Administration über die Gitea-Benutzeroberfläche, nach der Installation. Zum Beispiel möchte ich in der Lage sein, die Dinge in _Service Configuration_ auf der Seite _Configuration_ zu ändern.
• Option zum Ausblenden eines Benutzers auf der Explore-Seite.

Federated Pull Requests / Issues / Forks

Federated Pull Requests / Issues / Forks

Vielleicht nicht föderiert im Sinne des Wortes Fediverse (ActivityPub, OStatus, Diaspora*, etc.), aber ich möchte die Möglichkeit, mit entfernten Instanzen aus den eigenen Reihen zu interagieren, so implementiert, wie es am besten zum Projekt passt.

Es könnte auch cool sein, Teams und Organisationen zu haben, die aus Benutzern aus mehreren Instanzen bestehen, obwohl dies wahrscheinlich unglaublich schwierig zu implementieren wäre.

Zwei Vorschläge aus dem POV eines Endbenutzers mit minimalen Programmierkenntnissen, der versucht, Open-Source-Projekten zu helfen, die ich verwende, indem er Fehler meldet und UX-Feedback gibt:
1) Helfen Sie mit, ForgeFed zu standardisieren! Ich würde es lieben, wenn die UX beim Einreichen von Fehlern auf der Instanz von Gitea (und anderen von der Community gehosteten Codeschmieden) wie ein riesiges, dezentrales GH wäre.
2) Machen Sie jeden Teil eines Projekts zu einem Git-Repository, damit Issues, Wiki usw. leicht gezogen, verzweigt, verschoben oder gegabelt werden können. GL und sr.ht tun dies zumindest mit einigen ihrer Komponenten. Dies ist nicht nur nützlich, sondern könnte auch bei Punkt 1) helfen.

Die Möglichkeit, Tickets per E-Mail zu beantworten, wäre ein großer Schritt nach vorne für die Benutzerfreundlichkeit

Erlauben Sie die Bearbeitung der gesamten Konfiguration über die Benutzeroberfläche (und ändern Sie möglicherweise das Konfigurationsdateiformat während des Vorgangs)

Vielleicht den größten Teil der Konfiguration in der Datenbank speichern und die richtige Cli und API dafür bereitstellen

@sapk @tboerger Ich würde sagen, wir sollten für die Konfiguration zu Viper wechseln, auf diese Weise könnten wir ini (und einige der Fehler, die wir damit hatten) loswerden und Dinge wie das Neuladen der Konfiguration während Gitea und die richtigen env-Variablen erhalten .

Ich würde das gerne in Angriff nehmen, aber ich bin mir nicht sicher, ob ich in naher Zukunft die Zeit finden werde.

Ich bin auch für Viper. Ich habe es vor 2 Jahren versucht, hatte aber keine Zeit, es zu beenden ... aber ich kann es noch einmal versuchen :)

Ich bin dafür, eine minimalere Konfigurationsdatei zu erhalten ... Viele dieser Einstellungen müssen nicht über eine statische Konfigurationsdatei festgelegt werden und könnten aus Leistungsgründen leicht zur Datenbank hinzugefügt und zwischengespeichert werden.

Ich denke, wir könnten zuerst eine Datenbankkonfigurationstabelle hinzufügen und die meisten veränderbaren Konfigurationselemente aus der INI-Datei dorthin verschieben und nur Elemente belassen, die neu geladen werden müssen.

@lunny und alle: zustimmen, viele Einstellungen in die Datenbank zu verschieben und sie in der Webschnittstelle konfigurieren zu lassen (entweder Site-weit oder Repo-weit) fühlt sich wie ein guter Schritt nach vorne an. Es wäre dann auch einfach, ein Tool wie tea oder gitea selbst in der Lage zu haben, diese Werte über die Befehlszeile zu ändern, sodass Sie immer noch ein Standard-Setup skripten könnten.

Modulsystem klingt super. Ich glaube, es gibt viele Leute da draußen, die bereit sind, gitea neue Funktionen hinzuzufügen.

@belliash @sapk IMO-Plugins/-Module können nicht effizient implementiert werden, ohne das vollständig umzugestalten und mehr Abstraktion hinzuzufügen. Ich habe mehrere Technologien wie die native Plugin-Unterstützung von Go getestet.

Das Ergebnis waren riesige Binärdateien, die stark von der Gitea-Binärdatei abhängig sind.

Ich denke, es ist realistischer, die Webhook-Unterstützung zu verbessern und benutzerdefinierte Seiten durch Webhooks hinzuzufügen, da wir bereits eine ruhige ausgereifte API haben, die für Datenbankoperationen verwendet werden kann.

@jonasfranz Ich wäre sehr dafür, Modelle

go list -f  '{{ .Imports }}' code.gitea.io/gitea/models 

ergibt 98 (!) Direktimporte. 50 davon sind Non-Go-Core.

go list -f  '{{ .Deps }}' code.gitea.io/gitea/models

offenbart 437 (!!) transitive Abhängigkeiten. (304 davon sind Non-Go-Core)

Schauen Sie sich die Drohnenquelle an, da haben wir viele steckbare Sachen, die auf Webhooks basieren.

Daneben macht ein Plugin-Modell wie packer Sinn, ein grpc-basiertes Plugin-System.

@tboerger Können Sie ein Beispiel aus den steckbaren Sachen der Drohne liefern? Meinst du das Plugin-System basierend auf Docker-Images?

Ich spreche von den Erweiterungen für Configs, Secrets und so weiter, die Schnittstellen sollten unter https://github.com/drone/drone/tree/master/plugin definiert werden

Ich stimme Ihnen zu, der nächste große Schritt von Gitea sollte das Plugin-System sein. Das denke ich heutzutage auch. Ich werde das Plugin-System mal ausprobieren.

Ich denke, es sollte mit dem Plugin-System von Drohnen ähnlich sein, aber mehr haben. Wir müssen zulassen, dass ein Plugin eine Benutzeroberfläche hat und sollte sich automatisch mit Giteas OAuth2 anmelden. Und wir sollten einige Sicherheitsrichtlinien für die Plugins haben. und ETC.

Ich möchte eine Vergleichstabelle teilen, die wir ca. 2016 erstellt haben, um zu _entscheiden_, welche Hosting-Plattform für die Open Source Geospatial Foundation ausgewählt werden soll. In dieser Tabelle haben wir Funktionen aufgelistet, die für uns wichtig waren. Gitea ist in einer der Spalten:

https://wiki.osgeo.org/wiki/GitInfrastructureComparison

Sie werden sehen, dass ein wichtiges Feature, das 2016 gefehlt hat, heute noch fehlt: Antwort per Mail (Kommentar/Antwort) --- einige andere sind seit heute implementiert.

@strk- Tool zu migrate from github und Comments on diff lines sind fertig.

Anpassung der E-Mail-Vorlage erforderlich
Siehe #6037

Es ist also bereits einiges an Vorlagenanpassungen möglich - die Betreffzeile ist das einzige, was wir meiner Meinung nach nicht haben.

Was wir jedoch wirklich tun sollten, ist i18n für E-Mail und die git serv Hook-Nachrichten zu aktivieren.

Zurücksetzen eines Pull-Requests erforderlich.
Siehe #6375

Volle Unterstützung von Tags in der Benutzeroberfläche. Erstellen, zuweisen, ändern, löschen usw. Diese Funktion vermisse ich sehr.

Ich befürworte die Konfiguration in der Datenbank (mit cli oder api, um sie zu konfigurieren, wie Benutzer- und Authentifizierungs-LDAP usw. erstellen) und Plugin-System.
Diese beiden sollten gitea einen großen Schritt nach vorne bringen.

LFS

• [x] Wir brauchen eine Möglichkeit, LFS-Dateien in einem Repository zu verwalten - derzeit sind sie völlig undurchsichtig #7199 ist ein Versuch, dies bereitzustellen - aber um effizient zu sein, braucht es wahrscheinlich ...
  
  
  
  • [ ] Bloom-Filter für die Blob-Suche - es wäre sehr gut, eine etwas effiziente Möglichkeit zu haben, den Commit zu finden und in welchem ​​Baumpfad ein Blob eingeführt wurde
  
  
• [ ] Derzeit gibt es keine zuverlässige Möglichkeit, einen Upload auf LFS neu zu starten - daher können sehr große Uploads wiederholt fehlschlagen. Implementieren Sie tus.io gemäß #1723
• [ ] Wir sollten eine Option bereitstellen, um nur .gitattributes zu verwenden, um zu bestimmen, ob eine Datei ein LFS-Zeiger ist, anstatt einfach davon auszugehen, dass jede Datei, die wie ein Zeiger aussieht, ein Zeiger ist. Obwohl dies die Funktionalität in #7199 wahrscheinlich sehr schwierig machen wird ...
• [ ] LFS-Dateien sollten in der Diff-Ansicht angezeigt werden können.

Härten

Shutdown und der Beginn, Gitea wirklich clusterfähig zu machen

• [ ] Wir müssen Giteas Reaktion auf das Herunterfahren abhärten.
  
  
  
  • [x] Dies bedeutet ein ordnungsgemäßes Herunterfahren von Listening-Verbindungen, insbesondere des eingebauten SSH - das derzeit durch abruptes Herunterfahren zu einer Beschädigung von Git-Repositorys führen könnte. #7274 ist ein Versuch, dies zu beheben.
  
  
  • [ ], aber es bedeutet auch, dass Benachrichtigungen wie Jobs serialisierbar sein müssen - zB sollten Indexierungswarteschlangen durch On-Disk- oder DB-Warteschlangen, ähnlich Mail-Warteschlangen usw. erfolgen. Wir haben bereits einiges davon, aber diese Warteschlangen werden nicht ordnungsgemäß beendet.
  
  
• [ ] Als Folge davon sollten wir die Indizierung von der Suche trennen. Das ordnungsgemäße Herunterfahren erfordert dies auf jeden Fall – aber es ist Teil des Schritts in Richtung Clustering. Ich bin mir nicht sicher, welche Architektur wir verwenden sollten, aber es gibt mehrere Optionen - trennen Sie den Indexer in einen separaten Prozess und lassen Sie Gitea den Index schreibgeschützt oder exportieren Sie die gesamte Indizierung.

Diff und Einlesen von Daten beliebiger Länge in den Speicher

• [ ] Diff-Code muss umgestaltet werden - er ist fragil, liest das gesamte Diff in den Speicher und erfordert, dass riesige Diffs vom Browser analysiert werden, bevor der Benutzer antworten kann. Dies erfordert sowohl Änderungen an der Benutzeroberfläche als auch am Server - vermutlich ist ein unendlicher Bildlauf mit Ajax-Unterstützung die richtige Technik dafür. Gegenwärtig könnte ein ausreichend böses großes Diff sowohl Server als auch Browser lahmlegen.
• [ ] Unsere Diff-Architektur verschmutzt derzeit das Basis-Repository mit vorgefertigten Zweigen und Objekten.
• [ ] Im Allgemeinen MÜSSEN wir aufhören, nur Daten beliebiger Länge in den Speicher zu lesen. Wenn es eine Stelle gibt, an der der Browser dies wünscht, sollten wir das, was wir lesen, einschränken und dann entweder eine unendliche Scroll-Technik oder einen vollständigen Link mit Browser-Rendering verwenden oder in einer Pipeline gerendert werden, um sicherzustellen, dass es nicht vollständig im Speicher gepuffert wird. Auch relativ neuer Code leidet noch unter diesem Problem.
• [ ] (Wenn wir einen Git-Prozess ausführen, der beliebig lange Daten zurückgeben kann, sollten wir versuchen, sie nicht vollständig direkt in einen Standardpuffer zu lesen, sondern mehr Routine-Pipelines ausführen.)

Verschmelzen

• [ ] Wir müssen Merge umgestalten, um den Git-Index vollständig zu verwenden, da wir derzeit einen spärlichen Checkout zum Zusammenführen durchführen - im Grunde, weil Git-Merge auf https://git-scm.com/docs/git-merge-one-file to . herunterfällt Nicht-Fast-Forward-Zusammenführungen verarbeiten. Dies erzwingt die Erstellung von semi-beliebigen Pfaden auf dem Server - die unnötig sind und von den Zeichensatz-/Dateisystemfaktoren abhängig sind. Dies ist nicht erforderlich - wir können diese Zusammenführungen mit temporären Dateien, Hashing und direktes Hinzufügen zum Index durchführen.

Escape- und Repository-Standorte

• [ ] Wir müssen überall nach Flucht suchen. Legacy-Gogs-Code wurde im Allgemeinen nur schlecht entkommen und war für mehrere Sicherheitsprobleme verantwortlich.
• [ ] Die Annahme, dass der Benutzername und die Repository-Namen nicht maskiert werden müssen, zwingt uns eine Architekturentscheidung auf, die wir nicht brauchen. Es hat uns nicht einmal richtig für Git-Signaturen geschützt, daher #5774.
• [] Obwohl angenehm es ist für die Benutzer der zugrunde liegende Repository - Position zu haben , um die Position im Dateisystem entsprechen - zB $GITEA_ROOT/owner/reponame von git auf dem Server ist es eine schlechte architektonische Entscheidung IMHO und führte zu Annahmen , die von den Benutzern , dass unsere Repositories noch verwendet werden können , ohne weiter gedacht - SIE SOLLTEN NICHT. Wir sollten zu $GITEA_ROOT/repository-$ID wechseln, möglicherweise in Scherben. (Dadurch könnten viele Anrufe an repo.MustOwner() oder repo.GetOwner() )
  
  
  
  • [ ] Sobald wir zum oben genannten übergehen und alles richtig entkommen, können wir die Einschränkungen für die Benutzernamen und Repository-Namen lockern - obwohl dies sorgfältig durchdacht werden müsste, um sicherzustellen, dass wir dies auf eine Weise tun, die dies nicht zulässt Fälschen durch ähnliche Probleme wie #5774.
  
  
• [x] Wir sollten erzwingen, dass Server-Git-Prozesse mit einer ausreichenden Gitea-Umgebung ausgeführt werden müssen - es gibt wiederholt Benutzer, die versuchen, Giteas Repositorys auf dem Server zu verwenden, ohne Gitea zu durchlaufen, also beschweren Sie sich, dass Gitea nicht aktualisiert wird usw. #6961 ist a notwendigen Schritt dazu und nach der Zusammenführung ändern wir einfach https://github.com/go-gitea/gitea/blob/bf552761894dee08f734d91f5c8175cd0cb2f9f5/cmd/hook.go#L72 um die Einstellung von SSH_ORIGINAL_COMMAND zu erzwingen oder den Rest anderweitig zu erzwingen der Standardumgebung eingestellt ist.
• [ ] Wir sollten in der Lage sein, mit NO_EXEC gemounteten Repositorys zurechtzukommen - und wir sollten dies wahrscheinlich sogar empfehlen. Es ist wahrscheinlich nicht wirklich schwierig - ändern Sie einfach die Variable .git/config oder die zentrale Variable .gitconfig core.hooksPath und überlegen Sie, wo wir sonst Hooks platzieren werden.
• [ ] Wir speichern im Grunde Codezeilen direkt in der Datenbank für Kommentare - was nicht funktioniert, wenn die gespeicherten Daten nicht in UTF-8 vorliegen. Dies bedeutet, dass Sie einen Nicht-UTF8-Code einfach nicht kommentieren können.

API / SDK

• [ ] Es ist verrückt, wie viel Arbeit wir machen müssen, um eine API zu erstellen, wenn wir uns so viel Mühe geben, zu prahlen. Wir sollten dies einfach aus Prahlerei automatisch generieren oder so viel wie möglich automatisch generieren
• [ ] Wir haben keine Möglichkeit, eine feste API-Version gegen unsere Gitea-Entwicklung zu testen, daher können wir nicht sagen, wann wir bahnbrechende Änderungen vornehmen.
• [ ] Wir sollten in der Lage sein, ein automatisch generiertes API/SDK zu verwenden, um einfache Testumgebungen zu erstellen

Testen

• [ ] Derzeit führen wir unsere Unit-Tests auf TRACE-Ebene durch - dies schränkt unsere Fähigkeit ein, den Dingen einen richtigen Trace hinzuzufügen. Seit https://gitea.com/gitea/log/pulls/3 und wenn wir nach Gitea zurückportieren, können wir dies aus unserem Makefile ändern.
• [ ] Benötigen Sie mehr Unit-Tests und überlegen Sie, ob einige der Integrationstests tatsächlich Unit-Tests sind und umgekehrt. zB https://github.com/go-gitea/gitea/blob/master/integrations/download_test.go
• [ ] Wir brauchen mehr Integrationstests, die versuchen, User Stories zu durchlaufen. Das heißt - Ein Benutzer meldet sich an, macht X, dann passiert Y und Z. Es ist in Ordnung, Dinge isoliert zu testen, z. https://github.com/go-gitea/gitea/blob/master/integrations/download_test.go aber das ist nicht wirklich integriert und es fehlt das Testen, was der Benutzer erlebt. Ich sage das immer wieder, aber weitere Tests sollten so aussehen: https://github.com/go-gitea/gitea/blob/master/integrations/ssh_key_test.go und https://github.com/go-gitea/gitea/blob /master/integrations/git_test.go, die tatsächlich testen, ob ein Feature korrekt integriert wird.
• [x] Unser Testprogramm dauert zu lange - CI dauert derzeit 30-40 Minuten! Diese sollten wir parallel betreiben.
• [ ] Es gibt keine einfache Möglichkeit, Migrationstests zu erstellen.

Go-Paketarchitektur

Modelle

• [ ] code.gitea.io/gitea/models hängt von viel zu vielen Dingen ab, die aufhören müssen.
• [ ] models.x muss vernichtet werden. Es ist eine schreckliche architektonische Entscheidung.
• [ ] Bei zu vielen Modellen ist es viel zu einfach, eine Null-Zeiger-Dereferenzierung zu verursachen, weil Sie nicht wissen, in welchem ​​​​Zustand es sich befindet. Können wir hier das Typsystem von go etwas besser verwenden?
• [x] Wir sollten OwnerName einfach in die Repository-Tabelle eintragen, da wir jedes Mal, wenn wir ein Repository bekommen, den Besitzer suchen müssen. Es ist albern und Zeitverschwendung. Repositorys wechseln den Besitzer nicht sehr oft, daher sind die Kosten für die Handhabung nicht groß.
• [ ] Zu viele Dinge werden noch in Modellen gemacht und mehr sollten ausgelagert werden.
• [ ] Es kann sinnvoll sein, Modelle in Core und Non-Core aufzuteilen.

Module

• [x] Es gibt im Wesentlichen zwei Arten von Modulen: solche, die von Modellen abhängen, und solche, von denen Modelle abhängen. Trennen wir diese, man könnte Dienste nennen.

Macaron

• [ ] Ich denke, wir sollten den von @lunny vorgeschlagenen Wechsel zu Gin ernst
• [ ] Unsere Codebasis ist übersät mit Abhängigkeiten von Macaron, dies sollte nicht der Fall sein

Einstellung

• [ ] Hängt auch von Macaron ab(!)
• [ ] Ist eng mit go-ini verbunden, einer weiteren Abhängigkeit, von der wir uns abkoppeln sollten.

Internationalisierung

• [ ] EMail nicht internationalisiert
• [ ] Git-Nachrichten nicht internationalisiert
• [ ] Fehlermeldungen nicht internationalisiert
• [ ] Wir sollten das Entfernen unserer Hugo-Website-Dokumentation automatisieren, damit sie mit CrowdIn internationalisiert werden kann
• [ ] Es ist seltsam, dass wir die Sprachen mit Kleinbuchstaben haben, zB français, español in den Sprachauswahllisten - dies stellt den Anfang eines Satzes in jeder dieser Sprachen dar, daher sollten sie AFAICS groß geschrieben werden. Oui, si j'écris en français j'écris "français", mais si j'écris une liste á puces, j'écris:
  
  
  
  • Englisch
  
  
  • Französisch
  
  
  • Spanisch
  
  

Gitea Dump & Wiederherstellen

• [ ] Gitea-Dump ist beim Konvertieren zwischen SQL-Varianten kaputt
• [ ] Wir haben keinen Wiederherstellungsbefehl

Was die Benutzeroberfläche betrifft, würde ich vorschlagen, zwei Benutzeroberflächen bereitzustellen:

• ein einfaches HTML (ähnlich dem aktuellen ohne js)
• ein vollständiges JS, das nur auf API-Aufrufen angewiesen ist. Dies würde dazu zwingen, einige APIs zu überdenken, aber es wird auch mehr Interaktion von anderen externen Apps ermöglichen.

• denke, wir sollten den von @lunny vorgeschlagenen Wechsel zu Gin ernst nehmen

Ich würde Go-Chi anstelle von Gin empfehlen.

• Wir sollten das Entfernen unserer Hugo-Website-Dokumentation automatisieren, damit sie mit CrowdIn internationalisiert werden kann

IMHO sollte die Website/Dokumentation überhaupt nicht übersetzt werden, sie ist sowieso immer veraltet...

IMHO sollte die Website/Dokumentation überhaupt nicht übersetzt werden, sie ist sowieso immer veraltet...

Aber mit crowdin würde eine veraltete Version die Leute benachrichtigen und die aktuellen Übersetzungen ungültig machen.

Wäre es möglich, dem Build-Prozess geeignete Betriebssystempakete hinzuzufügen? ich

Vielleicht wären Pakete im PPA-Stil, die von den GItea-Entwicklern kontrolliert und versioniert werden, eine gute Idee, aber ich bin kein Fan von Debian-Stil "Sicherheitspatches einfrieren und zurückportieren" für die Versionierung von schnelllebigen Projekten (wie GItea).

Ich hätte immer noch gerne https://github.com/go-gitea/gitea/issues/3840.
Ich denke, es kann mit Abwärtskompatibilität implementiert werden.
Dies wird jedoch erst klar, wenn die Migration der neuen Routing-Bibliothek abgeschlossen ist.
Eine vorausgesetzte grundlegende Bereinigung/Refactoring würde es auch einfacher machen.

Ich hätte immer noch gerne #3840.
Ich denke, es kann mit Abwärtskompatibilität implementiert werden.
Dies wird jedoch erst klar, wenn die Migration der neuen Routing-Bibliothek abgeschlossen ist.
Eine vorausgesetzte grundlegende Bereinigung/Refactoring würde es auch einfacher machen.

In diesem Fall ist es möglich, dass Sie den Drohnen-Support verlieren, da dieser derzeit auch nicht für Gitlab implementiert ist.

Ich hätte immer noch gerne #3840.
Ich denke, es kann mit Abwärtskompatibilität implementiert werden.
Dies wird jedoch erst klar, wenn die Migration der neuen Routing-Bibliothek abgeschlossen ist.
Eine vorausgesetzte grundlegende Bereinigung/Refactoring würde es auch einfacher machen.

Wir brauchen diese Gruppenfunktion wahrscheinlich nicht, um die Repository-URLs zu beeinflussen. Wir könnten einfach Ordner erstellen, in denen das Repository angezeigt werden kann, aber die Repository-URLs unverändert lassen

@tboerger
Mein Gedanke war, dass die URL gleich bleiben kann, wenn ein Repository nicht in einer Gruppe/einem Verzeichnis verschachtelt ist.
Die URLs müssen nur dann "aktualisiert" werden, wenn das Repository die Gruppen-/Verzeichnisfunktion verwendet.
Aber ja, die Repos mit den neuen URLs könnten wahrscheinlich keine Drone-Unterstützung von Anfang an haben.

@lafriks
Das hört sich nach einer guten Idee an. Mein Anwendungsszenario der Funktion ist das Hosten von Git-Modulen oder den Unterprojekten von Repo-Projekten. Ich bin mir also nicht sicher, ob es diesen Fall abdeckt.

Kein Problem. Ich zögere auch, eine so umfassende und möglicherweise brechende Änderung vorzunehmen.

Dieses Thema hat viele gute Ideen und wir sollten sie behalten und ansprechen.
Aber wann und wie sollten wir wählen? Diese Diskussion kann ewig so weitergehen.

Ich würde vorschlagen, dass entweder der Eigentümer die Themen auswählt oder eine Abstimmung zwischen ihnen und den Mitgliedern findet.
Was denken Sie?

@DblK Das stimmt. Aber ich denke, wir könnten das tun, nachdem wir zu gitea.com migriert sind. Derzeit benötigen wir mehr Feedback von Benutzern.

• Mercurial-Unterstützung
• bessere Sortierung und Filterung nach PR und Themen

• Mercurial-Unterstützung

Nein, bitte. Es heißt nicht ohne Grund "git"ea.
Ich verstehe den Wunsch, einen größeren Spielraum zu haben, aber
Blähungen stehen vor der Tür...

Quecksilberimport wäre eine Alternative

Am 26. Juli 2019 13:52:50 UTC schrieb Sandro Santilli [email protected] :

• Mercurial-Unterstützung

Nein, bitte. Es heißt nicht ohne Grund "git"ea.
Ich verstehe den Wunsch, einen größeren Spielraum zu haben, aber
Blähungen stehen vor der Tür...

--
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an:
https://github.com/go-gitea/gitea/issues/6998#issuecomment -515461704

Federated Pull Requests / Issues / Forks

Vielleicht nicht föderiert im Sinne des Wortes Fediverse (ActivityPub, OStatus, Diaspora*, etc.), aber ich möchte die Möglichkeit, mit entfernten Instanzen aus den eigenen Reihen zu interagieren, so implementiert, wie es am besten zum Projekt passt.

In #1612 wird darüber bereits diskutiert. ForgeFed sammelt einige interessante Ideen, um eine Föderation in Codeschmieden wie Gitea zu bringen. Es wäre toll, wenn dies das nächste große Feature von Gitea wäre!

Ich würde mich über ein visuelles Diff-Tool für Grafikdateien (JPEG, PNG, aber auch PDF) freuen , ähnlich dem, was

Wir haben bereits eine PR, um Bilder zu unterscheiden

Wir haben bereits eine PR, um Bilder zu unterscheiden

Stimmt, aber das gilt nicht für die Vorschau von Swipe oder Zwiebelschalen, sondern nur nebeneinander. Außerdem glaube ich nicht, dass es PDF-Dateien abdeckt. Wir verwenden Gitea hier für die Entwicklung von Grafikmaterial (einschließlich Handbüchern und Broschüren), und ein guter visueller Vergleich für PDFs würde das Leben verändern.

Ich habe ein paar Ideen, die ich einfach rauswerfen möchte :smile_cat:

1. Verwenden Sie Cloud KSM, um jedes Geheimnis transparent zu verschlüsseln/entschlüsseln. Dies schützt vor gehackten und exponierten DBs. Die Idee ist, dass wir einen benutzerdefinierten Typ mit XORM-Codierungs-/Decodierungsmethoden verwenden können, um die geheimen Daten vor dem Schreiben in die DB zu verschlüsseln. Wir haben hier ein Demo-Beispiel gemacht: https://github.com/gomodules/ksm-xorm

2. OIDC-Unterstützung: Geben Sie id_token zusätzlich zum oauth2-Token zurück, wenn Sie sich über Gitea anmelden

3. Das Gitea-Benutzerprofil kann das Benutzerprofil in jedem verifizierten Git-Repository anzeigen. Beispiel: Benutzer können Github/Gitlab/BitBuket/Gitea-Repos anheften. Die Idee ist, dass Benutzer auch die anderen nicht ignorieren können. Kann gitea also das einzige globale Benutzerprofil sein?

4. Unterstützung für benutzerdefinierte Domains für Repositorys (go)

5. Volle Kompatibilität mit Github (Ich habe einige Arbeiten an dieser Front gesehen, ich weiß nicht, wie viel bereits getan wurde.)

6. Optionale Sprachserverintegration. So etwas wie Sourcegraph wie eine in die Benutzeroberfläche integrierte Navigation.

Ich möchte kurzfristig zu 1 & 2 beitragen.

Vielleicht können wir diff in Form eines Baums von Ordnern und Dateien anzeigen, die sich geändert haben - wie in BitBucket, anstelle einer riesigen Seite mit allen Änderungen darin. Es wäre viel, viel lesbarer.

Vielleicht eine Option, um Benachrichtigungen für alle Repositorys pro Tag oder pro Woche zu aggregieren.
Eine Art Zusammenfassung der Aktivitäten der letzten Wochen.

Fügen Sie die Möglichkeit hinzu, benutzerdefinierte Webhooks über benutzerdefinierte Vorlagen und einen Pool von Standardvariablen zu definieren.

Keine Gitea-Entwicklung, sondern ein nützliches Nebenprojekt: #7853

Feature-Parität mit github!

Oder zumindest eine aktuelle Liste im Wiki, die all die Features aufzeigt, die wir noch brauchen, bevor wir Parität erreichen. Dies wäre eine gute Möglichkeit, zukünftige Entwicklungsbemühungen zu strukturieren.

@lonix1 schau dir https://docs.gitea.io/en-us/comparison/ für diese Liste an

@kolaente sieht aus, als hätten wir fast alle Häkchen! Ja!

Ich bin ganz neu hier, aber auch ein williger Programmierer; Ich würde mich freuen, wenn gitea Gists unterstützt. Das ist eines der größten Löcher für meinen Gebrauch. Leicht genug gearbeitet, aber ich hätte lieber nur ein Kernsystem.

Ich denke, das Problem für Gists wäre https://github.com/go-gitea/gitea/issues/693 (Verlinkung, da hier noch nicht darauf verwiesen zu werden scheint).

Fügen Sie auch die Dokumentation Help , auf die Help Link GitHub-Hilfe mit Gitea-spezifischen Modifikationen sein.

@bagasme help kann nicht von github übernommen werden, das wäre eine Urheberrechtsverletzung. Jemand muss Gitea-Hilfe von Null schreiben

1. Anlegen von Issues per E-Mail (siehe GitLab Service Desk).

Wenn mehr Leute anfangen, sich selbst zu hosten, um ihre Open-Source-Projekte zu teilen, muss es für nicht registrierte Benutzer eine Möglichkeit geben, Probleme zu melden, ohne für jede Instanz ein Konto erstellen zu müssen (die meisten Leute werden sich kaum für einen Fehler registrieren .) Prüfbericht).

1. So etwas wie AutoDevOps von GitLab. Dies bedeutet die Möglichkeit, einen Standard-CI-Job zu definieren, wenn sich keine CI-YAML-Datei im Repository befindet.

2a. Container Registry-UI-Registerkarte und Auth.

1. Bots
2. GPG für Web-Commits
3. Möglichkeit, Zusammenführungen basierend auf Bedingungen zu blockieren
4. Möglichkeit, eine Datei in der Web-Benutzeroberfläche zu erstellen (einschließlich in einem leeren Bare-Repository)
5. An Repo angehängte Snippets über die Benutzeroberfläche verwalten (siehe GitLab)
6. Unterstützung für Git-Protokoll v2
7. Verbesserte Web-IDE-Option
8. Kubernetes-Integration (über UI-Plugin a la GitLab)
9. Fügen Sie eine Verzögerung von 400 ms hinzu, bevor ein Tooltip beim Schweben angezeigt wird
10. Bessere CI-Integration (Showpipelines, Concourse-Support usw.)
11. Benutzeroberfläche verfeinern
12. 2FA durchsetzen
13. Dateisperre
14. Verknüpfte Probleme mit PR-Zusammenführung automatisch schließen.

Eine Art Plugin / Erweiterungssystem.

Die meisten Vorschläge sind gut, aber sie verursachen Probleme in der Kerncodebasis.

Es wäre am besten, offizielle (und inoffizielle) Plugins zu haben. Dies würde auch bedeuten, dass Plugin-Autoren häufiger veröffentlichen könnten.

@lonix1 Nun, Git-Hooks, Webhooks und die Swagger-API können als Plugin-Verbindungspunkte betrachtet werden. Ich bin für mehr Plugin-Unterstützung, aber eine Liste mit Einzelheiten könnte helfen. Zum Beispiel möchte ich Unterstützung für ein Befehlszeilen-Äquivalent von Webhooks.

@guillep2k Zum Beispiel alle oben besprochenen Projektmanagementfunktionen. Diese wären sehr nützlich - aber sie berühren wahrscheinlich so viele Teile der Codebasis, dass sie 1) selbst für diejenigen Probleme verursachen könnten, die diese Funktionen nicht verwenden, und 2) deshalb ist eine solche Entwicklung sehr langsam, weil die Verantwortlichen dafür sind Beim Zusammenführen neuer Funktionen wissen sie, dass dieses Szenario möglich ist, und sind daher vorsichtig.

Wenn diese neuen Funktionen separat veröffentlicht werden könnten, könnten sie von willigen Benutzern ausprobiert werden, bevor sie in den Hauptzweig zusammengeführt werden.

Und es gibt noch andere Beispiele für diese Art von großen neuen Funktionen, scrollen Sie einfach nach oben.

@brandonkal GPG-Signieren von automatisch generierten Commits ist jetzt mit der Zusammenführung von #7631 möglich

Ich denke, die Roadmap sollte in diese vier Kategorien unterteilt werden (ich habe einige Beispielprobleme hinzugefügt – es sollte offensichtlich sein, dass sie noch lange nicht vollständig ist :wink:):

Grundfunktionalität

Es gibt noch einige _grundlegende Funktionen_, die nicht richtig funktionieren.
Zum Beispiel:

• es braucht immer noch eine gute Suchlösung, wie in Problemen wie #5694 #5277 #3448, #2967, #2434, #8366, #8386 und #7825 erwähnt
• der PDF-Viewer ist kaputt
• der SVG-Viewer ist kaputt
• es scheint, dass nicht-freie Abhängigkeiten verwendet werden

Sicherheit

Es gibt auch einige Sicherheitsprobleme:

• [ ] [das Docker-Image läuft immer noch als root](https://github.com/go-gitea/gitea/issues/1190), obwohl die Docker-Anleitung sehr klar ist und es keinen Grund gibt, die root Benutzer (Sie können die Ports sowieso von außen neu zuordnen)
• [ ] [Erzwingen von 2FA ist immer noch nicht möglich](https://github.com/go-gitea/gitea/issues/880)
• [ ] [Aktivieren Sie die Einstellung strengerer CSP-Header, indem Sie Inline-Stile entfernen](https://github.com/go-gitea/gitea/issues/305)
• [ ] [es wird nicht geprüft, ob jemand auf Anhänge zugreifen darf](https://github.com/go-gitea/gitea/issues/7908)

Integration

Ich denke, die Integration mit anderen Anwendungen/Diensten ist im Allgemeinen eine gute Sache.
Denn Softwareentwicklung verlässt sich in der Regel nicht nur auf ein einziges Tool.
Und es wird wahrscheinlich helfen, einige Leute davon zu überzeugen, Gitea an ihrem Arbeitsplatz zu verwenden.

Diese beiden Probleme würden die Interoperabilität erheblich verbessern:

• [ ] integriert automatisch Drone CI/CD ( wie @BNolet zuvor vorgeschlagen )
• [ ] [API-Integration für automatisierte PR-Reviews](https://github.com/go-gitea/gitea/issues/5733) durch Tools wie Pronto
• [ ] [einfache Integration mit einer Container Registry](https://github.com/go-gitea/gitea/issues/2316)
• [ ] eine generische Webhook-Lösung, mit der Benutzer einfach benutzerdefinierte Webhooks einrichten können ( wie zuvor von @bkcsoft vorgeschlagen )

Auch generische Webhooks würden es vermeiden, dass andere Leute die Interna von gitea kennen. @guillep2k hatte eine wunderbare Idee, dass eine "externe Befehls"-Integration ähnlich der generischen Webhook-Integration durchgeführt werden könnte .
:warning: Dies würde wahrscheinlich die meisten Probleme bei dem lösen, was die meisten Leute in dieser Ausgabe als 'Plugin-Unterstützung' wünschen . Denn das würde es ermöglichen, alles anzurufen, was Benutzer anrufen müssen. @lunny hat jedoch gerade erwähnt, dass dies praktisch bereits über Git-Hooks möglich ist. Ich bin mir nur nicht ganz sicher, ob dies wirklich der beste Weg ist, andere Tools/Plugins/Dienste zu integrieren.

On-Top-Features

Darüber hinaus gibt es offensichtlich einige nette Features in konkurrierenden Anwendungen (zB Git[Hub/Lab]) (die meisten davon sind wahrscheinlich ziemlich nett zu haben):

• [ ] [PRs zurücksetzen](https://github.com/go-gitea/gitea/issues/6375)
• [ ] [Verbessertes Diff für nicht-textuelle Dinge, wie von @arthur-bauer erwähnt](https://github.com/go-gitea/gitea/issues/6998#issuecomment-516325459)
• [ ] [Bearbeitungen von Betreuern](https://github.com/go-gitea/gitea/issues/717)
• [ ] [Vertrauliche Themen](https://github.com/go-gitea/gitea/issues/3217)
• [ ] Weitere Repository-Details anzeigen (dh Repository-Größe , Mitwirkender-Grafik , Sprachenleiste )
• [ ] einige Wiki-Verbesserungen (#823 #574)
• [ ] [mit einem Diff wie BitBucket, wie von @SignumPL erwähnt](https://github.com/go-gitea/gitea/issues/6998#issuecomment-517151615) (das wusste ich vorher nicht, aber es sieht in der Tat nützlich aus )
• [ ] [Integrieren Sie eine Funktionalität wie Octotree](https://github.com/go-gitea/gitea/issues/3045#issuecomment-546233388)

Kann Oracle Database als Option verwendet werden? Wenn es technisch möglich ist.

@DemiusAcademius Wenn xorm Orakel besser unterstützt, denke ich, dass das möglich ist.

Immer mehr Menschen beginnen Gitea zu nutzen, zB auch bedingt durch die jüngste Ankündigung des GitLab-Trackers. Aber GitHub/GitLab haben immer noch den Netzwerkeffekt auf ihrer Seite.

Die Föderation wäre ein wichtiger Treiber, um die Zusammenarbeit zwischen Benutzern verschiedener Gitea-Instanzen zu verbessern und dadurch das gesamte Gitea-Netzwerk zu vergrößern: #1612

Es wurde berichtet, dass die Möglichkeit, große Unterschiede in der Benutzeroberfläche anzuzeigen, ein limitierender Faktor bei der Einführung von Gitea war.
Tickets, die es adressieren: #7341 (Feature), #7495 (Crasher-Bug)

Es wurde berichtet, dass die Möglichkeit, große Unterschiede in der Benutzeroberfläche anzuzeigen, ein limitierender Faktor bei der Einführung von Gitea war.
Tickets, die es adressieren: #7341 (Feature), #7495 (Crasher-Bug)

Das ist eine _enorme_ Einschränkung. IMO alles, was @alexanderadam oben aufgelistet hat, verblasst im Vergleich dazu. Wenn ich große Unterschiede nicht überprüfen kann, indem ich Inline im Code kommentiere, ist das ein großes Problem.

W/R/T die Wut auf Microsoft und Github, die viele Projekte zur Migration veranlasste und eine hohe Nachfrage nach Föderationen verursachte – Gitlab hat kürzlich vorgeschlagen, Mitarbeiter in China und Russland zu verbieten, zwei der weltweit größten Länder nach Landmasse und Wirtschaft. Das US-Militär hat den Fokus (unter anderem) auf China und Russland verlagert, um die Barrieren zu schwächen, die sie für die imperiale Expansion/Interessen der USA darstellen. Propaganda und finanzielle Anreize haben Microsoft (Github, Azure), Amazon, Google, Atlassian (Trello, Jira) und sogar Gitlab in eine offensive Rolle in die Industrien Krieg, Spionage, Propaganda und Überwachung gebracht.

Ich erwähne dies, um mich bei denen zu bedanken, die an hochverfügbaren Open-Source-Remote-Repositorys mit wenigen Mängeln zu den Unternehmens- und Pentagon-verknüpften Diensten arbeiten, die wir jetzt verwenden und auf die wir uns immer noch verlassen – und um Sie darauf aufmerksam zu machen, dass schnell Alternativen verfügbar sind verschwinden für diejenigen, die das Internet und die Technologie so weit weg vom mächtigsten und feindseligsten Imperium der Geschichte nutzen möchten.

Vielleicht ist das Thema groß genug für einen separaten Abschnitt der offiziellen Website, um den Fortschritt bei dieser Funktion zu verfolgen, zusammen mit einer separaten Spendenkampagne, um diese Nachfrage zu erfassen. Die Einbeziehung von ForgeFed in das Fundraising kann vorteilhaft und fair sein, wenn man ihre bisherige Arbeit betrachtet. Es ist auf den Tag genau 17 Monate her, dass Microsoft mit Github umgegangen ist, und ich hoffe, dass wir in weiteren 17 Monaten Gitea im Verbund nutzen oder die restlichen Teile des Nettovermögens darauf aufbauen können.

Bitte hier nicht über Politik diskutieren, bleiben wir beim Thema - Gitea für alle verbessern

@lafriks Gitea zu verbessern bedeutet, eine Nische zu definieren – etwas, das von Ersatzprodukten nicht abgedeckt wird. Marketing ist der Prozess der Suche nach externen Möglichkeiten, wobei "politisch" eine von 4 Hauptkategorien der Marketinganalyse ist. Eine kluge Marke spricht die _Werte_ der Menschen gleichermaßen an, wie sie Funktionen, Spezifikationen und Preise bietet. Alternativen wie Gitea haben eine wertebasierte ("politische") Anziehungskraft, und wenn Sie dies nicht unterstreichen und beibehalten, würden Sie Ihren Verbraucher und die Marktchancen nicht verstehen.

Der Begriff "Politisch" ist zu einem gedankenbeendenden Klischee geworden, das die Diskussion um Rassismus, Gewalt und Ausbeutung auslöscht. Ich bin nur hierher gekommen, um den Leuten für die kontinuierliche Arbeit an Alternativen zu danken, die nichts mit US-Konzentrationslagern, Schleppnetzüberwachung und anderen imperialistischen Interessen zu tun haben, denen die Mehrheit unserer Industrie aktiv hilft. Wenn Sie sagen, dass dies keine Qualitäten sind, zu denen Gitea steht, Ich habe dich falsch verstanden und ich werde gehen.

Hinweis an @OKNoah

Marketing 101 für ein Open-Source-Projekt:

1. Keine Konzentrationslager ansprechen
2. Erwähne keine Politik
3. Verliere den Alufolienhut
4. Verwenden Sie keine antiken Begriffe wie Imperialismus
5. Kennen Sie die Vorteile Ihres Produkts. Der Vorteil von Gitea ist seine Einfachheit.

Wenn Sie die Transparenz von GitLab.com beleidigen, können Sie GitLab-FOSS selbst hosten. Es ist ein sehr gutes All-in-One-Produkt. Wenn Sie jedoch eine einfache Installation wünschen oder im Vergleich zu GitLab oder GitHub Enterprise einen geringeren Speicherverbrauch benötigen, ist Gitea eine gute Option für die grundlegenden Webfunktionen.

In diesem Thread geht es darum, Funktionen zu diskutieren, die dazu beitragen können, diese Lücke zu schließen, ohne die Einfachheit zu beeinträchtigen.

Meine 2 Cent - ich denke, dieser Thread ist zu lang geworden, und es ist an der Zeit, eine neue Ausgabe zu eröffnen, in der alle hier bereits geäußerten Ideen zusammengefasst werden. Und schließe diesen.

Wenn Sie sagen, dass dies keine Qualitäten sind, zu denen Gitea steht, ich habe Sie falsch verstanden und werde gehen.

Dies ist nicht das, was gesagt wird. Was gesagt wird, ist, dass dieser Thread der Ort ist, um zu diskutieren, welche Änderungen/Verbesserungen an Gitea vorgenommen werden können (insbesondere technische). Diese Diskussionen sind mehr als willkommen, aber nicht in diesem speziellen Thread.

Als einer der Leads werde ich diesen Thread sperren, wie @XVilka es richtig gesagt hat, wir haben viel Feedback

Wir könnten den Pfad zur FHS-Compliance für v2 ändern. Mit Flags ist dies bereits möglich, sollte aber der Standard für v2 sein.