Ändern einer Open Source-Anwendung

Was ist der allgemeine Workflow, wenn ich einer Open Source-Anwendung, die ich ursprünglich nicht geschrieben habe, eine Funktion hinzufügen möchte? Wie lerne ich den Code kennen? Wie finde ich die Stelle, die geändert oder hinzugefügt werden muss? Wie kann ich die Änderung tatsächlich vornehmen, ohne etwas anderes zu beschädigen? Wie teste ich, dass noch alles funktioniert?
Was sind die allgemeinen Richtlinien für ein solches Projekt?

open-source

— Dani
quelle

Sie sollten Ihre Änderungen auch an das Projekt senden , normalerweise als Patch, damit andere davon profitieren können.

Es gibt ein Protokoll, das jeder mit der Zeit mehr oder weniger wünscht, aber hier ist es, ausgerollt.

Sie laden die verteilte Quelle herunter.
Sie beginnen ein wenig selbst im Code zu navigieren
- Wenn es sich um ein kompiliertes Programm handelt, lernen Sie jetzt, wie Sie es kompilieren.
- Wenn Sie es nicht kompilieren können, melden Sie sich beim Autor / der Mailingliste und fragen nach dem Weg
Wenn Sie etwas über den Code nicht wirklich verstehen ...
- Nun, nein, Sie nicht fragen sie nahe.
- Sie lassen das fallen, da Sie wahrscheinlich nicht auf dem neuesten Stand sind und keine wirkliche Hilfe sein können.
- Sie senden eine Funktion, wenn der / die Autor (en) Funktionsanforderungen akzeptiert.
Sonst
- Sie finden den Ort, den Sie ändern möchten.
- Wenn Sie sich über kleinere Details wundern, fragen Sie den Autor / die Mailingliste und erläutern Ihre Absichten.
- Sie wechseln in das Hauptverzeichnis der Distribution (das oberste, das aus dem Entpacken / Entpacken stammt).
- Du diff -ur . > mypatch.path
- Sie senden mypatch.patchdem Autor eine Erklärung, was Sie getan haben, warum Sie es getan haben, und (da Sie bereits dort sind) geben Sie deutlich an, dass Sie auf die Rechte an dem Patch verzichten.
wenn der / die Autor (en) Ihren Beitrag nicht mögen
- Sie überprüfen, ob es eine Möglichkeit gibt, Ihre Änderung als Plugin freizugeben
  - In diesem Fall sind Sie jetzt auf dem Weg, ein Plugin-Mantainer zu werden .
- sonst
  - Sie flammen über die Situation in Ihrem Blog und veröffentlichen dort den Patch, den Sie kostenlos herunterladen und mit Ihrer Erklärung und Ihren Beschimpfungen ausprobieren können.
  - Sie verfolgen ab und zu das Fehlersystem / die Mailingliste, um Unterstützung für Ihren Patch zu kaufen. Vermeiden Sie es, gebannt zu werden.
- In keinem dieser Fälle geben Sie den Code auf , da es sich um einen sehr anstrengenden und unbelohnenden Prozess handelt, mit dem Sie kaum Schritt halten können. Dadurch werden die Benutzer traurig und verwirrt. Gabeln sollten wirklich nur passieren, wenn ein großes Unternehmen versucht, seine Entscheidungen über ein Stück OSS zu schikanieren .
sonst
- Sie erhalten weitere Anweisungen von diesen Autoren.

Nebenbei : Es gibt eine neue Alternative zum diff -ur .Patch und ist der Github-Weg .

Sie "gabeln" ihren Code auf Github unter Ihrem Namen
(jetzt haben Sie eine Kopie ihres Codes auf Ihrem Konto)
Verbinde deinen Git mit deiner persönlichen Kopie.
Nehmen Sie Ihre Änderungen daran vor, checken Sie sie ein,
und fordern Sie den / die Hauptautor (en) auf, sich Ihr Github-Projekt anzusehen.
Wenn sie es mögen, werden sie synchronisieren .
Andernfalls können Sie Ihre "Gitfork" in Ihrem Blog verlinken.

— ZJR
quelle

Alles gut, bis Sie vorschlagen, dass das OP die Produktautoren in Flammen setzt, weil sie den neuen Feature-Patch nicht angenommen haben. Es ist unklar, ob dies lustig oder ernst sein sollte. So oder so, es ist SEHR schlechte Form, effektiv wie ein kleines Kind in die ganze Welt zu weinen, weil Ein Produktteam mag / möchte Ihren neuen Feature-Patch nicht. Veröffentlichen Sie es auf jeden Fall, aber seien Sie immer großmütig, wenn es nicht akzeptiert wurde, unabhängig davon, wie unlogisch die Entscheidung zu sein scheint. -1 - Zu Ihrer Information, ich werde meine Stimme gerne umkehren, wenn Sie das entfernen.

— ocodo

Die Anwendung, die ich ändern möchte, folgt einem strengen Standard, der mit meinen Änderungen gegen den Standard verstößt. Ich glaube, ich bin nicht einmal in der Lage, die Anwendung meines Patches zu beantragen.

— Dani

@Slomojo OSS ist voll von unreifen Menschen, und so etwas passiert die ganze Zeit. Jeder sollte bereit sein, wie ein Maultier zu arbeiten, und dann auf der Grundlage abgelehnt werden, die manchmal solide und manchmal streitig sind . Und dann haben Sie zumindest immer die Möglichkeit, darüber zu schimpfen und Leute zu finden, die das Gefühl haben, dass Sie vielleicht Recht haben. Nun, der trotz drauflegen , das wäre die falsche und sehr kiddish Schritt.

— ZJR

@Dani lol, du musst dem Share wirklich einen Patch nehmen und darüber schimpfen . Vermeiden Sie Gabeln, da dies Ihr Leben verschlingt. Es fühlt sich an, als würden Sie ohne Gehaltsscheck kontinuierlich umgestalten. ... wie auch immer, überprüfen Sie anhand der Mailingliste und des Fehlerberichtssystems, ob es eines gibt, ob sich jemand für eine solche Erweiterung interessiert, vielleicht sind Sie nicht allein. Aaaund das Beste wäre, dass sie eine API zum Erweitern oder ein Plugin-Ding zum Einfügen Ihrer Änderungen hatten. Das ist in solchen Fällen immer die beste Option: ein Plugin zu pflegen . ... wird das in bearbeiten.

— ZJR

Wenn es automatisierte Testfälle gibt, führen Sie diese aus, bevor Sie den Patch senden.

— Oenone

Typischerweise.

Wenn es sich um ein zufälliges Betriebssystemprojekt handelt, würden Sie höchstwahrscheinlich hier und da kleinere Fehler beheben.

Schließlich würden Sie eine Reihe von Änderungen als "Patch" einreichen.

Normalerweise würden Sie Commit-Rechte erhalten, wenn Ihre Sachen gut sind.

Ich spreche allgemein und aufgrund der Frage so vage und unspezifisch wie möglich

— MattyD
quelle