Seite 1 von 2

Verfasst: Dienstag 24. April 2007, 09:16
von jens
jens hat geschrieben:Da es nur acht Leute gibt, die committen, wundert mich es allerdings nicht, das es Patches gibt, die es noch nicht ins SVN geschafft haben...
Um es noch mal aufzufrischen. Ich denke schon, das django, als Projekt, da ein Problem hat... z.Z. warten 45 Patches darauf eingecheckt zu werden: http://code.djangoproject.com/query?sta ... or+checkin

Das ist eine ganze Menge. Und all diese Tickets sind eigentlich fertig zum einchecken, zumindest ist stage="Ready for checkin" markiert worden.

In der devel-Mailingliste gibt's auch wieder eine kleine Diskussion darüber: http://groups.google.de/group/django-de ... 606385479e

Dadurch das django so populär ist, gibt es viel was die Community will und sie bieten auch die Hilfe an. Zumindest werden viele Patches eingereicht. Aber die Projekt-Leader kommen einfach nicht nach. Ist auch irgendwie verständlich.

Auf der anderen Seite ist es auch wieder gut, das nicht jeder Patch voreilig eingebunden wird. So bleibt der SVN trunk stabiler...

Verfasst: Dienstag 24. April 2007, 11:26
von Y0Gi
Sowas kann auch irgendwann zum guten Grund werden, Django nicht zu benutzen.

Verfasst: Dienstag 24. April 2007, 17:12
von jens
Dumm ist wenn django-Apps voraussetzten, das man Patches eingespielt hat, damit alles funktioniert. z.B. stockphoto:
+ recommended: Patch your Django installation against `ticket 1484`_
...
+ Without the Django patch listed above, the batch import feature is only
likely to work for very small archives.
(aus der README)

Verfasst: Samstag 28. April 2007, 18:10
von Leonidas
Y0Gi hat geschrieben:Sowas kann auch irgendwann zum guten Grund werden, Django nicht zu benutzen.
Es steht einem auch jederzeit frei Django zu forken. Nur sollte man es dann auch selbst besser machen können, was andererseits auch gar nicht so einfach ist.

Verfasst: Dienstag 1. Mai 2007, 19:40
von Y0Gi
Dann den eigenen Fork parallel nachzupatchen ist auch nicht besser. Wünschenswert ist einfach, dass die Patches in Django zeitnah eingepflegt werden. Wenn dazu keine externe Hilfe (z.B. freiwillige Entwickler) in Anspruch genommen und intern nichts dafür getan wird (ich kenne die Hierachie bei Django nicht, sofern es eine gibt, ebenso wenig weiß ich, welche Rolle die Firma spielt, die meines Wissens Django ursprünglich entwickelt hat), dann liegt für mich die Schuld beim Django-Team. Wenn man sich dort nicht helfen lassen will, kann man sich besser ein anderes Framework suchen, das aktiv(er) gepflegt und weiter entwickelt wird. Problematisch wird es in dem Moment, wo es nichts vergleichbares gibt. Selbst diese Aufgabe zu übernehmen bedeutet aber das Rad irgendwo neu zu erfinden, anstatt sich vollkommen auf die eigentlichen Ziele des eigenen Projekts (z.B. einer Anwendung) konzentrieren zu können.

Verfasst: Dienstag 1. Mai 2007, 20:30
von Leonidas
Y0Gi hat geschrieben:Dann den eigenen Fork parallel nachzupatchen ist auch nicht besser. Wünschenswert ist einfach, dass die Patches in Django zeitnah eingepflegt werden.
Da hast du schon ganz Recht. Das Problem ist aber, dass Django dazu einlädt, selbst irgendwelche Features zu implementieren oder daran zu spielen, so dass letztendlich sehr viele Patches eingesendet werden die aber natürlich alle erstmal getestet werden müssen (Testsuite durchlaufen, Coding Standards erfüllen) und dann teilweise auch noch dokumentiert werden müssen. Sowas nimmt nun mal ziemlich viel Zeit in Anspruch. Letztens erst hat Malcolm Tredinnick, einer der Core-Devs in der Mailingliste erzählt, wie es aussieht, wenn er sich mal ransetzt und Patches integriert.
Y0Gi hat geschrieben:Wenn dazu keine externe Hilfe (z.B. freiwillige Entwickler) in Anspruch genommen und intern nichts dafür getan wird (ich kenne die Hierachie bei Django nicht, sofern es eine gibt, ebenso wenig weiß ich, welche Rolle die Firma spielt, die meines Wissens Django ursprünglich entwickelt hat), dann liegt für mich die Schuld beim Django-Team.
Das es an freiwilligen Entwicklern fehlt ist bei Django eher nicht der Fall. Im Gegenteil, es gibt gradezu zu viele Patches, die eben integriert werden müssen. Vor einiger Zeit haben sie den Workflow etwas verändert, so dass sie nun ein Viererteam von Leuten haben, die Tickets aussortieren (Ticket Triager). Das Problem ist aber, dass wenn Tickets als "Design decision needed" gesetzt werden, dass dann auf django-developers oftmals von den Entwicklern kein Statement zu bekommen ist. Liegt vielleicht auch daran, dass die Entwickler gerne auch mal die ganzen brauchbaren Branches mergen würden - kann man ihnen nicht verübeln. In Trunk committen eigentlich nur die Core-Devs (und einige von ihnen wirklich nur zu einem Spezialgebiet wie L10N), Externe arbeiten höchstens an Branches. Das Problem der Branches ist, dass sie an einem Ausmerksamkeitsmangel leiden, so dass sich keiner Traut die zu mergen, weil dann einige Dinge kaputt gehen könnten. Das ist verständlich und eigentlich auch eine gute Idee, weil so der Trunk extrem gut getestet ist, aber so gibt es quasi tote Branches was sehr schade ist, weil es einige sehr Interessante gibt. In letzter Zeit kündigen sich aber einige Branches an: Oracle wurde glaube ich gemerged, Unicode bald, Newforms-Admin sollte es hoffentlich bald. Letzterer ist insofern ein Problem, dass der aktuelle Oldforms-Admin in einer Art Ruhestand ist und dort nichts mehr passiert, da alle gespannt auf Newforms-Admin warten. Ein wenig Deadlock, zugegeben.
Welche Rolle in alledem Lawrence Journal-World spielt weiß ich nicht. Die ersten Core-Entwickler waren dort mal angestellt, Adrian ist es noch, Jacob glaube ich auch. Lawrence Journal-World entwicklt ja auch noch Ellington CMS, also brauchen sie die Core-Devs.

Im Falle von Pylons sieht das etwas anders aus, da die einzelnen Komponenten von verschiedenen Leuten entwickelt werden und sich somit die Last etwas besser verteilt.
Y0Gi hat geschrieben:Wenn man sich dort nicht helfen lassen will, kann man sich besser ein anderes Framework suchen, das aktiv(er) gepflegt und weiter entwickelt wird.
Sowas könnte mit jedem anderen Framework auch passieren, dass einfach die Manpower ausgeht, um wirklich alle änderungen zügig zu integrieren. Pylons hat durch Komponentenansatz etwas mehr Puffer, aber an sich kann sowas eben mit jedem Projekt passieren, sofern es eine kritische Masse erreicht hat. Vor allem wenn dessen Zielgruppe Programmierer sind, die auch mal selbst Hand anlegen.
Der beste Lösungsvorschlag, der mir einfällt ist das Rekrutieren weiterer Committer. Das bringt aber eigene Probleme mit sich, denn so Leute hängen ja nicht an Bäumen. Es muss jemand sein, der mit der Linie der Django-Leute übereinstimmt, jemand der sich in Django möglichst gut auskennt und jemand dem man so etwas eben anvertrauen kann. Aktuell sieht es so aus, dass es viele aktive gibt, aber wenig die wirklich viel beisteuern, so dass man sie ins Kern-Team übernehmen könnte. Bei Firmen würden jetzt einfach Stellenanzeigen aufgegeben werden, bei Freier Software ist das etwas komplizierter, da sich Developer eben nur aus der Community rekrutieren lassen.
Y0Gi hat geschrieben:Problematisch wird es in dem Moment, wo es nichts vergleichbares gibt. Selbst diese Aufgabe zu übernehmen bedeutet aber das Rad irgendwo neu zu erfinden, anstatt sich vollkommen auf die eigentlichen Ziele des eigenen Projekts (z.B. einer Anwendung) konzentrieren zu können.
Deswegen ist es wichtig, dass man genau weiß, was man für Ziele verfolgt. Soll es möglichst schnell gehen und kann Django so etwas erledigen ist Django eine gute Wahl. Wenn es aber um speziellere Anforderungen geht, bzw. will man sich die Komponenten freier Aussuchen als es in Django der Fall ist, dann kommt Pylons (oder vielleicht noch TurgoGears) ins Spiel. Aber wenn man 100%ige Freiheit will, baut man sich eben mit WSGI-Komponenten etwas komplett eigenes. Wobei man da aber viele Vorteile aus der Hand gibt. Man hat in der Regel keine Dokumentation (oder nur sehr wenig und von verschiedener Qualität, je nach Komponente), kaum Support von Leuten die so etwas einsetzen und quasi niemanden, der solch ein Gesammtsystem fährt. Daher kann es sein, dass man selbst reihenweise Bugs fixen muss, bzw. auf die Entwickler der einzelnen Komponenten warten muss, bis sie Patches integrieren. Das dauert auch Zeit. So entwickelt man mehr oder weniger auch sein eigenes Framework, dessen Instandhaltung ebenso Zeit kostet wie das Instandhalten eines Django-Forks. Ob es nun mehr oder weniger Zeit ist, ist schwer abzuschätzen.

Es stimmt schon, dass im Moment die bekanntesten Megaframeworks für python etwas Probleme haben. TurboGears laufen die Leute davon (ich habe längst das Boot verlassen, noch bevor es richtig zu sinken begann) und ich weiß nicht ob TG jemals wieder aufholen wird - Pylons scheint sich immer mehr als das bessere TG herauszukristallisieren. Ist aber auch egal, denn mit Pylons ist ja immerhin ein gutes Framework mit ähnlichem Ansatz verfügbar. Django mangelt es im Moment an Core-Developern, bzw. hat es zu viele Branches, die eigentlich schon längst überfällig sind. Magic-Removal war vergleichbar mit dem langerwarteten Debian Sarge, Newforms-Admin geht es im Moment ähnlich. Aber wenn die Merges erstmal abgeschlossen sind, bin ich recht optimistisch, dass die die Kurve kriegen. Nur die Frage ist, wann.