nicht angemeldet
Mozilla schreit nach Hilfe!
hi
beim Mozilla-Projekt ist die Zahl der unbestätigten Bugs etwas außer Kontrolle geraten. Inzwischen haben sind fast 3000 UNCOs (= Unconfirmed) angesammelt, jeden Tag werden 100 bis 150 neue gemeldet.
Dazu kommt, das viele ältere davon gar nicht überprüft wurden, ob sie mit neueren Mozilla-Versionen immer noch auftreten. Wer immer Zeit und Lust hat diesem Misstand Anhilfe zu verschaffen, der möse sich bitte unter irc.mozilla.org #kill-unco melden, bevor das Chaos perfekt ist.
Grüße aus Bleckede
Kai
-
Hallo Kai,
beim Mozilla-Projekt ist die Zahl der unbestätigten Bugs etwas außer Kontrolle geraten. Inzwischen haben sind fast 3000 UNCOs (= Unconfirmed) angesammelt, jeden Tag werden 100 bis 150 neue gemeldet.
Ganz ehrlich - so ganz verstehe ich die Panikmache nicht. Die sollen jetzt mal schoen die Debug-Informationen raushauen, das Ding mal richtig beschleunigen und sich dann _endlich_ mal trauen, ihre 1.0 endgueltig rauszubringen (dieser 1.0.0-Release-Candidate-Quatsch ist ja schon fast peinlich). Eine endlich mal verfuegbare 1.-Version ist jetzt von der Signalwirkung her wirklich wichtiger als der Perfektionismus mancher Leute, die nicht ertragen koennen, dass die Welt nicht gottgleich fehlerfrei ist. Und wenn man sich die Roadmap von Mozilla anguckt, kann man sehen, dass die runde 1.0 sowieso wohl kaum aelter als zwei Wochen werden wird, weil die Zwischenversionspolitik trotz des magischen Zahlensprungs munter weiter gehen soll. 1.0.1, 1.0.2 ... bis die Mehrzahl der Durchschnittsuser den 1er-Mozilla ueberhaupt runterladen wird, ist die Versionsnummer eh schon wieder ungerade. Und Fehler wird er in 20 Jahren, wenn man wohl bei 1.9.9 und kurz vor der 2.0 stehen wird, genau so viele haben wie jetzt - nur andere halt ;-)
viele Gruesse
Stefan Muenz-
Hi Stefan
Die sollen jetzt mal schoen die Debug-Informationen raushauen, das Ding mal richtig beschleunigen und sich dann _endlich_ mal trauen, ihre 1.0 endgueltig rauszubringen (dieser 1.0.0-Release-Candidate-Quatsch ist ja schon fast peinlich).
Was ist daran peinlich? Ein Release Candidate ist doch nichts anderes als
zu sagen, wir denken, das kann man so rausgeben, ihr die ihr die ganzen
Fehler gemeldet habt, schaut es euch bitte nochmal an ob es auch auf
euren Plattformen ordentlich funktioniert.Zudem hat ein RC eine ganz andere Zielgruppe als eine Betaversion die
eigentlich nicht auf einem produktiven System eingesetzt werden sollte
ohne reifliche Überlegung.Eine endlich mal verfuegbare 1.-Version ist jetzt von der Signalwirkung her wirklich wichtiger als der Perfektionismus mancher Leute, die nicht ertragen koennen, dass die Welt nicht gottgleich fehlerfrei ist.
Meiner Meinung nach kann im Moment dem Mozilla nichts mehr schaden, als
eine 1.0er Version die die Erwartungen nicht erfüllt und fehlerhaft oder
instabil ist. Dann heist es dann, das soll der geniale Mozilla sein, das
Ding das dauernd mein Profil verliert...Und wenn man sich die Roadmap von Mozilla anguckt, kann man sehen, dass die runde 1.0 sowieso wohl kaum aelter als zwei Wochen werden wird, weil die Zwischenversionspolitik trotz des magischen Zahlensprungs munter weiter gehen soll. 1.0.1, 1.0.2 ... bis die Mehrzahl der Durchschnittsuser den 1er-Mozilla ueberhaupt runterladen wird, ist die Versionsnummer eh schon wieder ungerade.
Ist doch auch nett wenn laufend auftauchende Bugs geflickt werden?
Und Fehler wird er in 20 Jahren, wenn man wohl bei 1.9.9 und kurz vor der 2.0 stehen wird, genau so viele haben wie jetzt - nur andere halt ;-)
Genauso wird es die bei IE 2022 geben, nur hat der in der Zeit wesentlich
mehr Major Releases wohl durchgelassen. Die Definition was einen Versionssprung
an der ersten Stelle rechtfertigt ist einfach anders.Die Definition die ich da kenne ist immernoch:
1. Stelle = Vollständig oder mindestens grössten Teils neu geschriebener Code
2. Stelle = Einige Teile komplett neu geschrieben, neue Features
3. Stelle = Bugfixes, kleine ÄnderungenGruss Daniela
-
Hallo Danie,
Was ist daran peinlich? Ein Release Candidate ist doch nichts anderes als zu sagen, wir denken, das kann man so rausgeben, ihr die ihr die ganzen Fehler gemeldet habt, schaut es euch bitte nochmal an ob es auch auf euren Plattformen ordentlich funktioniert.
An sich schon - aber wer so fragt, wird halt noch mal tausend Meldungen erhalten, und die Probleme werden nur mehr. Man muss das Ganze halt auch mal von der pragmatischen Seite sehen und nicht nur von der theoretischen Vollendungslehre her.
Zudem hat ein RC eine ganz andere Zielgruppe als eine Betaversion die eigentlich nicht auf einem produktiven System eingesetzt werden sollte ohne reifliche Überlegung.
Das stimmt zwar ebenfalls in der Theorie, ist aber auch nicht praxisrelevant. 99,9% aller Beta-Tester haben Mozilla - zumindest seit der 0.9.x-Phase - sicher nicht mehr nur auf einem nicht-produktiven System getestet.
Meiner Meinung nach kann im Moment dem Mozilla nichts mehr schaden, als eine 1.0er Version die die Erwartungen nicht erfüllt und fehlerhaft oder instabil ist. Dann heist es dann, das soll der geniale Mozilla sein, das Ding das dauernd mein Profil verliert...
Klar - das sollte auf jeden Fall vermieden werden. Wobei IMHO die "Reife" einer V1.0 wirklich laengst gegeben ist. Ganz dicke Bugs sollten eigentlich nicht mehr drin sein. Ansonsten waere jetzt wichtig, die Gemeinde mal damit zu erfreuen, wie flott eine debug-freie, compiler-optimierte Version sein kann. Und dann kann ich mir eigentlich nicht vorstellen, dass ein Desaster aus der 1.0 wird.
Ist doch auch nett wenn laufend auftauchende Bugs geflickt werden?
Ja, auf jeden Fall. Allerdings ist da bei "Normalanwendern" ein bischen Aufklaerungspolitik von Noeten. Ich denke hier halt auch wieder von der Windows-Welt her, wo dreistufige Versionsnummern bei den meisten kommerziellen oder Shareware-Programmen unueblich sind. Diese Masse von Usern, die ja vom Mozilla-Browser ueberzeugt werden sollte, um die Marktanteile des Browsers zu steigern, koennte ein Problem damit haben, wenn die eigene, gerade downgeloadete Version schon nach zwei Wochen wieder "veraltet" ist. Ich hoffe, dass Mozilla dabei einen Weg findet, Patches mit kleinen Download-Volumina anzubieten. Denn kein Normaluser laedt sich alle zwei Wochen den kompletten Browser neu runter.
Die Definition die ich da kenne ist immernoch:
- Stelle = Vollständig oder mindestens grössten Teils neu geschriebener Code
- Stelle = Einige Teile komplett neu geschrieben, neue Features
- Stelle = Bugfixes, kleine Änderungen
Durchaus nachvollziehbar und einsichtig - aber wie gesagt noch nicht sehr verbreitet in der Welt der Massen-User. Und vor allem scheint mir wichtig, dass es vor allem bei der 3. Stelle "Smart-Updates" gibt.
viele Gruesse
Stefan Muenz-
Hi Stefan
Meiner Meinung nach kann im Moment dem Mozilla nichts mehr schaden, als eine 1.0er Version die die Erwartungen nicht erfüllt und fehlerhaft oder instabil ist. Dann heist es dann, das soll der geniale Mozilla sein, das Ding das dauernd mein Profil verliert...
Klar - das sollte auf jeden Fall vermieden werden. Wobei IMHO die "Reife" einer V1.0 wirklich laengst gegeben ist. Ganz dicke Bugs sollten eigentlich nicht mehr drin sein. Ansonsten waere jetzt wichtig, die Gemeinde mal damit zu erfreuen, wie flott eine debug-freie, compiler-optimierte Version sein kann. Und dann kann ich mir eigentlich nicht vorstellen, dass ein Desaster aus der 1.0 wird.
Hm, gerade so 0.9.x aufwärts sind die Bugs imho mehr geworden und in
0.9.9 sind ein paar drin, die ich wirklich nicht in einem fertigen
Produkt haben will. Leider konnte ich wegen neuem PC und Hardwareprobleme
darin und HD-Crash beim alten noch nicht testen ob die jetzt weg sind
oder mit ner sauberen Installation zu lösen wären. Seit 0.9.8 hat
das Ding ja nichtmal mehr sauber compiliert, resp war nach dem compilieren
nicht startbar. Sind also schon noch ein paar heftigere Dinge.Ist doch auch nett wenn laufend auftauchende Bugs geflickt werden?
Ja, auf jeden Fall. Allerdings ist da bei "Normalanwendern" ein bischen Aufklaerungspolitik von Noeten. Ich denke hier halt auch wieder von der Windows-Welt her, wo dreistufige Versionsnummern bei den meisten kommerziellen oder Shareware-Programmen unueblich sind. Diese Masse von Usern, die ja vom Mozilla-Browser ueberzeugt werden sollte, um die Marktanteile des Browsers zu steigern, koennte ein Problem damit haben, wenn die eigene, gerade downgeloadete Version schon nach zwei Wochen wieder "veraltet" ist. Ich hoffe, dass Mozilla dabei einen Weg findet, Patches mit kleinen Download-Volumina anzubieten. Denn kein Normaluser laedt sich alle zwei Wochen den kompletten Browser neu runter.
Stimmt, das wäre schön und für die, welche selber compilieren Patchfiles
damit man nicht die ganze Source runterladen muss.BTW, produktiv setzens wohl einige auch schon viel länger ein, ich zum
Beispiel seit M16 od M18, weis nicht mehr genau.Gruss Daniela
-
Hallo Stefan,
Ja, auf jeden Fall. Allerdings ist da bei "Normalanwendern" ein bischen Aufklaerungspolitik von Noeten. Ich denke hier halt auch wieder von der Windows-Welt her, wo dreistufige Versionsnummern bei den meisten kommerziellen oder Shareware-Programmen unueblich sind.
Also ich weiß nicht.
Mein IE hat z.B. die Version 5.50.4030.2400, der Amaya-Browser die 4.3.2, Textpad die 4.5.0,
Excel die 9.0.2812, Outlook die 9.0.0.2814, gimp for win die 1.2.3, perl die 5.6.1, das jdk die 1.3.1-02, der Apache die 2.0.35, der Tomcat die 4.0.3 usw.
Es gibt also auch hier viele Programme mit drei- oder sogar vier-teiliger Versionsnummercu,
Andreas-
Hallo Andreas,
Also ich weiß nicht.
Mein IE hat z.B. die Version 5.50.4030.2400, der Amaya-Browser die 4.3.2, Textpad die 4.5.0,
Excel die 9.0.2812, Outlook die 9.0.0.2814, gimp for win die 1.2.3, perl die 5.6.1, das jdk die 1.3.1-02, der Apache die 2.0.35, der Tomcat die 4.0.3 usw.
Es gibt also auch hier viele Programme mit drei- oder sogar vier-teiliger VersionsnummerNa gut, zugegeben, aber andererseits ist es doch tatsächlich so, daß der Normaluser von diesen mehrstelligen Versionsnummern nichts mitbekommt. Zumindest bei Microsoft Produkten. Dein IE lässt sich immer noch als IE 5.5 runterladen und auf der Excel - CD steht Excel 2000 (bzw. MS Office 2000) und nicht Excel 9.0.2812.
Und bei Windows setzt MS lieber ein b oder c dahinter (W95), oder macht eine second edition daraus (W98). Gut, daß sie noch nicht auf die Idee mit dem Monatsnamen gekommen sind. Sonst hätte es womöglich W98.November oder so geheissen (Klingt nach einem Virus, nicht wahr?).Naja die meisten restlichen Programme kommen mehr aus der Unixwelt, da sind solche Versionsnummern ja üblich, da wundert´s nicht, daß sie auch in ihren Win-Versionen mehrstellig sind.
Ciao, Vedat
-
-
hi
Klar - das sollte auf jeden Fall vermieden werden. Wobei IMHO die "Reife" einer V1.0 wirklich laengst gegeben ist. Ganz dicke Bugs sollten eigentlich nicht mehr drin sein. Ansonsten waere jetzt wichtig, die Gemeinde mal damit zu erfreuen, wie flott eine debug-freie, compiler-optimierte Version sein kann. Und dann kann ich mir eigentlich nicht vorstellen, dass ein Desaster aus der 1.0 wird.
frag mal ein paar heise-Trolle, die finden noch genug Macken, um das Ding für 20 Jahre weiterzuentwickeln, bis die 1.0 kommen soll. Da M$ seit dem MSIE4 kaum noch etwas getan hat, ist das Ding eben doch schon etwas stabil geworden, also muss Mozilla mindestens (!) so stabil sein.
Ja, auf jeden Fall. Allerdings ist da bei "Normalanwendern" ein bischen Aufklaerungspolitik von Noeten. Ich denke hier halt auch wieder von der Windows-Welt her, wo dreistufige Versionsnummern bei den meisten kommerziellen oder Shareware-Programmen unueblich sind. Diese Masse von Usern, die ja vom Mozilla-Browser ueberzeugt werden sollte, um die Marktanteile des Browsers zu steigern, koennte ein Problem damit haben, wenn die eigene, gerade downgeloadete Version schon nach zwei Wochen wieder "veraltet" ist. Ich hoffe, dass Mozilla dabei einen Weg findet, Patches mit kleinen Download-Volumina anzubieten. Denn kein Normaluser laedt sich alle zwei Wochen den kompletten Browser neu runter.
bei Browsern sind doch 3 stellige Versionsnummern normal, der MSIE macht's so, NN4 macht's so, Opera..
Mozilla muss nur eines: Besser sein als der MSIE, und zwar aus Enduser-Sicht. Dabei ist es scheißegal, wie Standardkonform er ist. Es zählen NUR Speed, Stabilität. Features und gutes aussehen.
Grüße aus Bleckede
Kai
-
Hallo Kai
Mozilla muss nur eines: Besser sein als der MSIE, und zwar aus Enduser-Sicht. Dabei ist es scheißegal, wie Standardkonform er ist. Es zählen NUR Speed, Stabilität. Features und gutes aussehen.
Technische Gleichwertigkeit oder Ueberlegenheit wird den Otto-Normal-User sicherlich nicht davon ueberzeugen, von IE auf Mozilla umzusteigen. Wahrscheinlich hat die grosse Mehrheit der Leute, die sich heutzutage im Internet rumtreiben, noch nie was von dem Browser gehoert.
Meiner Meinung nach wird Mozilla ohne professionelles Marketing (wer uebernimmt das bei einem Open Source Projekt?) immer ein "Randgruppen-Browser" bleiben.
Gruss
Uwe
-
-
-
Hi Stefan,
Ganz ehrlich - so ganz verstehe ich die Panikmache nicht.
Die sollen jetzt mal schoen die Debug-Informationen
raushauen, das Ding mal richtig beschleunigendas hätten sie mal als Variante einer 0.9.7 machen sollen. :-(
Im Moment ist Korrektheit wichtiger als Performance - und so lange bleibt der Debug-Coe sinnvollerweise drin.
und sich dann _endlich_ mal trauen, ihre 1.0 endgueltig
rauszubringen (dieser 1.0.0-Release-Candidate-Quatsch ist
ja schon fast peinlich).Also da kann ich Dir beim besten Willen nicht zustimmen.
Die 1.0 wird für die Mozilla-Welt (also insbesondere für die Linux-Welt) Maßstäbe setzen. APIs müssen über den gesamten 1.x-Versionszyklus kompatibel gehalten werden.
Deshalb ist es so wahnsinnig wichtig, daß die 1.0 bezüglich dieser Kompatibilität jetzt nichts released, was in 6 Wochen als untauglich erkannt wird, aber dann zwei Jahre lang nicht geändert werden _darf_.Eine endlich mal verfuegbare 1.-Version ist jetzt von der
Signalwirkung her wirklich wichtigerFür wen?
Die Freaks werden gerne auf eine perfekte 1.0 warten.
Und die Firmenkunden werden ohnehin kein Mozilla installieren, sondern eher "Netscape 6.5" im September.als der Perfektionismus mancher Leute, die nicht ertragen
koennen, dass die Welt nicht gottgleich fehlerfrei ist.Sorry, ich glaube, Du schießt an dieser Stelle am Ziel vorbei. (So polemisch kenne ich Dich eigentlich gar nicht ...)
Und wenn man sich die Roadmap von Mozilla anguckt, kann man
sehen, dass die runde 1.0 sowieso wohl kaum aelter als zwei
Wochen werden wirdDas ist aber irrelevant. 1.x ist etwas anderes als 0.9.
Dieser Release-Sprung ist der wichtigste überhaupt in der Mozilla-Historie.weil die Zwischenversionspolitik trotz des magischen
Zahlensprungs munter weiter gehen soll. 1.0.1, 1.0.2 ...
bis die Mehrzahl der Durchschnittsuser den 1er-Mozilla
ueberhaupt runterladen wird, ist die Versionsnummer eh
schon wieder ungerade.Na und? Das macht doch nichts.
Ich denke, Dein Verständnisproblem liegt im Begriff des "bugs". Das bug-report-System von Mozilla umfaßt _alle_ offenen Probleme und Aktivitäten.
Es gibt sogar einen "bug" mit dem Namen "releasing Mozilla 1.0" - dessen Funktion ist es, eine Liste aller offenen Bugs zu enthalten, welche bis zum Release 1.0 definitiv noch geschlossen werden müssen.Das, was Du als normale kleine Bugs kennst, kann sicherlich in 1.0.3 etc geschlossen werden.
Aber es gibt einige Dinge, für die es dann zu spät sein wird. Zwischen 1.0.0 und 1.0.3 darf beispielsweise nicht die Semantik von DOM-Zugriffsroutinen inkompatibel geändert werden. Genau solche Bugs waren aber kürzlich noch offen ... ich habe jetzt eine Weile lang nicht mehr nachgesehen.
Und Kais Aufruf soll zweifellos dazu führen, daß keiner _dieser_ Bugs bei der 1.0.0 übersehen wird.Und Fehler wird er in 20 Jahren, wenn man wohl bei 1.9.9
und kurz vor der 2.0 stehen wird, genau so viele haben wie
jetzt - nur andere halt ;-)Auch dann wird es welche geben, die in der 2.0.0. unbedingt gefixed werden müssen, weil man anschließend wieder zwei Jahre lang nichts mehr daran wird ändern dürfen - und andere, bei denen es nur darum geht, ob irgendwas auf dem Bildschirm schöner aussieht.
Viele Grüße
Michael-
Hallo Michael,
das hätten sie mal als Variante einer 0.9.7 machen sollen. :-(
Wobei, wenn ich ehrlich sein soll, mir persoenlich speziell die 0.9.7 bislang als die fehlerfreieste vorkam. Die beiden danach hatten - zumindest an der Oberflaeche - ein paar Bugs, die vorher schon funktionierten.
Im Moment ist Korrektheit wichtiger als Performance - und so lange bleibt der Debug-Coe sinnvollerweise drin.
Solange es tatsaechlich noch problematische Dinge gibt wie bei den von dir angesprochenen DOM-Zugriffsroutinen, stimme ich dir zu. Wenn es da aber tatsaechlich noch massive Probleme gibt, die nicht von heute auf morgen loesbar sind, dann sollten sie lieber gleich ihren ganzen Roadmap-Plan noch mal neu gestalten. So wie jetzt setzen sie sich doch nur unter wahnsinnigen Druck. Seit Monaten wird da die zweite Aprilhaelfte als Release-Datum fuer die 1.0 ausgewiesen. Und jetzt stehen die User halt zu zehntausenden vor der Tuer und klopfen ungeduldig mit den Fingern. Ich kenn das Gefuehl verdammt gut, im Kleinen habe ich diesen Fehler auch mal gemacht - bei meiner 7.0 vor vier Jahren. Das Ergebnis war, dass ich in den letzten zwei Wochen davor zu einer Art Zombie mutierte und hinterher krank wurde. Ist halt ungeschickt, so was ;-)
Die 1.0 wird für die Mozilla-Welt (also insbesondere für die Linux-Welt) Maßstäbe setzen. APIs müssen über den gesamten 1.x-Versionszyklus kompatibel gehalten werden.
Dem stimme ich ja zu. Aber wie kann man sich denn munter bis zur 0.9.9. vorwagen, wenn dies noch nicht der Fall ist? Ist da nicht vielleicht vorher was schief gelaufen?
Die Freaks werden gerne auf eine perfekte 1.0 warten.
Und die Firmenkunden werden ohnehin kein Mozilla installieren, sondern eher "Netscape 6.5" im September.Ersteres mag ja sein. Aber das Netz besteht nun mal vorwiegend aus Nicht-Freaks, und letztere moechte das Mozilla-Projekt doch eigentlich auch erreichen.
Was letzteres betrifft, kann ich das schlecht beurteilen. Da Netscape aber auf Mozilla basiert, ist das ja auch letztlich wurscht. Wichtiger ist da, wie bald Netscape auf der 1.0 des Mozilla aufsetzt. Angenommen, Mozilla 1.0 kommt Mitte Mai - ob Netscape dann wirklich noch bis September wartet, bis sie eine darauf basierende Version anbieten?Sorry, ich glaube, Du schießt an dieser Stelle am Ziel vorbei. (So polemisch kenne ich Dich eigentlich gar nicht ...)`
April eben - sonst bin ich ja ganz brav geworden ;-)
Es gibt sogar einen "bug" mit dem Namen "releasing Mozilla 1.0" - dessen Funktion ist es, eine Liste aller offenen Bugs zu enthalten, welche bis zum Release 1.0 definitiv noch geschlossen werden müssen.
Durchaus sinnvoll. Aber diese Liste sollte, wenn man erst mal bei 0.9.9 angelangt ist, nicht mehr allzulang sein. Ansonsten hat man in der Versionenpolitik was verkehrt gemacht. Versionenpolitik schafft eben auch Erwartungshaltungen. Und Zahlen wie "0.9.9" wohl allemal. Wer so was releast, muss sich im Klaren darueber sein.
viele Gruesse
Stefan Muenz-
Hallo Stefan,
das hätten sie mal als Variante einer 0.9.7 machen sollen. :-(
Wobei, wenn ich ehrlich sein soll, mir persoenlich speziell die 0.9.7
bislang als die fehlerfreieste vorkam. Die beiden danach hatten -
zumindest an der Oberflaeche - ein paar Bugs, die vorher schon
funktionierten.Full Ack. Aber der Fehler, der mich am meisten störte, ist in der 1.0.RC1
wieder gefixed.Die 1.0 wird für die Mozilla-Welt (also insbesondere für die
Linux-Welt) Maßstäbe setzen. APIs müssen über den gesamten 1.x-
Versionszyklus kompatibel gehalten werden.
Dem stimme ich ja zu. Aber wie kann man sich denn munter bis zur
0.9.9. vorwagen, wenn dies noch nicht der Fall ist? Ist da nicht
vielleicht vorher was schief gelaufen?Es gibt einen Release-Manager für Mozilla, und ein eigenes "Releasing-Projekt". Ich bin da nun wirklich nicht der Experte, aber das Releasing-Verfahren habe ich mir mal kurz durchgelesen (weil mich interessiert, was die 1.0 wirklich taugt, und ob ich die unseren Firmenkunden zur Installation empfehlen will).
Vorgesehen ist, daß seit der 0.9.6 auf 1.0 "gezielt" wird und daß auf dem Weg dorthin drei oder vier (!) Zwischenreleases erlaubt sind.
Es ist also vorgesehen, daß die 1.0 nach der 0.9.9 oder 0.9.10 (!) herauskommen soll. Insofern ist der aktuelle Stand, daß es einen 1.0.RC1 nach der 0.9.9 existiert, anscheinend ein Versuch, mit nur drei Zwischenreleases auszukommen; falls eine 0.9.10 notwendig ist, wäre das kein Beinbruch.Erst wenn sich herausstellt, daß nach der 0.9.10 noch keine Grundlage für eine 1.0 existiert, hat die Roadmap versagt - so steht es explizit dort geschrieben.
Die Freaks werden gerne auf eine perfekte 1.0 warten.
Und die Firmenkunden werden ohnehin kein Mozilla installieren, sondern eher "Netscape 6.5" im September.
Ersteres mag ja sein. Aber das Netz besteht nun mal vorwiegend aus
Nicht-Freaks, und letztere moechte das Mozilla-Projekt doch eigentlich
auch erreichen.Ja, aber nicht mit einer Baustelle, sondern mit einem funktionsfähigen Browser. Und ehrlich - die Probleme, die ich momentan mit 1.0.RC1 habe (Bilder laden ist nicht wirklich reproduzierbar - manchmal geht es, manchmal nicht), machen mir doch einige Sorgen.
Was letzteres betrifft, kann ich das schlecht beurteilen.
Da Netscape aber auf Mozilla basiert, ist das ja auch letztlich
wurscht. Wichtiger ist da, wie bald Netscape auf der 1.0 des Mozilla
aufsetzt. Angenommen, Mozilla 1.0 kommt Mitte Mai - ob Netscape dann
wirklich noch bis September wartet, bis sie eine darauf basierende
Version anbieten?Da geht es gar nicht um 'warten', sondern darum, daß die einfach mindesten 6 Wochen brauchen, um den ganzen Müll einzubauen, der Netscape 6.2 von Mozilla 0.9.4 unterscheidet. Und vermutlich müssen sie noch irgendwelches Zeug einbauen, das Mozilla nicht im Quelltext hat.
Du weißt ja selbst, daß Netscape 6.2.2. auf einem gepatchten Mozilla 0.9.4.1 basiert, obwohl zu diesem Zeitpunkt bereits 0.9.7 oder mehr verfügbar war. Ich kann mir daher gut vorstellen, daß in Netscape 6.5 eher Mozilla 1.0.1.1 oder so ähnlich drin ist - zu einem Zeitpunkt, zu dem Mozilla bei 1.0.4 angekommen sein wird.
Es gibt sogar einen "bug" mit dem Namen "releasing Mozilla 1.0" -
dessen Funktion ist es, eine Liste aller offenen Bugs zu enthalten,
welche bis zum Release 1.0 definitiv noch geschlossen werden
müssen.
Durchaus sinnvoll. Aber diese Liste sollte, wenn man erst mal bei
0.9.9 angelangt ist, nicht mehr allzulang sein. Ansonsten hat man in
der Versionenpolitik was verkehrt gemacht. Versionenpolitik schafft
eben auch Erwartungshaltungen. Und Zahlen wie "0.9.9" wohl allemal.
Wer so was releast, muss sich im Klaren darueber sein.In der Unix-Welt gibt es keinen Zwang, Versionsnummern ausschließlich aus Ziffern zu bilden. Das dürfen sehr wohl auch nicht-einstellige Zahlen sein.
Viele Grüße
Michael
(der gerade mit Entsetzen feststellen mußte, daß Mozilla 1.0.RC1 beim Abspeichern einer HTML-Seite in eine Datei aus validem XHTML 1.0 invaliden Code macht, weil es - in schlimmster M$IE-Tradition - den Quelltext 'optimiert' - pfui Teufel ...)-
Hallo.
Viele Grüße
Michael
(der gerade mit Entsetzen feststellen mußte, daß Mozilla 1.0.RC1 beim Abspeichern einer HTML-Seite in eine Datei aus validem XHTML 1.0 invaliden Code macht, weil es - in schlimmster M$IE-Tradition - den Quelltext 'optimiert' - pfui Teufel ...)Wirklich grausam. Ich habe eine halbe Ewigkeit nach der Ursache gesucht, wieso Mozilla eine bestimmte Webseite nicht anzeigen kann, während Opera, IE und jeder beliebige stupide Textbrowser kein Problem mit der Seite hatten.
Was mache ich also: Seite lokal speichern, in den Editor laden und den Quelltext mühselig durchforsten, immer wieder und wieder, ohne Erfolg. Bis ich glaubte gemerkt zu haben, dass die Webseite speziell je nach User-Agent verschiedene Versionen liefert; aber niemand filtert schamlos Open Source-Browser.
Bisher ahnte ich nicht, dass ein neues Feature Mozillas dafür verantwortlich ist, und kein Bug...Entweder ich bilde es mir ein, oder Mozilla optimiert tatsächlich auch den Quelltext, welcher vom internen HTML-Viewer angezeigt wird. Das ist wirklich nicht mehr zu verantworten.
Grüße,
Mathias-
Hi,
(der gerade mit Entsetzen feststellen mußte, daß Mozilla
1.0.RC1 beim Abspeichern einer HTML-Seite in eine Datei
aus validem XHTML 1.0 invaliden Code macht, weil es - in
schlimmster M$IE-Tradition - den Quelltext 'optimiert' -
pfui Teufel ...)Was mache ich also: Seite lokal speichern, in den Editor
laden und den Quelltext mühselig durchforsten, immer wieder
und wieder, ohne Erfolg. Bis ich glaubte gemerkt zu haben,
dass die Webseite speziell je nach User-Agent verschiedene
Versionen liefert; aber niemand filtert schamlos Open
Source-Browser.
Bisher ahnte ich nicht, dass ein neues Feature Mozillas
dafür verantwortlich ist, und kein Bug...mir geht es genauso.
Ich bastele an meiner Suchmaschine, will die CGI-generierten Seiten-Inhalte HTML- und CSS-validieren, habe das Teil aber noch nicht online, und mit Opera funktioniert die gesamte Website nicht (zu schlechte JavaScript-Unterstützung, deshalb blocken wir den schon beim Login komplett raus).
Wie also nun validieren?
1. Seite im Browser anzeigen und abspeichern,
2. per FTP auf meine private Domain und dann
3. den W3C darauf los lassen ...
und das am besten mit einem "vertrauenswürdigen" Mozilla 1.0.Haste gedacht, denn der Quelltext ist nicht wiederzuerkennen:
Ich habe explizit
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">in meinem Dokument drin stehen, aber Mozilla nimmt beim Abspeichern sämtliche schließenden "/"-Parameter aus singulären Tags heraus (<meta>, <br>, <img>).
Und das sind in meinem Falle leider einige ... stell Dir eine Seite vor, die etwa so viele Bilder hat wie die Forums-Hauptdatei ...Und der Validator haut mir die Seite dann natürlich um die Ohren. :-(
Und das Allerschlimmste ist: In view-source ist der Code noch korrekt! Er geht erst beim Speichern kaputt. Auf die Idee muß erst mal einer kommen ...
Ich kann also immerhin in view-source das gesamte Dokument markieren und _diesen_ Text abspeichern und dann weiter wie oben beschrieben ... aber was mich das Nerven gekostet hat, das herauszufinden ...
Viele Grüße
Michael
-
-
-
-
-
-
Hi Kai,
Wer immer Zeit und Lust hat diesem Misstand Anhilfe zu verschaffen, der möge sich bitte unter irc.mozilla.org #kill-unco melden, bevor das Chaos perfekt ist.
tja, diese Zeit müßte man eben haben ... statt dessen hier die Bauanleitung, um einen aktuellen Effekt zu reproduzieren:
1. Diese Forums-Hauptdatei mit einem Mozilla in
Standard-Konfiguration laden. (Version ist egal, ich
poste dieses gerade mit 1.0RC1, und da "geht es".)2. Ein beliebiges Posting anklicken.
3. Edit / Preferences / Advanced / HTTP Networking und
Inhalt des Feldes "Accept-Encoding" löschen (oder
auch nur "gzip," aus dem String entfernen, das
reicht auch schon).4. "Zurück"-Button.
Wer jetzt glaubt, wieder den Inhalt der Forums-Hauptdatei vor sich zu sehen - guess again.
Mozilla arbeitet nach der Methode, daß "nicht sein kann, was nicht sein darf" - es würde _jetzt_ die Seite nicht mehr komprimiert anfordern, aber daß es genau dies noch Sekunden vorher getan und den komprimierten Inhalt in seinem Cache liegen hat, verdrängt es geflissentlich.
M$IE hat übrigens denselben Bug (in allen Versionen 4.0-6.0), aber dort kann man es nicht ausprobieren, weil Änderungen an der HTTP-Konfiguration einen Neustart des Browsers erfordern.
Beide Browser sind aus diesem Grund auch hoffnungslos überfordert, wenn ihnen ein caching proxy einen komprimierten Seiteninhalt andrehen will, nach dem sie nicht explizit gefragt haben (ich habe es mit unserem Firmen-Proxy ausprobiert) - obwohl beide den "Content-Encoding:"-Header ansonsten korrekt interpretieren und das Paket auspacken können. Sie haben nur beide keinen Bock ... :-(
Viele Grüße
MichaelP.S.: Opera 6.0 macht es übrigens richtig (bravo!).
-
Hallo,
nein nein, es geht jetzt nicht um meinen geliebten mozilla an sich, ehrlich nicht ;-), aber der Bug mit dem "wegnehmen" der gzip-Fähigkeit (Du verzeihst bitte, wie immer, meine Laienformulierungen?) während des anzeigen einer eigendlich schon dekomprimierten Seite und dem dann erfolgendem Verlust des "gedächtnises" bezüglich der ja schon längst dekompremierten Seite ist doch in gewisser weise eher ein "akademischer" Bug, oder? ;-)))) wäre was für version 7 oder 8 sich mal darum zu kümmern, weil das so vielen immer pasiert, daß sie per Mainipulation an der Config dem mozilla die dekompremierfähigkeit nehmen und dann sich ärgern müssen, weil die aktuelle Seite nicht mehr da ist ,-)))
Chräcker
-
Moin moin!
nein nein, es geht jetzt nicht um meinen geliebten mozilla an sich, ehrlich nicht ;-), aber der Bug mit dem "wegnehmen" der gzip-Fähigkeit (Du verzeihst bitte, wie immer, meine Laienformulierungen?) während des anzeigen einer eigendlich schon dekomprimierten Seite und dem dann erfolgendem Verlust des "gedächtnises" bezüglich der ja schon längst dekompremierten Seite ist doch in gewisser weise eher ein "akademischer" Bug, oder? ;-))))
Naja, da hast Du schon recht, fuer die Praxis ist das wohl nicht so relevant. Jedoch laesst das auf eine gewisse "Unsauberkeit" im Design schliessen, was wiederum Befuerchtungen bzgl. der einfachen Erweiterbarkeit des Codes aufkommen laesst; ausserdem draengt sich die Vermutung auf, dass da noch weitere Bugs in dieser Gegend existieren.
So long
--
Rule of thumb -- every time Microsoft use the word "smart," be on the lookout for something dumb.
-- http://www.fourmilab.ch/webtools/demoroniser/
-
-