Wer sich intensiver mit TYPO3 beschäftigt wird sicher auch eines Tages in die Situation kommen, auf einen Fehler in TYPO3 zu treffen (was nicht heißt, dass es da viele von gibt *hüstel*).
Der Bugtracker sollte dem erfahrenen Admin bekannt sein und das Einstellen eines (ausführlichen!) Reports obligatorisch, sofern er noch nicht gemeldet ist.
Nicht nur dann, wenn der Bug einen selbst blockiert, sondern auch da TYPO3 ein Open-Source-Projekt ist, welches von seiner Community lebt, ist das Finden der Fehlerursache sowie deren Beseitigung der nächste logische Schritt. Gut.. nichts wie ab in den Bugtracker mit dem Fix!
Okay.. für die meisten Leser bisher Standard nehme ich an! Den nächsten Schritt möchte ich nun erläutern: Das Senden des Patches an die Core-Liste, was die Wahrscheinlichkeit der Aufnahme in den TYPO3-Core deutlich steigert.
Auch wenn der Artikel sich im Folgenden mehr wie ein „tue-dies, tue-das, tua-DAS-bloß-nicht!, …“ liest und am Anfang die Einhaltung der Gepflogenheiten etwas schwer fällt, so finde ich doch, dass es sich nicht nur deswegen lohnt, um dem ganzen Projekt etwas für die damit erreichten Erfolge (Geld/Ruhm/Ehre/…) zurückzugeben – es gibt einem in der täglichen Anwendung doch immer wieder ein gutes Gefühl, sich an bestimmten Stellen in TYPO3 denken zu können „wie schön, was ich da vor langer Zeit mal gemacht habe“ und die gesamte TYPO3-Community von der eigenen Arbeit profitieren kann.
Was ist die Core-Liste?
Die TYPO3-Core-Liste typo3-team-core (bzw. die Newsgroup typo3.teams.core) ist der zentrale Ort für alle Patches, die von den TYPO3-Core-Entwicklern in das Subversion-Repository eingepflegt werden. Bis vor einiger Zeit war diese Liste vor der Öffentlichkeit verborgen – durch die Öffnung kann mittlerweile jeder eigene Patches an die Liste senden und für Patches voten.
Im Gegensatz zu den restlichen Listen herrschen etwas strengere Regeln:
- Keine allgemeinen Diskussionen beginnen, sondern nur Requests For Comments (RFCs), die einen Patch enthalten.
- über RFCs darf diskutiert werden
- nach Review des RFCs wird gevotet: „+1“ signalisiert das OK des Einzelnen, -1 sowie gar Vetos sind weniger üblich und sollten genauer überlegt werden 😉
- zur Aufnahme ins SVN wird mindestens das „+1 by reading and testing“ eines Core-Entwicklers (außer dem Autor des RFC) sowie eines weiteren (beliebigen) Entwicklers benötigt.
Wie sieht ein RFC aus?
Damit eine einheitliche Form eingehalten wird, ist das Format für die RFCs wie folgt festgelegt:
This is an SVN patch request.
Type: [Bugfix / New feature / Code cleanup]
Bugtracker references:
[Anklickbarer Link zum Bugtracker, z.B. http://bugs.typo3.org/view.php?id=12987]Branches:
[SVN branches, in die der Patch deiner Meinung nach eingepflegt werden soll. „4-3, trunk“ würde hierbei auf die aktuelle stabile Version (4.3) sowie die momentane Entwicklungsversion (trunk, später 4.4) abzielen.]Problem:
[kurze, aber zur Nachvollziehung des Problems ausreichende Fehlerbeschreibung]Solution:
[Beschreibung deiner Lösung]Notes:
[Optional weitere Hinweise, z.B. detaillierte Anleitung zur Fehlerreproduktion][Gruß & Tschüss]
Als Sprache wird natürlich Englisch erwartet. Der Betreff der Mail hat wie folgt auszusehen:
RFC #[Bug-Nummer ohne führende Nullen]: [Bug / Feature / Code cleanup]: [Bug-Titel]
Deinen Patch musst du an die Mail anhängen und zwar möglichst so, dass er von deinem Mailprogramm/Newswriter Inline und nicht als Attachment gesendet wird (Dateiname [Bug-Nummer].diff sollte helfen).
Nach dem Absenden heißt es nun erst einmal Abwarten auf Reaktionen. Verbesserungsvorschläge sollten von dir in den Patch eingearbeitet werden und als neue Version ([Bug-Nummer]_v2.diff) gesendet werden.
Zur Dokumentation, dass der Patch an die Core-Liste gesendet wurde, solltest du dann dem Bugtracker-Eintrag das Tag „pending in core list“ hinzufügen.
Was muss ich beim Patch beachten?
Das folgt im morgigen Türchen… 🙂
