TYPOlight - ein Ein-Mann-Team??

[Matze-Katze]

Hey,

bin jetzt schon nen guten Monat dabei und hab mich mittlerweile in TYPOlight eingearbeitet. Ich bin ziemlich begeistert von diesem CMS, das ich nach wochenlangem durchforsten von Erfahrungsberichten, Online-Demos, Foren etc. fand.
Ich bin jetzt mit einer Website auf TL 2.7.6 umgezogen. Sie ist aber noch nicht online, da ich noch darauf warten möchte, bis TL 2.8 rauskommt.

Das bringt mich zum eigentlichen Anliegen:
Ich sehe, da ich dort auch selbst aktiv bin, dass es eine rege Beteilung der Community beim Ticketsystem gibt.
Typolight ist ein super CMS, aber es gibt trotzdem noch erheblichen Bedarf an Verbesserungen, Features und an Bugfixing.

Da ich, wie ich bereits gesagt habe, auf die TL 2.8er Version warte, schau ich immer mal wieder in die Roadmap, um zu gucken, wie viele Tickets noch bearbeitet werden müssen.
Das sind schon seit ca. 2 Wochen um die 10 Stück. Manchmal werden es weniger, dann kommen wieder ein paar dazu. Es geht also nur sehr schleppend voran.
Ich kann mir vorstellen, dass das bei einer Person (Leo), die nach der offiziellen TL-Website am Core arbeitet und die auch im Ticketsystem alles beantwortet, kein Wunder ist.

Nun frage ich mich, warum das Team nicht durch ein paar Programmierer erweitert wird?
Das würde die Entwicklung von TL beschleunigen, die User glücklicher machen, da ihre Anliegen im Ticketsystem tausendmal schneller bearbeitet werden (ich sehe, dass für die nächste Version (TL 2.8) Tickets abgeschlossen wurden, die teilweise schon vor mehr als einem Jahr erstellt wurden) und damit auch den Bekanntheitsgrad, die Usability, und alles andere auch verbessern!

Ich denke, dass Weiterentwicklung absolut wichtig ist. Wenn ein User nicht das Gefühlt hat, dass es voran geht und angesprochene Probleme (z.B. im Ticketsystem) erst nach einem Jahr in einer neuen TL Version bearbeitet werden, führt das dazu, dass sich der User abwendet.

Ich würd mich über eure Meinung zu dem Thema freuen.

[Toflar]

Heikles Thema und eindeutige Antwort.

Die überlasse ich aber gerne Leo, falls er auf das Thema stösst

Was allgemeines zum Ticketsystem - das gilt übrigens für jedes Ticketsystem bei jeder Applikation: Wenn 3 Monate nichts an den Tickets geschieht, heisst das nicht, es wird nicht weiterentwickelt. Plötzlich sind mehrere Tickets auf einmal erledigt. Schau dir z.B. mal Mootools an, dort ist die 1.3 sogar für heute angesetzt...das interessiert eigentlich niemanden

Die 2.8 wurde fürs 1Q 2010 angekündigt und wird somit auch pünktlich erscheinen. Das hat alles seine Richtigkeit und das Tempo ist überhaupt nicht schleppend sondern im Gegenteil, sehr schnell

[Sarvo]

bei der Updategeschwindigkeit kann man sich wirklich nicht beschweren. Ging mir sogar öfter mal zu schnell .

Ein weiterer Punkt den auch andere schon angesprochen haben ist einfach, viele Köche verderben oft den Brei.
Leo arbeitet alleine am Core und er kennt sein System. Deswegen ist das System bis jetzt auch so sicher und sauber programmiert.

Und bei der Sicherheitslücke, die Leo immerhin selbst erkannt hat!, kannst du sehen wie schnell die Reaktionszeiten eigentlich sind.

[david enke]

Das kann man nur bejaen, falls man ein Ticket erstellt ist die Beantwortung durch Leo 'erschreckend' schnell.

Man bedenke außerdem im Vergleich mal die lange eigenständige Entwicklung der Linux-Core durch Linus Torvalds...

[Thomas]

Das Negativbeispiel währe Windows, wo viele für viele Fehler sorgen.

[xchs]

Ich denke auch, dass sich Leo in dieser Hinsicht redlich bemüht. Schau Dir nur mal die Anzahl der Tickets an, welche in der neuen Version 2.8 umgesetzt werden. Das wird wahrscheinlich die Version mit den bislang meisten Tickets sein, wobei ein Großteil davon aus Feature Requests der Benutzer besteht.

[david enke]

Das Negativbeispiel währe Windows, wo viele für viele Fehler sorgen.

Im Gegenzug ist allerdings auch die durch Innovation und Teamwork geprägte Erweiterung des Unix-Cores durch Apple zu nennen...
Wobei ja nun offenkundig das Entwicklungsbudget dabei eine weittragende Rolle spielt. Dieses Beispiel funktioniert also auch nur für kommerzielle Entwicklungen, nicht jedoch für Open-Source Entwicklungen.

[Toflar]

Ausserdem posten so viele Entwickler irgendwelche Patches (die zwar nicht immer angenommen werden), dass es, für den Moment zumindest, für mich noch stimmt

Manchmal dürfte Leo ruhig ein bisschen mehr "Ja" sagen, aber naja...hätte er zu allem "Ja" gesagt, wären wir heute nicht bei dem TL, das wir alle lieben, sondern eher bei einem überladenen Typo3.

Von daher... Just my two cents

[Matze-Katze]

Ein weiterer Punkt den auch andere schon angesprochen haben ist einfach, viele Köche verderben oft den Brei.
Leo arbeitet alleine am Core und er kennt sein System. Deswegen ist das System bis jetzt auch so sicher und sauber programmiert.

Das kann man genauso gut umdrehen und ist damit kein Argument:
"4 Augen sehen mehr als 2..." etc.

Das kann man nur bejaen, falls man ein Ticket erstellt ist die Beantwortung durch Leo 'erschreckend' schnell.

Ja, die Beantwortung vielleicht. Das ändert aber trotzdem nichts an der Tatsache, dass es Tickets gibt, die nach 500 Tagen noch nicht in einer Version untergebracht wurden.

ch denke auch, dass sich Leo in dieser Hinsicht redlich bemüht.

Na klar bemüht der sich! Das bezweifelt hier keiner und ich frag mich jetzt schon, wie er das zeitlich alles hinkriegt. Aber ich fände es weitaus sinnvoller, wenn mehrere an der Entwicklung arbeiten würden. Die Gründe dafür habe ich im Anfangspost dargelegt...

[Nils Riel]

Ihr argumentiert sehr allgemein - was genau geht euch denn zu langsam? Wichtige Dinge sind doch immer im Nu erledigt. Klar ist natürlich, dass dadurch Feature Requests langsamer von statten gehen.

Was ich positiv finde: Oft wird die Lösung eines Problems schon im Ticket selbst gepostet - auch wenn es erst mit der nächsten Version behoben wird.

[david enke]

also grundlegend ist dein gedanke gut, aber der mehraufwand bei open-source projekten liegt erfahrungsgemäß an der organisation und kommunikation der leute untereinander, was ein schwerwiegendes gegenargument wäre.
zudem erzeugt die dezentrale entwicklung häufig qualitätsprobleme, ein kontrol-und kommunikationsorgan zur überwachung wäre nötig.

die späte umsetzung von tickets erklärt sich aber häufig auch durch deren relevanz, 500 tage sind für kleinkram, oder irrelevante änderungen oder feature-requests nicht unbedingt ungerechtfertigt. im gegenzug wandern wichtige features oder änderungen sehr schnell ins releasesystem.

[leo]

Das ändert aber trotzdem nichts an der Tatsache, dass es Tickets gibt, die nach 500 Tagen noch nicht in einer Version untergebracht wurden.

Es wird irgendwann auch Tickets geben, die nach 1000 Tagen in keiner Version untergebracht worden sind, weil einfach nicht alle Ideen ins Konzept passen und nicht jeder Wunsch umgesetzt werden muss. Vieles sind gute Ideen, die ich deswegen offen lasse, weil sie vielleicht für das nächste Major-Update passen könnten.

Du solltest die Arbeiten vielleicht eher danach bemessen, was gemacht wird und nicht danach, was nicht gemacht wird. Ein Blick ins Entwicklerhandbuch wäre fürs Verständnis des Entwicklungsprozesses sicherlich auch hilfreich:

https://contao.org/typolight-entwicklungsprozess.html

Wenn Du trotz allem weiterhin der Meinung bist, dass es nur auf Quantität und schnelle Bearbeitung ohne Hinterfragen des Sinns ankommt, empfehle ich Dir ein anderes CMS. Beschwer Dich dann aber bitte nicht, dass Joomla, Wordpress und Konsorten so viele Sicherheitslücken und Fehler enthalten

[leo]

Da ich, wie ich bereits gesagt habe, auf die TL 2.8er Version warte, schau ich immer mal wieder in die Roadmap, um zu gucken, wie viele Tickets noch bearbeitet werden müssen.
Das sind schon seit ca. 2 Wochen um die 10 Stück. Manchmal werden es weniger, dann kommen wieder ein paar dazu. Es geht also nur sehr schleppend voran.

Übrigens richtet sich die Veröffentlichung nicht danach, ob alle Tickets bearbeitet wurden oder nicht, sondern folgt einem bestimmten Konzept. TYPOlight besteht ja nicht nur aus dem Core, sondern auch aus über 300 Erweiterungen und über 30 Übersetzungen, die möglichst auch mit dem Erscheinen des finalen Release lauffähig sein sollten.

Das Projekt befindet sich also so oder so eine gewisse Zeit in der RC-Phase, damit alle Entwickler und Übersetzer die Möglichkeit haben, ihre Übersetzungen bzw. Erweiterungen anzupassen. Natürlich könnte ich auch einfach alle Tickets bearbeiten und dann die neue Version veröffentlichen, aber das wäre sowohl den Entwicklern gegenüber als auch den Nutzern, deren Erweiterungen nach dem Update auf einmal nicht mehr laufen würden, ziemlich unfair.

Deswegen besteht während der RC-Phase - aber auch generell! - keinerlei Veranlassung, sich unüberlegt durch die Tickets zu hasten, nur um möglichst schnell eine neue Version zu veröffentlichen. Das wäre äußerst unprofessionell und zum Glück haben das auch die meisten Entwickler verstanden - egal ob im Open Source- oder im kommerziellen Bereich.

[weke]

Da kann ich Leo nur zustimmen (ja ich),

was passiert, wenn ein Update schnell "rausgeprügelt" wird, konnte ich aktuell am Firefox 3.6 erleben.
Beim Versuch das Update einzuspielen wurden 5 Add-ons deaktiviert, da nicht Kompatibel. Super sag ich da nur...

So langsam trudeln die Updates ein und das ein oder andere Add-on läuft wieder.

Finde Leo macht das gut so und darf auch mal genervt auf einige Tickets reagieren

[Acta]

Wo der Leo recht hat , hat er recht.

Das gute an der ein Mann arbeit ist, das Fehler wenn Sie enstanden sind nur von Ihm sein können. Demzufolge sollte er auch einfach wissen wo und wie er etwas ändert. D.h. er behält die Übersicht.

Das Leo bei all der Arbeit nicht immer der netteste ist, ist auch Verständlich.

Aber eins kann ich sagen. Im Realive (Usertreffen Frankfurt) war er sau nett!

[Matze-Katze]

Wenn Du trotz allem weiterhin der Meinung bist, dass es nur auf Quantität und schnelle Bearbeitung ohne Hinterfragen des Sinns ankommt, empfehle ich Dir ein anderes CMS. Beschwer Dich dann aber bitte nicht, dass Joomla, Wordpress und Konsorten so viele Sicherheitslücken und Fehler enthalten

Ich habe nie gesagt, dass ich dafür bin, auf Quantität statt auf Qualität zu achten!
Ich habe lediglich darauf hingewiesen, dass ich es wichtig finde, dass die User merken, dass es voran geht und ihre Probleme und Feature-Anfragen, wenn sie denn akzeptiert werden, auch bearbeitet werden.

Ich habe aber noch keine rationalen Bedenken gegenüber meinem Vorschlag gehört, das Programmierteam zu erweitern...

Das gute an der ein Mann arbeit ist, das Fehler wenn Sie enstanden sind nur von Ihm sein können. Demzufolge sollte er auch einfach wissen wo und wie er etwas ändert. D.h. er behält die Übersicht.

Das ist ebenfalls kein gutes Argument. Denn gerade weil die Fehler von ihm sind, kann es schnell dazu kommen, dass er das übersieht. Ist wie beim Schreiben von Texten. Wenn man bei dem eigenen Text auf Fehlersuche geht, findet man meist nicht viele. Jemand der gegenliest ist da meist erfolgreicher.

[Sarvo]

Das ist ebenfalls kein gutes Argument. Denn gerade weil die Fehler von ihm sind, kann es schnell dazu kommen, dass er das übersieht. Ist wie beim Schreiben von Texten. Wenn man bei dem eigenen Text auf Fehlersuche geht, findet man meist nicht viele. Jemand der gegenliest ist da meist erfolgreicher.

Du siehst aber, wie es in der Realität aussieht. Das System ist sehr sicher und sauber, dagegen kann man nichts sagen.
Es gibt in der Community außerdem auch noch ambitionierte Entwickler die den abgelieferten Code im Auge haben und dann sicherlich Leo Rückmeldung geben falls ihnen was aufgefallen ist.

Wie Leo es auch gesagt hat, fakt ist doch es FUNKTIONIERT so bestens ! Bei den anderen CMS, bei denen die Politik anders ist, siehst du ja was du dann dafür bekommst.

Ich verstehe ehrlich gesagt, dein Anliegen nicht mehr so wirklich

[Matze-Katze]

Du siehst aber, wie es in der Realität aussieht. Das System ist sehr sicher und sauber, dagegen kann man nichts sagen.
Es gibt in der Community außerdem auch noch ambitionierte Entwickler die den abgelieferten Code im Auge haben und dann sicherlich Leo Rückmeldung geben falls ihnen was aufgefallen ist.

Wie Leo es auch gesagt hat, fakt ist doch es FUNKTIONIERT so bestens ! Bei den anderen CMS, bei denen die Politik anders ist, siehst du ja was du dann dafür bekommst.

Ich verstehe ehrlich gesagt, dein Anliegen nicht mehr so wirklich

Ich hab keine Ahnung, wie sicher und sauber das programmiert ist. Ich wette, dass 90% der Leute, die TL nutzen, sich nicht in den Core eingelesen haben und nicht mit Überzeugung sagen können, dass es keine Sicherheitslücken gibt.

In dem Fall ist man wohl, es sei denn, man ist selber "Hacker", Programmierer oder was weiß ich für einer und weiß, wie man Sicherheitslücken ausfindig macht - das dürften wohl die wenigsten können - dazu veranlasst, Leo zu vertrauen bzw. darauf zu hoffen, dass es keine Lücken oder keine Angreifer gibt.

Es geht mir aber hier auch gar nicht vorrangig um die Sicherheit.

Ich versteh nicht, warum keiner mein Anliegen kapiert. Es steht doch klar und deutlich im Startpost geschrieben.

Ich würde mir wünschen, dass das "Programmierteam" durch kompetente engagierte Programmierer erweitert wird. Dazu möchte ich eure Meinung hören. Argumente dafür, habe ich im Laufe dieses Themas erläutert.

Was Leo dann im Endeffekt macht, ist noch mal was anderes. Ist ja sein CMS.
Aber warum nicht diskutieren...?

[Toflar]

Weil das Programmierteam ja da ist. Oder von wem stammen all die Erweiterungen und Veränderungsvorschläge im Ticketsystem für den Core?

[Matze-Katze]

?!
Mit Programmierteam meine ich Leute, die an der Bearbeitung von den Tickets und an sonstigen Erweiterungen/Problemen etc. etc. vom Core (und damit nicht noch so ne Frage auftaucht: natürlich auch an allen anderen Erweiterungen, die im Moment von Leo gepflegt werden) arbeiten...

[xtra]

So, nun gebe ich auch mal meinen Senf ab. Einige hier wissen ja, dass ich auch gerne mal auf Kollisionskurs gehe und in der Vergangenheit auch ordentlich an Missstaenden gemeckert habe.
Ich finde jedoch, die Entwicklung von TL geht nun definitiv in die richtige Richtung und es ist sehr viel passiert.
Fryher gab es beispielsweise keinen offenen SVN Server, wo man sich den trunk ansehen konnte (siehe hierzu auch die damalige, teilweise recht hitzige Diskussion). Dieser ist nun vorhanden und das Mehraugenprinzip schlaegt voll zu. Etliche Tickets resultieren bereits hieraus und wir betrachten jeden change mit wachsamen Augen und teilweise diskutieren wir features im tracker bis das Optimum erreicht ist.
Auch ist die Kommunikation gegenyber der Community einiges besser geworden (achtung, subjektives Empfinden). Dies litt vermutlich aber hauptsaechlich daran, dass Leo sein Buch geschrieben hat (was fyr einen Entwickler mitunter die ungeliebteste Taetigkeit ist) und das redesign der Homepage abschliessen musste.

Weiterhin reichen immer mehr Entwickler patches ein, welche Leo dann bewertet und ggf. in den Core ybernimmt (analog: Linux Kernel - Linus bekommt nur die patches vorgelegt, die von anderen bewertet wurden und sieht selbst auch nochmal dryber).
Genau so verhaelt es sich mit TYPOlight auch.
Leo ist zwar derjenige, der vorne an steht, aber auch der, der den Kopf hin haelt wenn was schief laeuft. Aber er hat auch viele Entwickler um sich, die ihn unterstytzen.
Und nicht zuletzt sollte man den Grundsatz von TYPOlight nicht vergessen. es ist "light". Fyr den einen zu light, fyr mich nicht light genug. Leo ist derjenige, der in der Mitte sitzt und versucht einen Konsens herzustellen und die Entscheidungen trifft.
Vieles gehoert nicht in den Core sondern in eine Extension.
Daher sind auch einige Tickets richtig alt, da sie einen interessanten Ansatz verfolgen, der noch nicht ausgereift ist, aber nicht in Vergessenheit geraten soll.

Schlussendlich kann man mit TYPOlight viel machen ohne in den core einzugreifen. Fyr alles andere requested man einen HOOK, welcher sofern man einen patch beilegt meist auch gerne implementiert wird.
2.8 ist meines Wissens nach die Version in der seit langem die meissten HOOKs hinzukommen.
Von daher, es gibt in sofern schon quasi ein "Team" von Entwicklern, jedoch treten die nicht offiziell in Erscheinung sondern sind im ER und so weiter vertreten. Weiterhin finden auch hier immer mehr schoene Diskussionen yber die Entwicklung statt.

Wir sind auf dem richtigen Wege.

Chris

[leo]

Auch bei den anderen großen Open Source CMS arbeitet meistens nur einer auf einmal am Core (Linux ist das beste Beispiel), selbst wenn 5.000 Entwickler am eigentlichen Projekt mitarbeiten. Das bedeutet nicht, dass deswegen mehr oder weniger Fehler gemacht werden. Aber wir haben einige fähige Entwickler in der Community, die kritisch beäugen, was sich im SVN so tut, und eventuelle Fehler sofort erkennen und zurückmelden. Diese "Qualitätskontrolle" funktioniert seit der Umstellung des SVN sogar noch besser.

Und selbst wenn all das nicht so wäre: Wir haben uns für TYPOlight für diesen Weg entschieden und damit bisher gute Erfahrungen gemacht. Insofern erübrigt sich jede weitere Diskussion.

[Acta]

Das kann man doch als letzen Satz stehen lassen.


- Amen -

[matze]

Im Großen und Ganzen kann ich den Herrn Katze schon verstehen:
Es gibt nicht umsonst Prinzipien wie das "Extreme Programming" bei dem immer 2 Entwickler an einem Code sitzen. So etwas ähnliches hat ja Microsoft auch eingeführt mit dem Ergebnis, dass Windows 7 in Punkto Sicherheit ganz oben auf der Liste steht.
Bei anderen Herstellern krankt das genau an diesem Punkt. Da sei mal nur Apple genannt, die ewig brauchen bis sie mal was gefixt haben oder ganz schlimm Adobe die mit ihren Produkten eigentlich die größten Löcher in die Betriebssysteme reißen. Aber auch genau dort wird darüber nachgedacht ein System wie bei MS einzuführen.
Denn, das ist auch erwiesen, mehrer Leute sehen gerade auch beim Programmieren die meisten Fehler.

Mit Aussagen wie: "Typolight ist sehr sicher" wäre ich mal vorsichtig. TL ist (leider) nicht nicht wirklich großartig populär. Also mal verglichen mit z.B. Wordpress. Von daher ist es auch noch nicht im Fokus der bösen Hacker.
Nichts desto trotz halte ich persönlich (mein "Feeling") TL für recht sicher. Alleine weil ich mich auch schon mal grob durch den Core gekämpft habe :-)

Das System krankt meiner Meinung nach ein bisschen an anderer Stelle: Und zwar genau da wo es immer krankt. An den Drittprodukten.
Die meisten Sicherheitslücken kommen unter Windows von Anwendungsprogrammen (Adobe usw). Die meisten Lücken bei Typo3 werden durch die Erweiterungen aufgerissen.
Und da sollte man auch meiner Meinung nach bei TL ansetzen. Mein Vorschlag wäre:
Ähnlich wie bei Wikipedia gibt es "stabile Versionen". Das bedeutet: Über eine Extension haben 5 Revisoren drübergeschaut und von den 5 haben mindestens 60% ihr OK gegeben. Damit wäre dann der aktuelle Status der Erweiterung als geprüft freigegeben. (die Zahlen sind jetzt einfach nur mal aus dem Bauch geschossen)
Damit das funktioniert sollte man einen Umfangreichen Kriterienkatalog erstellen anhand dessen sich ausmachen lässt, ob eine Erweiterung gut ist oder nicht. Vielleicht könnte man dann einen solchen Kriterienkatalog dann auch mal als interaktive, automatische Prüfung online stellen...

Nur eine Idee.

[Matze-Katze]

Ich weiß nicht, warum die Diskussion jetzt zum Thema Sicherheit abdriftet. Das war gar nicht mein Hauptanliegen.
Ich meinte, dass mit mehreren Programmieren die Entwicklung schneller und effizienter vorangeht. Dass dabei die Sicherheit durch mehrere Leute, die den Code auf Fehler überprüfen, gesteigert wird, ist für mich selbstverständlich (sofern es sich denn um kompetente Leute handelt).

Übrigens: Die Diskussion mit dem Argument abbrechen zu wollen, es ging bis jetzt einigermaßen gut, klingt für mich nicht sehr fortschrittlich und konservativ.
Offen für neues sein ist im Internet das A und O.

[Toflar]

Zum Thema Extension-Reviewing haben wir uns schon viele, viele Gedanken gemacht.

Ich hab sogar grafische gif-Tags lokal auf meinem Comp liegen, die man irgendwann mal verwenden könnte

Braucht alles Zeit, die wir nicht haben

[leo]

Ich meinte, dass mit mehreren Programmieren die Entwicklung schneller und effizienter vorangeht.

Du willst es nicht verstehen, oder? Während der RC-Phase ist es vollkomen egal, wie langsam oder schnell die Entwicklung voranschreitet, weil in jedem Fall eine bestimmte Anzahl Wochen gewartet wird, damit andere Entwickler und Übersetzer eine Chance haben, ihre Arbeit fertigzustellen. Selbst wenn ich alle Tickets heute bearbeiten würde, die finale Version kommt deswegen nicht früher!

Es geht hier generell nicht um Geschwindigkeit, sondern um Qualität.

[xtra]

Zum Thema Extension-Reviewing haben wir uns schon viele, viele Gedanken gemacht.
Ich hab sogar grafische gif-Tags lokal auf meinem Comp liegen, die man irgendwann mal verwenden könnte
Braucht alles Zeit, die wir nicht haben

Und ich hab einen Teil des zugehoerigen codes in meiner Schublade, aber wie du schon sagtest die Zeit fehlt.
Das alles machen wir ohne Bezahlung in unserer Freizeit, daher geht es eben schleppend voran.

Die extensions werden so schon kaum bewertet, also braeuchte man ein QS-Team. Die Frage wieviele Lust und Zeit hierfyr aufbringen stelle ich lieber mal nicht. Ebenso spendet kaum einer fyr die Extensions die er einsetzt.
Ich sehe momentan kaum Probleme im Entwicklungsprozess von TYPOlight sondern vielmehr darin, was die Nutzer von diesem, kostenlos zur Verfygung gestellten System alles erwarten. Alles soll moeglich sein, am Besten gestern und kosten darf es logischerweise auch nix. Da spricht grundsaetzlich nichts gegen, wenn jedoch die Leute dann auch noch darauf bestehen dass man ihre Probleme loest, dann wird es eng und man verliert doch ein wenig die Lust noch was bereit zu stellen und einzubringen.
Aber nun gerate ich komplett ins Offtopic... (hoffentlich krieg ich die Kurve noch).

Abgesehen davon hat matze vollkommen recht, die Extensions sind das Problemkind in der Entwicklung von TYPOlight. Nicht Leo, welcher eine problematische extension kurz nach unseren Hinweisen offline genommen hat. Reaktionszeit: 56 Minuten. Mehr kann man nicht verlangen.

Die Geschwindigkeit der Implementierung von Features ist IMO auch vollkommen in Ordnung. Minitickets wie Anpassungen von styling und aehnlichem sind innerhalb eines Tages fertig. Groessere Changes passen, wie Leo schon schrieb, oftmals einfach nicht ins Konzept des aktuellen Releases.

Zuryck zum letzten Post des OT .

Ich meinte, dass mit mehreren Programmieren die Entwicklung schneller und effizienter vorangeht.

Das mangelt nicht daran, dass die Leute nicht im "Team" sind, sondern hoechstens, dass sich keiner um die tickets kymmert.
wie ich oben schon schrieb, ich stelle bei tickets patches bei, welche sich Leo dann ansieht und ggf. ybernimmt. Sorg dafyr dass das mehrere machen und es ist allen geholfen. Einen commit Zugang braucht es hierzu nicht.

Übrigens: Die Diskussion mit dem Argument abbrechen zu wollen, es ging bis jetzt einigermaßen gut, klingt für mich nicht sehr fortschrittlich und konservativ.
Offen für neues sein ist im Internet das A und O.

Im Allgemeinen stimme ich dir hier zu. Jedoch nicht in diesem Kontext. Denn wie gesagt steht es jedem frei, die Dinge selbst in die Hand zu nehmen. Lediglich ein direkter (Schreib-)Zugriff auf den offiziellen Code und die Garantie dass etwas ybernommen wird ist nicht gegeben.

Aus diesem Grunde habe ich auch meine eigene Version vom core vorliegen, an welchem ich experimetiere und sobald ich etwas ausgetestet habe, im tracker vorlege. Das ist ein weiterer Vorteil von OSS, jeder kann branchen und seine changes dann wieder zuryckfliessen lassen.

Gruss
Chris (der mit dem Status quo momentan zufrieden ist).

[matze]

Sag mal, spinnt mein Firefox oder schreibst du immer ein Y statt einem Ü?

[Matze-Katze]

Du willst es nicht verstehen, oder? Während der RC-Phase ist es vollkomen egal, wie langsam oder schnell die Entwicklung voranschreitet, weil in jedem Fall eine bestimmte Anzahl Wochen gewartet wird, damit andere Entwickler und Übersetzer eine Chance haben, ihre Arbeit fertigzustellen. Selbst wenn ich alle Tickets heute bearbeiten würde, die finale Version kommt deswegen nicht früher!

Erwähnte ich irgendwo die RC-Phase?!
Und selbst in der RC-Phase ist es von Vorteil, schneller fertig zu sein. Dann hat man Zeit um sich um anderes zu kümmern...

Es geht hier generell nicht um Geschwindigkeit, sondern um Qualität.

Falsch! Es geht um beides! Das eine bedingt das andere, wenn man möchte, dass das Produkt bekannt und beliebt wird.
Man kann gerne das qualitativ hochwertigste Produkt entwickeln. Es wird nichts bringen, wenn man dafür 10 Jahre brauch.

[Nina]

@Matze-Katze: Ich sage es dir ganz direkt: Du kannst hier sicher deine Meinung äußern, dass du mehr Core-Entwickler besser fändest, aber es wird definitiv nicht geschehen. Typolight war von Anfang an ein Ein-Core-Dev-Projekt und es wurde von Leo schon immer klar gesagt, dass sich daran nichts ändern wird. Weshalb sollte es das auch? Es funktioniert so seit vielen Jahren sehr gut und das Projekt kommt in sehr gutem Tempo voran. Wir sind übrigens mit dem Tempo wie der Bekanntheitsgrad von TL steigt, sehr zufrieden.

Du bist neu hier. Weshalb denkst du, dass du in der kurzen Zeit alle bisherigen Entwicklungsstadien sowie den Entwicklungszyklus und die Entscheidungen des TYPOlight-Teams verstehst und wir wegen deiner Meinung ein seit Jahren sehr gut funktionierendes System umschmeißen sollten? Um es nochmal eindeutig zu sagen: TYPOlight wird nie mehr als einen Core-Entwickler haben. Das steht schon seit dem ersten TL-Entwicklungstag fest.

Um es mal aus meiner Erfahrung zu sagen: Ich bin mit dem Entwicklungsablauf und der -geschwindigkeit hochzufrieden. Ich nutze es aktiv für meine Kunden und wurde bisher nie davon enttäuscht.

[Matze-Katze]

@Nina:
Ein Open-Source-CMS wie dieses basiert auf Rückmeldungen zwischen Entwicklern und Nutzern. Beide bedingen sich gegenseitig. Ohne Entwickler hätten die Nutzer kein CMS mehr. Ohne die Nutzer ist das CMS des Entwicklers wert-/sinnlos.
Warum ihr auf meine Meinung eingehen solltet (zumindest das und gegebenenfalls auch gegenargumentieren) ist ganz einfach:
Weil ich ein Teil der Community bin - ein Teil dessen, wovon der Erfolg des CMS abhängt, ein Teil derer, die Bugs und Features vorschlagen.

Wenn der Entwickler nicht auf Wünsche der Community eingeht, wird diese gegenseitige Beziehung gestört. Das trägt nicht gerade zum Erfolg des Projekts bei.

Neu in einem Forum sagt rein gar nichts über diese Person aus.

Ich denke nicht, dass ich etwas von den Entwicklungsstadien sowie den Entwicklungszyklen und die Entscheidungen des TYPOlight-Teams wissen muss, um hier einen Vorschlag einzubringen, den ich begründet habe und bis jetzt noch nicht rational und anders als "wird immer so bleiben und basta" widerlegt wurde.
Ich sage auch nirgendswo, dass alles umgeschmissen werden soll?!
Ich rede von Verbesserungen in Quantität UND Qualität, die dem TL-Projekt zu mehr Nutzern verhilft und kann nicht verstehen, warum hier so ein grundlegender Tenor dagegen herrscht.

Ich finde es echt schade, wenn man sich ohne Argumente abzuwägen/auf diese einzugehen auf eine Meinung festlegt.

[Toflar]

Sag mal, spinnt mein Firefox oder schreibst du immer ein Y statt einem Ü?

Sein Markenzeichen - alles i.O mit deinem FF

@Matze-Katze: Ich finde du solltest erst mal ein bisschen abwarten und schauen, wie das mit dem System läuft. Du hast sehr Recht, was deine Ansicht betr. Beziehung Entwickler<->Community angeht, aber wie du siehst, spricht sich ein Grossteil der Community für die aktuelle Vorgehensweise aus.

Das spricht doch dafür, dass alle zufrieden sind, so wie's aktuell läuft?

Ausserdem sind wir doch auf deine Argumente eingegangen. Du sagst, du möchtest ein grösseres Entwicklerteam und legst deine Argumente auf den Tisch und in den vorherigen Beiträgen finden sich x Gegenargumente.
Ich weiss halt nicht, nach was genau du Ausschau hälst

[matze]

Kurze Werbung für mein Thema an der Stelle an alle, die sich mit PHP auskennen und Erweiterungen schreiben. Auch in Anlehnung was ich weiter oben geschrieben habe.
Qualität von Extensions messbar machen

[Matze-Katze]

Okay hier mal die "Gegenargumente", die ich als solche erkannt habe:

Ein weiterer Punkt den auch andere schon angesprochen haben ist einfach, viele Köche verderben oft den Brei.
Leo arbeitet alleine am Core und er kennt sein System. Deswegen ist das System bis jetzt auch so sicher und sauber programmiert.

brauch ich glaub ich nix zu sagen...

Das Negativbeispiel währe Windows, wo viele für viele Fehler sorgen.

also grundlegend ist dein gedanke gut, aber der mehraufwand bei open-source projekten liegt erfahrungsgemäß an der organisation und kommunikation der leute untereinander, was ein schwerwiegendes gegenargument wäre.
zudem erzeugt die dezentrale entwicklung häufig qualitätsprobleme, ein kontrol-und kommunikationsorgan zur überwachung wäre nötig.

Dass man die Programmierer instruiert und sich auf ein Verfahren einigt ist logisch. Ich denke, dass das Ergebnis mehr Zeit spart, als es Zeit kostet, einen Neuen einzuweisen.

Das gute an der ein Mann arbeit ist, das Fehler wenn Sie enstanden sind nur von Ihm sein können. Demzufolge sollte er auch einfach wissen wo und wie er etwas ändert. D.h. er behält die Übersicht.

Hab ich auch schon irgendwo erläutert, dass das Unsinn ist...

Auch bei den anderen großen Open Source CMS arbeitet meistens nur einer auf einmal am Core (Linux ist das beste Beispiel)

Superargument

Und selbst wenn all das nicht so wäre: Wir haben uns für TYPOlight für diesen Weg entschieden und damit bisher gute Erfahrungen gemacht. Insofern erübrigt sich jede weitere Diskussion.

Basta!

Es geht hier generell nicht um Geschwindigkeit, sondern um Qualität.

na dann...

Um es nochmal eindeutig zu sagen: TYPOlight wird nie mehr als einen Core-Entwickler haben. Das steht schon seit dem ersten TL-Entwicklungstag fest.

Basta²

[leo]

Leider haben wir inzwischen die Ebene der sachlichen Diskussion verlassen, daher schließe ich das Thema.