Öffentliches Contenido-Git-Repository

[Drizzt]

Nachdem ich Contenido nun schon eine Weile für verschiedene Projekte nutze und für nahezu jedes Projekt auch einige (zusätzliche) Änderungen habe, hatte ich Contenido schon eine ganze Zeit in einem privaten SVN-Repository untergebracht. Und immer gehofft es gäbe mal ein offizielles und öffentliches VCS, gegen das ich meine Änderungen verwalten kann bzw. aus dem ich mir schon mal ein Bugfix herauspicken kann, bevor eine neue Version veröffentlicht wird. Da das bis heute nicht geschehen ist, habe ich mich nun dazu entschlossen einfach ein Git-Repository aufzusetzen und es für jeden (lesend) zugänglich zu machen. Ich würde mich freuen, wenn Reporter von bekannten Bugs (mit Patches) oder Modul-Autoren oder wer sonst Änderungen am Code von Contenido vorgenommen hat und meint, dass die wichtig für alle sind, mir diese Änderungen zum Einpflegen ins öffentliche Repository zukommen lassen könnte. Git macht das einfach, weil ich damit von anderen Git-Repositories genauso leicht Patches importieren kann, wie aus E-Mails. Das hätte für alle den (meiner Ansicht nach) großen Vorteil, dass man schnell auf bekannte Fehler reagieren kann und man ein öffentliches VCS hat, an dem Änderungen übersichtlicher nachzuvollziehen sind, als hier im Forum.

Jetzt allerdings eine wichtige Anmerkung: ich will hier keinen Fork/Branch von Contenido aufmachen, sondern das Repository als „staging area“ für die nächste offizielle Version verstanden wissen (evtl. können ja auch die Entwickler der four for business AG direkt auf das Repository zugreifen und sich gewünschte Änderungen herauspicken um diese einfach in ihr VCS einzupflegen (noch besser wäre natürlich, wenn es ein offizielles und öffentliches VCS gäbe)). Das heißt, abgesehen von Modulen, die entweder in eigenen Repositories oder zumindest in eigenen Branches verwaltet werden, möchte ich mich nur auf Bug-Fixes und Code Clean-ups konzentrieren.

So, jetzt aber zu den wichtigen Informationen:

• Wo finde ich das Repository? Das Repository ist via Webinterface unter http://gitweb.carbon-project.org/contenido.git erreichbar. Wer lieber eine lokale Arbeitskopie möchte, führt

  Code: Alles auswählen

  git clone git://git.carbon-project.org/contenido.git

  im Verzeichnis seiner Wahl aus.
• Wie kommt der Code ins Repository? Entweder indem ich eine E-Mail bekomme (vorzugsweise mittels git format-patch formatiert/erstellt, aber „normale“ diffs (bitte

  Code: Alles auswählen

   diff -Nau

  verwenden (bei mehreren Dateien noch ein -r hinzufügen) und darauf achten, dass Patches aus dem Hauptverzeichnis mit

  Code: Alles auswählen

  patch -p1

  anwendbar sind) gehen natürlich auch) oder indem ich einen git-pull-Request bekomme. Alle Patches/Pull-Requests sollten Informationen zum Bug enthalten und was sie ändern. Eine URL hier zum Forum zum Thread indem der Bug berichtet wurde, wäre erwünscht.
• Kann ich auch Schreibzugriff auf das Repository erhalten? Ja, sobald ich sehe, dass von jemandem gute Patches kommen, bin ich gerne bereit für denjenigen ein Repository einzurichten bzw. Zugriff auf's Hauptrepository zu geben.
• Du hast was von vielen eigenen Änderungen erzählt, die sehe ich aber gar nicht im Repository, wo sind die? Die sind im nicht-öffentlichen Teil und haben für die Allgemeinheit nichts mit dieser Idee zu tun. Die Änderungen sind meist Erweiterungen für bestimmte Projekte und sehr spezifisch (und deshalb eher uninteressant für Andere).

Ich würde mich über eure Meinungen zu diesem Vorschlag freuen, noch mehr würde ich mich natürlich über Patches freuen!

Grüße,
Kai

[thepoet]

Eine gute Idee und etwas das ich, hätte ich etwa mehr Freizeit zur Verfügung, selbst schon angegangen wäre. Nur ein Wunsch: bitte die Commits so atomar wie möglich halten.

Eine Anregung die mir beim Lesen der email-Validator-Diskussion durch den Kopf gegangen ist: Ich könnte mir gut vorstellen, in die git-Version einen Deprecation Path einzubauen, so dass man die Wahl hat zwischen der "alten", 100% abwärtskompatiblen Codebasis, und PHP5.3/6-Syntax und -Sprachumfang.

-Christian

[Drizzt]

Das mit den atomaren Patches kommt mir grundsätzlich sehr gelegen. Und da ich immer einen Upstream-Branch habe, kann man (hoffentlich) mit wenig Aufwand immer nur die Patches in einen eigenen (lokalen) Arbeits-Branch ziehen, die man möchte. Zum E-Mail-Validator: der sollte nichts verwenden, was nicht auch schon in 5.2 ist und 5.2 ist in Debian Stable. Damit sollten eigentlich die meisten Installationen abgedeckt sein bzw. auf neuerem Stand. Und da die alte Validierungsfunktion eher vom Typ „lieber gar nicht verwenden“ war (die hat zu viele korrekte Adressen ausgefiltert), die neue hingegen grundsätzlich mehr korrekte Adresse abdeckt, sollte es von der Komaptibilität kein Problem sein. Sonst, wie immer: Patches are welcome.

Grüße,
Kai