Wessen Verantwortung ist ein Bugfix-Patch?

Eine Situation, die in Open-Source-Projekten mehrfach aufgetreten ist, sieht folgendermaßen aus:

1. Ich stelle einen Fehler in unserer Bereitstellung fest und finde einen schnellen Hack-Patch heraus. (Zum Beispiel einfach Code auskommentieren, den wir eigentlich nicht brauchen.)
2. Ich wende ein wenig zusätzlichen Aufwand auf, um den wirklichen Fehler herauszufinden, einen Patch zu entwickeln und ihn über eine Git-Pull-Anfrage oder ähnliches einzureichen.
3. Meine Pull-Anfrage wird abgelehnt. Vielleicht war der Patch unvollkommen (z. B. eingeschlossene Linien, die er nicht haben sollte), vielleicht verstieß er gegen den Codierungsstil, vielleicht hatte er andere Konsequenzen. Oder vielleicht habe ich in Git etwas falsch gemacht - die Pull-Anfrage hätte umbasiert werden müssen oder so. Ein Betreuer gibt Feedback zur Verbesserung des Patches und fordert mich auf, ihn erneut einzureichen.

An dieser Stelle bin ich verwirrt, wie weit ich gehen soll. Ich habe kein Problem: Ich habe es bereits in Schritt 1 behoben. Ich habe das Problem gemeldet und sogar Schritte unternommen, um es für andere zu beheben. Ich habe jedoch nicht das Gefühl, dass dies "meine" Pull-Anfrage ist, und bin daher nicht der Meinung, dass die Verantwortung für die Verbesserung des Patches bei mir liegen sollte.

Eine besondere Situation, die mich ärgert, ist, dass wir uns nach der Diskussion über die Fehler meines Patches auf eine Mailingliste einigen, wie der richtige Patch aussehen soll (dh wie er sich verhalten soll, manchmal einschließlich der einzelnen Codezeilen). Dann liegt es vermutlich immer noch in meiner Verantwortung, den Patch tatsächlich zu generieren und einzureichen.

Gibt es in diesen Situationen eine Standardetikette? Wie werden sie gelöst? Ist meine Reaktion ungewöhnlich? Wie weit werden Sie voraussichtlich gehen, um Ihre Fehlerbehebung zu akzeptieren?

(Beachten Sie, wenn ich "Open Source-Projekt" sage, dass einige davon sehr klein sind, aber keine Hobbys sind - einfach kleine Softwareprojekte, die für mehrere Organisationen von Nutzen sind, die Entwicklerressourcen für die Bearbeitung dieser Projekte einsetzen. Falls die offensichtliche Antwort lautet Ist "Patch reparieren und erneut einreichen", muss ich verstehen, dass ich meinem Arbeitgeber die Verantwortung übertragen muss, an Dingen zu arbeiten, die für ihn von Vorteil sind. Es wäre falsch, Zeit damit zu verbringen, einen Fehler zu beheben, der uns nicht betrifft ...)

Was mich betrifft, sind Sie fertig, wenn Sie einen Fehler finden oder eine Verbesserungsanforderung haben, keinen Beitrag zum Projekt leisten und einen Fehlerbericht über die entsprechenden Kanäle eingereicht haben. Jeder, der ein Open-Source-Projekt nutzt und einen Defekt feststellt, sollte dies melden, um der Community etwas zurückzugeben.

Der Versuch, eine Lösung zu finden, sie zu entwerfen und umzusetzen, ist ein Bonus für das Projekt. Wenn Sie dies getan haben, ist es möglicherweise eine gute Idee, es entweder über eine Pull-Anforderung oder durch Senden von Dateideltas zusammen mit dem Fehlerbericht oder der Erweiterungsanforderung an das Entwicklungsteam zu senden, um ihnen etwas zur Bearbeitung zu geben. Sie sind jedoch nicht verpflichtet, Ihren Beitrag zum Projekt anzunehmen.

Es scheint mir falsch zu sein, dass ein Benutzer Patches beisteuert. Es ist ziemlich einfach, an einer Diskussion über ein Problem teilzunehmen, aber die Zeit, um eine Lösung zu finden, ist viel länger. Kein Projekt sollte erwarten, dass Nicht-Mitwirkende Mitwirkende werden, nur um ein einzelnes Problem zu beheben.

Fahren Sie so weit fort, wie Sie bereit sind, es zu ertragen. Es wäre schön, Ihren Patch zu reparieren und mit der Welt im Hauptkoffer zu teilen, aber wenn der Betreuer es nicht will, zucken Sie die Achseln. Sie können irgendwo Ihr Problem und den Patch, mit dem es behandelt werden soll, posten, damit andere im selben Boot nach einer Lösung suchen können.

Und du bist nicht ohne Problem. Ihr Patch wird nicht im nächsten Upgrade enthalten sein. Sie müssen also nacharbeiten und hoffen, dass es funktioniert, oder es einmassieren, wenn Sie eine neue Version kaufen. Wenn Sie es also in das Hauptprojekt aufnehmen, sparen Sie und Ihr Unternehmen auf lange Sicht Zeit.

Es ist ein Schmerz für dich, aber du leistest einen Beitrag zur Gemeinschaft. Ich schätze auf jeden Fall alle Beiträge, die zur Arbeit beigetragen haben. Es ist nicht so, als ob Qualitätssoftware nur magische Genesis aus der Masse wäre. Jemand muss die Arbeit machen. (Also, wer ist super? Du bist super). Wenn Sie sich nicht dafür interessieren, teilen Sie der Community mit, dass Sie, obwohl Sie die Diskussion darüber zu schätzen wissen, wie es sein sollte, einfach zu beschäftigt sind, um dies zu tun. Ich meine, was werden sie tun? Löhne kürzen?

Es gibt einen Grundsatz, der das Verständnis der Open Source-Kultur erleichtert: Die Person, die die Arbeit ausführt, entscheidet, woran sie arbeitet. Dies ist einer der Anziehungspunkte im Vergleich zu Entwicklerjobs. Ihre oberste Priorität ist möglicherweise die Nummer 50 im Auftragsbestand. Wenn Sie Ihre Pull-Anfrage nicht korrigieren, wird sie möglicherweise nach oben rinnen und sie werden sich darum kümmern. Wenn Sie es ihnen jedoch einfach genug machen, werden sie sich jetzt darum kümmern.

Der andere Grund, warum Sie gebeten werden, Ihre Pull-Anfrage zu korrigieren, ist großmütiger. Sie möchten, dass Sie Ihren Beitrag gutschreiben, so gering er auch sein mag. Wenn Sie die Korrektur durchführen, ist Ihr Name der Name im Feld author des Commits. Die meisten Menschen sind stolz genug auf ihren Beitrag, um ihn durchstehen zu wollen. Deshalb ist es die Standardeinstellung der Betreuer, ihn zuzulassen.

Wenn sich Ihr Unternehmen auf diesen Kodex verlässt, tun Sie Ihrem Arbeitgeber gegenüber keinen schlechten Dienst. Arbeitgeber kennen den Nutzen eines Arbeiters, der sich Zeit nimmt, seine Werkzeuge zu schärfen.

AFAIK, der Open-Source-Weg ist, dass die Verantwortung für die Behebung von Fehlern demjenigen überlassen bleibt, der sich genug um den Fehler kümmert, um die Last zu bewältigen und sicherzustellen, dass er behoben wird. Abhängig von den Umständen habe ich alles getan, angefangen beim Ignorieren eines Problems bis hin zum Kampf (Bereitstellen von Patches und Argumentieren, damit sie akzeptiert werden), um sicherzustellen, dass es behoben wurde.

Alles ist in Ordnung. Lassen Sie nur nicht zu, dass die Leute, die das Projekt leiten, das Falsche von Ihnen erwarten (dh hoffen Sie, dass Sie das Problem durch Diskussionsoptionen richtig beheben und dann nichts unternehmen). Sie sind sich wahrscheinlich mehr Probleme bewusst als sie können sich selbst behandeln und werden versuchen, einen wiederkehrenden Beitrag von Ihnen zu machen, wenn sie können.

Der ursprüngliche Fehler wirkt sich möglicherweise nur auf Sie aus, daher liegt es sehr in Ihrem Interesse, die Einreichung zu veranlassen, indem Sie alles tun, was erforderlich ist, um Ihren Patch in Übereinstimmung zu bringen. Andernfalls wird Ihre Korrektur in der nächsten Version, die Sie herunterladen (da Sie andere Korrekturen benötigen), fehlen.

Sie möchten nicht jedes Mal, wenn Sie eine neue Kopie des Projekts herunterladen, eine Liste der Patches erstellen, die Sie anwenden müssen - es ist einfach zu viel Mühe. Nehmen Sie sich etwas Zeit und reparieren Sie es dauerhaft, damit Sie sich nicht erneut darum kümmern müssen.

Für einen Open Source-Entwickler gibt es zwei Arten von Problemen:

• (a) Probleme ohne Patch
• (b) Probleme, die durch ein Patch verursacht wurden

Ich denke, die meisten Open-Source-Paketbetreuer / -Entwickler LIEBEN die Idee, einen Nicht-Core-Entwickler mit ihren Patches auf den neuesten Stand zu bringen.

Ihr primäres Ziel ist es jedoch, die Anzahl der Typ-B-Probleme zu minimieren. Deshalb liegt die Messlatte ziemlich hoch.

Einige Leute überwinden es. Sie werden zu Mitwirkenden oder vielleicht sogar zu zentralen Mitwirkenden. Andere geben auf. Open Source hat eine gewisse darwinistische Natur - das Überleben der Stärksten.

Ich ermutige Sie, Ihren Beitrag so weit voranzutreiben, dass das Team ihn akzeptiert. Sobald Sie ein paar Beiträge geleistet haben, werden sie Ihnen weiter vertrauen, aber Sie sollten trotzdem sicherstellen, dass Ihre Beiträge einwandfrei sind.

Das Endergebnis ist es absolut wert. Dinge wie sagen zu können "Muss ich codieren? Ja ... Sie führen jeden Tag etwas aus, das ich geschrieben habe."