Patch Writer’s Guide

Hier sind einige Tipps von Matz, wie Sie Ihre Patches zur Berücksichtigung erhalten.

Diese Richtlinien wurden von einem Beitrag von Matz auf der Ruby-Core-Mailingliste übernommen.

• Ein Änderungsantrag pro Patch

  Dies ist das größte Problem bei den meisten zurückgestellten Patches. Wenn Sie einen Patch einreichen, der mehrere Fehler behebt (und Funktionen hinzufügt) gleichzeitig, müssen wir diese trennen, bevor wir ihn anwenden. Das ist eine ziemlich schwierige Aufgabe für uns beschäftigte Entwickler, daher werden diese Art von Patches tendenziell zurückgestellt. Keine großen Patches bitte.

• Beschreibungen bereitstellen

  Manchmal beschreibt ein bloßer Patch nicht ausreichend das Problem, das er behebt. Eine bessere Beschreibung (das behobene Problem, Vorbedingungen, Plattform usw.) würde helfen, dass ein Patch früher übernommen wird.

• Diff zum neuesten Revision

  Ihr Problem könnte in der neuesten Revision behoben worden sein. Oder der Code könnte inzwischen völlig anders sein. Bevor Sie einen Patch einreichen, versuchen Sie bitte, die neueste Version (den trunk-Branch für die neueste Entwicklungsversion, ruby_2_6 für 2.6) aus dem Subversion-Repository abzurufen.

• Verwenden Sie diff -u

  Wir bevorzugen diff -u Style Unified Diff Patches gegenüber diff -c oder anderen Patch-Stilen. Sie sind viel einfacher zu überprüfen. Senden Sie keine modifizierten Dateien, wir möchten keinen eigenen Diff erstellen.

• Testfälle bereitstellen (optional)

  Ein Patch, der Testfälle bereitstellt (vorzugsweise ein Patch für test/*/test_*.rb), würde uns helfen, den Patch und Ihre Absicht zu verstehen.

Wir könnten in Zukunft zu einem Git-ähnlichen Push/Pull-Workflow übergehen. Aber bis dahin würden die Befolgung der oben genannten Richtlinien Ihnen helfen, Frustration zu vermeiden.