Die Version 1 beta 5 wurde veröffentlicht. Dies soll voraussichtlich die letzte Version vor der finalen 1er sein, die wahrscheinlich nächste Woche released wird.
Ted bittet um Tests. Fehler sollten schnellstmöglich im englischen Forum bzw. im Projekt gemeldet werden.
Danke!
Version 1 beta 5
-
Piratos
Re: Version 1 beta 5
Wenn das die letzte Beta sein soll, dann ist die erste 1 er in Wahrheit die Beta 6.
Man muss nur im englischen Thread nachsehen um zahlreiche Fehler, teils aber auch bereits gemeldete und nicht abgestellte zu sehen.
Der massgebene DEV Teil wird leider immer noch nicht mit Fehlermeldungen im ausreichenden Masse beschickt - da wird lieber im Forum die Fahne hoch gehalten.
Wer sich selbst die Mühe macht mal 10 Minuten unter die Oberfläche zu sehen, findet noch weitere dazu.
Ich allein habe da innerhalb 10 Minuten 11 Fehler gefunden, die weder im dev noch im Forum angezeigt werden.
das fängt schon damit an :
Cannot create /opt/lampp/htdocs/1b5/config.php, please change permissions to allow this
Um das zu ermöglichen müsste man Schreibrechte auf die Root der Installationsebene setzen und das will ja wohl keiner, richtig wäre eine leere config.php mitzuliefern um diese dann für den Installationsvorgang auf Schreibrechte zu setzen - bedingt aber ein besonderes Handling beim Update, da ja eine config.php schon vorhanden ist - aber so weit bei den simpelsten Dingen denkt da keiner mehr.
Andere Opensourcetitel insbesondere auch Forensoftware machen das schon seit Jahren völlig problemfrei.
Ich möchte nicht wissen, was da heraus kommt, wenn man da mal einen halben Tag dran sitzt.
Ich persönlich habe keinerlei Lust (und Zeit) mehr eigene Test's zu machen und Bugzilla zu füttern, denn da werden noch 38 gemeldete (und teils uralte) Fehler als offen angezeigt und es tut sich nichts.
Man sollte doch lieber erst diese erledigen und dann eine Beta5 bringen.
Auf der anderen Seite muss man sich ja wirklich zu Recht fragen, welchen Sinn denn nun Test's haben, wenn die Fehler nicht erledigt werden ?
Irgendwie erkenne ich da nur einen Unsinn weniger einen Sinn.
Ich warte somit ganz einfach auf die 1.1 er stable und werde dann wieder bei meinen Modulen aktiv.
Aus meiner Sicht kann ich nur jedem empfehlen solche Meldungen von Ahnungslosen zur aktuellen Beta wie , ist prima, läuft bestens etc. vollständig zu ignorieren und für einen echten Einsatz ebenso zu verfahren ansonsten die 0.13 er nehmen - man handelt sich ansonsten, wenn es für andere ist, mehr Ärger ein als Lob.
Es fehlt auch die definitive Auskunft ob Modulemanager und Soup - die ja nun nicht mehr enthalten sind, auch dauerhaft kein Bestandteil des Standardpacks ist. Die mitgelieferte Changelog geht nur bis zur 0.11 er Version, wird also offenbar nicht gepflegt (Frage - weiss denn überhaupt noch irgendein Developer Bescheid ?)
Man muss nur im englischen Thread nachsehen um zahlreiche Fehler, teils aber auch bereits gemeldete und nicht abgestellte zu sehen.
Der massgebene DEV Teil wird leider immer noch nicht mit Fehlermeldungen im ausreichenden Masse beschickt - da wird lieber im Forum die Fahne hoch gehalten.
Wer sich selbst die Mühe macht mal 10 Minuten unter die Oberfläche zu sehen, findet noch weitere dazu.
Ich allein habe da innerhalb 10 Minuten 11 Fehler gefunden, die weder im dev noch im Forum angezeigt werden.
das fängt schon damit an :
Cannot create /opt/lampp/htdocs/1b5/config.php, please change permissions to allow this
Um das zu ermöglichen müsste man Schreibrechte auf die Root der Installationsebene setzen und das will ja wohl keiner, richtig wäre eine leere config.php mitzuliefern um diese dann für den Installationsvorgang auf Schreibrechte zu setzen - bedingt aber ein besonderes Handling beim Update, da ja eine config.php schon vorhanden ist - aber so weit bei den simpelsten Dingen denkt da keiner mehr.
Andere Opensourcetitel insbesondere auch Forensoftware machen das schon seit Jahren völlig problemfrei.
Ich möchte nicht wissen, was da heraus kommt, wenn man da mal einen halben Tag dran sitzt.
Ich persönlich habe keinerlei Lust (und Zeit) mehr eigene Test's zu machen und Bugzilla zu füttern, denn da werden noch 38 gemeldete (und teils uralte) Fehler als offen angezeigt und es tut sich nichts.
Man sollte doch lieber erst diese erledigen und dann eine Beta5 bringen.
Auf der anderen Seite muss man sich ja wirklich zu Recht fragen, welchen Sinn denn nun Test's haben, wenn die Fehler nicht erledigt werden ?
Irgendwie erkenne ich da nur einen Unsinn weniger einen Sinn.
Ich warte somit ganz einfach auf die 1.1 er stable und werde dann wieder bei meinen Modulen aktiv.
Aus meiner Sicht kann ich nur jedem empfehlen solche Meldungen von Ahnungslosen zur aktuellen Beta wie , ist prima, läuft bestens etc. vollständig zu ignorieren und für einen echten Einsatz ebenso zu verfahren ansonsten die 0.13 er nehmen - man handelt sich ansonsten, wenn es für andere ist, mehr Ärger ein als Lob.
Es fehlt auch die definitive Auskunft ob Modulemanager und Soup - die ja nun nicht mehr enthalten sind, auch dauerhaft kein Bestandteil des Standardpacks ist. Die mitgelieferte Changelog geht nur bis zur 0.11 er Version, wird also offenbar nicht gepflegt (Frage - weiss denn überhaupt noch irgendein Developer Bescheid ?)
Last edited by Piratos on Sat Aug 19, 2006 10:04 am, edited 1 time in total.
-
Piratos
Re: Version 1 beta 5
Auch beim Handling von Stylesheets.php hat man zurück gerudert:
Das ist das, was nur das Holen der Stylesheets verballert.
Der Grund - anstelle die Sheets über Mysql bzw. PG Kommandos direkt zu holen wird widerum fast 100% der ganzen CMS - Libns geladen nur um die CS zu holen - das kann doch nicht wahr sein, besonders weil es da schon bessere Lösungen gab !!!
Die Zeiten kann man zu den Zeiten der index.php dazu rechnen. Der Speicherverbrauch schränkt die Anzahl der gleichzeitig möglichen User stark ein , da vorzeitig auf Swapping (Festplatte) übergegangen wird.
Bei der Messung der Zeit in der index.php wird immer noch geschummelt - an der richtigen Stelle eingesetzt ergibt es andere Ausführungszeiten:
Und das sind rund 0,03 Sekunden mehr.
Es wird die falsche Version angezeigt - die komplette version.php ist falsch:
$CMS_VERSION = "0.11-beta5";
$CMS_VERSION_NAME = "Trinidad";
$CMS_SCHEMA_VERSION = "13";
--------------------------------------------
Auf der anderen Seite wird der Logger wieder eingesetzt, der in der 0.13 bereits aus Zeit und Speichergründen verschwunden war:
define("LOG4PHP_LOGDIR", dirname(__FILE__).'/tmp/cache');
define("LOG4PHP_CONFIGURATION", dirname(__FILE__).'/lib/log4php/log4php.properties');
require_once(dirname(__FILE__).'/lib/log4php/LoggerManager.php');
Ebenfalls ein glatter Rückschritt.
Die Version 1.0 verspricht einen glatten Rückschritt und 0 Fortschritt - jammerschade was so ein paar Developer anrichten können, wenn offenbar die Übersicht flöten gegangen ist.
Das deutet auf ein komplettes Fiasko hin. Wenn so etwas passiert kann man nur noch von sehr minderer Arbeitsqualität sprechen - ich bin ziemlich enttäuscht.
Das ist das, was nur das Holen der Stylesheets verballert.
Der Grund - anstelle die Sheets über Mysql bzw. PG Kommandos direkt zu holen wird widerum fast 100% der ganzen CMS - Libns geladen nur um die CS zu holen - das kann doch nicht wahr sein, besonders weil es da schon bessere Lösungen gab !!!
Die Zeiten kann man zu den Zeiten der index.php dazu rechnen. Der Speicherverbrauch schränkt die Anzahl der gleichzeitig möglichen User stark ein , da vorzeitig auf Swapping (Festplatte) übergegangen wird.
Bei der Messung der Zeit in der index.php wird immer noch geschummelt - an der richtigen Stelle eingesetzt ergibt es andere Ausführungszeiten:
Und das sind rund 0,03 Sekunden mehr.
Es wird die falsche Version angezeigt - die komplette version.php ist falsch:
$CMS_VERSION = "0.11-beta5";
$CMS_VERSION_NAME = "Trinidad";
$CMS_SCHEMA_VERSION = "13";
--------------------------------------------
Auf der anderen Seite wird der Logger wieder eingesetzt, der in der 0.13 bereits aus Zeit und Speichergründen verschwunden war:
define("LOG4PHP_LOGDIR", dirname(__FILE__).'/tmp/cache');
define("LOG4PHP_CONFIGURATION", dirname(__FILE__).'/lib/log4php/log4php.properties');
require_once(dirname(__FILE__).'/lib/log4php/LoggerManager.php');
Ebenfalls ein glatter Rückschritt.
Die Version 1.0 verspricht einen glatten Rückschritt und 0 Fortschritt - jammerschade was so ein paar Developer anrichten können, wenn offenbar die Übersicht flöten gegangen ist.
Das deutet auf ein komplettes Fiasko hin. Wenn so etwas passiert kann man nur noch von sehr minderer Arbeitsqualität sprechen - ich bin ziemlich enttäuscht.
Last edited by Piratos on Sat Aug 19, 2006 11:17 am, edited 1 time in total.
-
Piratos
Re: Version 1 beta 5
Irgend etwas tut sich da auf Basis von Anregungen im englischen Thread.
Ich habe leider nicht den kompletten IRC Chat verfolgen können, aber offenbar werden zentrale Classen nun gesplittet, damit man nicht überall statt eines kleinen Luftballons einen Fesselballon erhält.
Zudem wird wohl auch etwas getan um um eine Freigabe des Memorys nach Nutzung durch Adodb zu erhalten (Close auf Resultset).
Ich habe leider nicht den kompletten IRC Chat verfolgen können, aber offenbar werden zentrale Classen nun gesplittet, damit man nicht überall statt eines kleinen Luftballons einen Fesselballon erhält.
Zudem wird wohl auch etwas getan um um eine Freigabe des Memorys nach Nutzung durch Adodb zu erhalten (Close auf Resultset).
-
cyberman
Re: Version 1 beta 5
Hmm, auf der Mainpage geht es bis 0.13 ...Piratos wrote: Die mitgelieferte Changelog geht nur bis zur 0.11 er Version,
-
Piratos
Re: Version 1 beta 5
Ja es gab wohl ein kleines Problem beim dev-server - ich habe tatsächlich 2 x die 011 beta 5 als tatsächlichen download bekommen und nicht die 1 b5 - das ist aber im englischen thread geklärt - die grundsätzlichen Dinge bleiben aber leider die gleichen.
Die Hauptursache beim RAM ist die, wie seit Jahren angemeckert, dass man Monsterclassen für jeden Kleinscheiss einsetzt.
Zum anderen auch solche Dinge, dass ein Query noch nie abgeschlossen wurde , damit ist der Einsatz der Adodb Funktion Close für das Resultset gemeint , die den vom Ergebnis einer Abfrage belegten Speicher frei gibt - das passiert hunderte Male nicht und hat entweder bei grossen Datenmengen sofort einen Abschuss zur Folge bzw. führt zu den schwer erkennbaren memory_peaks die einen Überlauf erzeugen.
Das hat zudem beim Einsatz von persistant sehr unangenehme Folgen.
Und noch 2 weitere Informationen von Deutschlands grösstem Hoster
maxexecutiontime ist 10 Sekunden
maximale Anzahl von Prozessen 24 - das bedeutet schlichtweg nie mehr als echte 24 Besucher gleichzeitig.
Die Hauptursache beim RAM ist die, wie seit Jahren angemeckert, dass man Monsterclassen für jeden Kleinscheiss einsetzt.
Zum anderen auch solche Dinge, dass ein Query noch nie abgeschlossen wurde , damit ist der Einsatz der Adodb Funktion Close für das Resultset gemeint , die den vom Ergebnis einer Abfrage belegten Speicher frei gibt - das passiert hunderte Male nicht und hat entweder bei grossen Datenmengen sofort einen Abschuss zur Folge bzw. führt zu den schwer erkennbaren memory_peaks die einen Überlauf erzeugen.
Das hat zudem beim Einsatz von persistant sehr unangenehme Folgen.
Und noch 2 weitere Informationen von Deutschlands grösstem Hoster
maxexecutiontime ist 10 Sekunden
maximale Anzahl von Prozessen 24 - das bedeutet schlichtweg nie mehr als echte 24 Besucher gleichzeitig.
-
Piratos
Re: Version 1 beta 5
Na wer sagt es denn, wer lange bohrt macht auch ein Loch und darin ist nun die B5 gefallen, denn es kommt eine B 6 mit wahrscheinlich umfangreichen Änderungen, was unsere Problemfälle betrifft - da bin ich mal gespannt.
-
cyberman
Re: Version 1 beta 6
Offensichtlich noch rechtzeitigPiratos wrote: wer lange bohrt macht auch ein Loch und darin ist nun die B5 gefallen,
...Die Beta6 wurde veröffentlicht. Die Probleme durch das Nachladen von Klassen und der Speicherbedarf sollen sich verbessert haben.denn es kommt eine B 6 mit wahrscheinlich umfangreichen Änderungen,
Der Preis für die aktuellen Änderungen ist allerdings, dass Module, die auf Kernklassen von CMSms zugreifen, nicht bzw. nicht wie gewünscht funktionieren. Für Module, die dies unbedingt benötigen, wurde ein Kompatibilitäts-Modus eingebaut. Um diesen zu aktivieren, muss in der config.php der Wert $config['backwards_compatible'] auf true gesetzt werden.
Ansonsten - frohes Testen ...
PS: Noch etwas - für einen deutschen Login-Screen (Administration) sollte in der config.php der Wert $config['locale'] auf 'de_DE' gesetzt werden.
Last edited by cyberman on Fri Aug 25, 2006 7:17 am, edited 1 time in total.
