Hallo Raphael, sorry, auch ich habe mich lange gefragt, ob ich antworten soll. Aber da andere den Schwachsinn, den Du schreibst für bare Münze nehmen, sehe ich mich gezwungen einige Sachen klarzustellen.
2011/5/28 Raphael Bircher <r.birc...@gmx.ch>: > Am 26.05.11 15:59, schrieb Christian Lohmaier: > Bei OOo fühlte sich zumindest Oracle > für die Qualität verantwortlich. Wenn ein Bug wirklich stöhrte, konnte man > fast immer auf einen Bugfix von dort zählen. Was bringt Dich auf die Idee, daß man bei LO nicht auf einen Bugfix zählen kann, wenn ein Bug wirklich stört? > Wenn halt mal der entsprechende > Programmierer kein Ohr haben wollte, ging man halt eine oder zwei Etagen > höher rein. Hahahahahahahaha! Bitte, FAKTEN, nicht nur Geschwafel. Gibt mir mal ein Beispiel, wo Du (oder jemand anders, der nix mit Oracle zu tun hat) "mal ein oder zwei Etagen höher" gegangen ist. Was ist denn überhaupt nach Deiner Definition "eine Etage höher", und was ist dann die zweite Etage. Sorry, aber Du schwafelst wieder nur irgendwelches Zeug, von dem Du glaubst es sei so, aber von dem du selber überhaupt keine Ahnung hast. Wie oft hattest DU SELBST mit cws-QA zu tun? Noch nicht mal als QA-Rep, einfach nur als Member würde mir schon reichen. > Schau mal in den > Bugtracker, Ihr habt nach etwas mehr als einem Jahr bereits 1800 offene Bugs > rumliegen. Dem gegenüber stehen 1200 gefixte. Bitte, schau doch mal bei OOo: über 20000 offene Bugs, das auf 10 Jahre, macht pro Jahr 2000 offene Bugs, und das trotz der sooo tollen Unterstützung von Oracle. Demgegenüber stehen run 45000 gefixte Issues (und das sind nicht nur code-issues). Aber nur mit den blanko Zahlen, ohne zusätzliche Kriterien bringt das nix. > Ohne diskussion, auch bei OOo blieben Bugs offen, Aber im Verhältniss sieht > die Bilanz doch einiges besser aus. Nein, sieht sie nicht. Mal abgesehen davon, daß bei den offenen Bugs bei LibreOffice auch etliche EasyHacks, sprich einsteigertaugliche Aufgaben gesammelt sind - aus den reinen Zahlen kannst Du keine Bilanz ableiten. >> Der einzige Unterschied ist in der Grundeinstellung zu der Art des >> Releases, da gibt es einen Unterschied. > > Selbst wenn dieser unterschied schon ziemlich gross ist, es ist nicht der > einzige. Der wirklich grosse Unterschied ist, dass es die Workflows von LibO > erlauben dass nahezu ungetesteter Code in das Programm einfliesst. Wenn es in den Code einfließt, heißt das noch lange nicht, daß das auch im Programm landet. Auch in einen CWS wird "nahezu ungetesteter Code" reingeschrieben. Alles was neu ist ist per Definition ungetestet. Bei OOo testet das dann ein dem Entwickler zugeneigter QA-Mensch, bei LO werfen sich alle darauf. Wo findet man den Fehler schneller: Wenn zwei Leute draufschauen, oder wenn 50 Leute draufschauen? Mal anders rum: Bei LO wäre es undenkbar, daß eine Verschlimmbesserung wie der Serienbriefassistent im Produkt landen würde. Sowas ist nur dadurch möglich, daß es erst abgeschottet in irgendeinem CWS erstellt wird, und dann nach dem Motto "Hurrah, hier bin ich" im Produkt landet. Und wenn man dann was kritisiert heißt es: Jetzt ist es zu spät, jetzt ist es ja schon implementiert, hättest Du mal früher reagiert. Also kommts ins Produkt, obwohl jedem klar ist, daß die Lösung Murks ist. > Es gibt zum Beispiel keine > Möglichkeit ein Buggy Feature aufzuhalten. Klar gibt es das. Und das einfacher als bei OOo. Überraschungsmomente ala "Ich hab da mal was vorbereitet - friß oder stirb" gibts hier quasi nicht. > Denn es landet direkt im Master. Ja und? von Master aus werden keine Endnutzer-Releases erstellt. Und die Release-Branches werden auch so frühzeitig abgezweigt, daß nicht noch kurz vor Schluß ein Feature plötzlich auftaucht, so wie es bei OOo oft der Fall war. Kurz vor der Deadline werden auf Teufel-komm-raus noch unzählige CWS integriert und schon tauchen für den externen Beobachter 5 neue Features auf, von denen vorher noch keine Rede war. Bei LO passiert das nicht. Es gibt Master, da landen neue Sachen, für Umfangreichere Sachen gibt es auch da extra Branches. Aber Master und den Release-Branch kannst Du nicht gleichsetzen. > Der QA hat keine Handhabe gegen den Entwickler, es sei denn es sind ganz > üble Bugs, die können zum Blocker ernannt werden. Sorry, aber womit belegst Du diese Aussage? Wo ist es anders gegenüber Oracle/OOo. Auch bei OOo hast Du keine andere Handhabe als bei LO: Issue melden, zum Blocker-Issue hinzufügen und hoffen, daß das release-team den als wichtig genug einstuft, um das Release zu verzögern. Mehr Handhabe hat die QA bei OOo auch nicht. > Aber selbst die kriterien > für einen Blocker sind so schwammig, dass man fast jedem Bug den > Blockerstatus absprechen kann. Ist doch bei OOo auch nicht anders definiert! > Bei OOo sass man als QA am längeren Hebel. Das ist Schwachsinn. > Wenn man als QA stop rief, dann > war stop, ob das den Programmierer nun passt oder nicht. OK, wieder mal Ende der Märchenstunde und Fakten/Beispiele bitte. Wann hast Du (oder wer anders, der nix mit Oracle zu tun hat) "Stop" gerufen und es war dann auch wirklich stop? Ich kann mich im Gegenteil an etliche Beispiele erinnern, wo es nur nach sehr langem Hickhack und massiven Widerstand des Projektes eine Änderung möglich war. Ich erinnere nur mal an das Quickstarter/Schnellstartericon in WIndows. Bis das wieder sinnvolle Funktionalität bekam war es ein sehr harter Kampf, von wegen man sagt einfach "stop". Auch wenn man klare Argumente hat, sogar die Spezifikation von Microsoft bzgl. Taskleisten Icon sagt, daß das, was der Entwickler da verzapft hat totaler Unfug ist, wurde das ins Produckt gedrückt, und wiegesagt nur nach sehr langem Kampf wurde das geändert - und nicht, weil man auf Oracle's Seite den Fehler eingesehen hat, sondern einfach nur damit wieder Ruhe herrscht. > Das war zwar keine > angenehme Sache für die Programmierer, aber machte dafür die ohnehin sehr > unattraktive QA Arbeit wesentlich angenehmer. Ich hatte garantiert Einfluss, > was bei LibreOffice nicht der Fall ist. Du schreibst hier explizit "ich" - also bitte gib mal Beispiele von Deinem Einfluß. Und: Du schreibst: bei LO hättest du keinen Einfluß. Belege bitte - wie kommst Du auf die Idee, daß man bei LO als QA keinen Einfluß hätte? > Klar, es war etwas unglücklich, dass > dieses System komplett von Mitarbeiter einer Firma kontrolliert wurde und in > manchen Fällen wurde das System vielleicht zu stur umgesetzt. Aber es > funktionierte. Es funktionierte eben nicht, bedingt durch "Vetternwirtschaft" und das andere Buildsystem bei Sun/Oracle wurde die Community immer gerne links liegen gelassen, buildbreaker, die durch die Tinderbox/Buildbots gefunden wurden sind regelmäßig ignoriert worden, Dein "Einfluß" kommt immer erst hinterher, wenn man *nachdem* ein cws in den Master gelandet ist und somit ein größerer Kreis der Leute den Mist zu Gesicht bekommen hat. Also nix mit "Worfklow ist so super" - nenne wiegesagt mal konkrete Beispiele (oder hör damit auf, so unhaltbare Behauptungen aufzustellen) >> Anstattdessen ist die Philosophie: Release Early, Release Often. >> Sprich: Auch wenn nach dem Release einer Version ein dicker Bug >> entdeckt wird ist das halb so wild, weil das nächste Release schon >> fest eingeplant ist, und das in naher Zukunft, nicht erst nach einem >> halben Jahr oder noch später. > > Ein dicker Bug hat in einem Release nichts, aber auch gar nichts verlohren. Ja, und Du besitzt ja auch sicher eine Glaskugel, mit der du noch nicht entdeckte Bugs vorhersagen kannst. Immer dann, wenn es konkret wird, weichst Du aus, drückst Dich vor einer Antwort, anstattdessen kommen weitere unhaltbare Behauptungen oder Mutmaßungen. ciao Christian -- ----------------------------------------------------------------- To unsubscribe send email to dev-unsubscr...@de.openoffice.org For additional commands send email to sy...@de.openoffice.org with Subject: help
