Hallo Raphael, jetzt zum ersten Mal verstehe ich als Nichtprogrammierer den Unterschied zwischen den Arbeitsweisen von LO und OOo. Die sind doch gewaltig. Danke für deinen Beitrag.
Du hast vollkommen recht: In einer Büro-Umgebung, in einer Bank oder einem anderen Betrieb wären größere Bugs absolut unerträglich. Auch in einem kleineren Verlag, der sich auf das Textsystem einfach verlassen muss, wenn es nicht untergehen will. Das LO-Team scheint davon auszugehen, dass die Anwender aus Spaß irgendwelche Releases testen können, und nicht wirklich produktiv sein wollen oder müssen. Ich wünsche, Oracle entwickelt einen "Oracle Office Suite - OOS" für die zahlenden Kunden und kooperiert im vollen Sinne mit der OOo-Community. Für meinen Bereich (FH) würde ich sogar den Kauf einer Software, wenn die Preise für Bildung bescheiden bleiben, bevorzugen. Eine Rückkehr zu Microsoft, auch wenn es kostenlos wäre, wäre ein technologischer Rückschritt. Best Dave 2011/5/28 Raphael Bircher <[email protected]> > Hallo Christian > > Ich hab mir wirklich lange überlegt, ob ich auf diese Mail antworten soll, > denn sie spricht genau den Hauptpunkt an, warum ich mich bei LibO nicht zu > Hause fühle. > > Am 26.05.11 15:59, schrieb Christian Lohmaier: > >> Hallo Michael, *, >> >> QA kommt nur durch die Personen zustande die die QA durchführen, und >> dann auch von Entwicklern, die die gefundenen Fehler beheben. >> > Da beginnt bereits schon das Problem. 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. Wenn halt mal der entsprechende > Programmierer kein Ohr haben wollte, ging man halt eine oder zwei Etagen > höher rein. Bugfixes sind meist unspektakulär, und der Enduser bekommt > (hoffentlich) nichts davon mit. Somit sind sie für die meisten freien > Entwickler uninteressant. Die Firmen die bei LO mitarbeiten sind alle sammt > Linux Distributionen. Wenn der Bug also auf Linux ist, gibts Chancen dass er > gefixt wird. Aber was, wenn der Bug Windows, oder Mac OS X ist. Bei ganz > ganz groben Sachen hilft da Novell manchmal noch, aber auch eher > Zähneknirrschend. Alle anderen Bugs bleiben einfach liegen. Schau mal in den > Bugtracker, Ihr habt nach etwas mehr als einem Jahr bereits 1800 offene Bugs > rumliegen. Dem gegenüber stehen 1200 gefixte. > > Ohne diskussion, auch bei OOo blieben Bugs offen, Aber im Verhältniss sieht > die Bilanz doch einiges besser aus. > > Bei OOo macht die QA die Community, bei LO macht die QA die Community. >> Bei OOo fixen Oracle-Entwickler die Bugs (in naher Zukunft dann nicht >> mehr), bei LibreOffice die Entwickler aus der Community. >> >> 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. Bei OOo > ist das ein Vergehen gegen den Workflow. Es gibt zum Beispiel keine > Möglichkeit ein Buggy Feature aufzuhalten. Denn es landet direkt im Master. > Der QA hat keine Handhabe gegen den Entwickler, es sei denn es sind ganz > üble Bugs, die können zum Blocker ernannt werden. Aber selbst die kriterien > für einen Blocker sind so schwammig, dass man fast jedem Bug den > Blockerstatus absprechen kann. QA kann man daher für LibO eigentlich gar > nicht machen. Man kann Testen, und Fehler melden, was dann damit passiert > liegt in den Händen der Programmierer. Auf diese Weise kann man die Qualität > nicht sicher stellen. > Bei OOo sass man als QA am längeren Hebel. Wenn man als QA stop rief, dann > war stop, ob das den Programmierer nun passt oder nicht. 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. 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. > > Bei OOo waren die Tests obligatorisch, in den meisten Fällen machten diese > Arbeit Leute aus Hamburg. Diese Tests fanden bereits in den CWS statt, also > bevor es überhaupt im Master landet. Dabei gab es viele Regeln, vielleicht > ein paar zu viele, aber immerhin wurde getestet. Adequate Tests könnte man > bei LibO in den Nightly Builds einbauen. Die erste Beta hat aber bewiesen, > dass sich wohl kaum jemand um diese Builds schährt, geschweige denn noch > ernsthaft testet. Ebenfalls existieren keine Informationen wer was getestet > hat. > > Bei LibreOffice geht man gar nicht erst mit dem Anspruch heran, ein >> "perfektes" Release abliefern zu können, das geht bei einer Software >> bei diesem Umfang einfach nicht, hat es bei OOo nie gegeben, wird es >> auch anderswo nie geben. >> > Mit dieser Einstellung wird man sehr schnell nachlässig: "Wer aufhört > besser zu werden, hört auf zu sein." > > 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. > Bei einem Dicken Bug wartet ein User keinen Monat, er knallt das Ding von > der Platte. Dem ist die Philosophie dahinter so lange wie breit, glaube mir, > das ding muss einfach nur tun. > > Bei OOo hat das Release einen Bug. Und der Nutzer muß dann entweder >> * Zurück zur alten Version >> * selber bauen/dev-builds verwenden >> * warten, warten, warten bis die nächste offizielle Version rauskommt, >> die dann wieder einen anderen dicken Bug hat. >> >> Bei LO ist es >> * Zurück zur alten Version (das ist dann aber kein so großer Sprung >> zurück, weil es häufigere Releases gibt. Man kann von einer 3.3.3 >> zurück zu einer 3.3.2 wechseln, die liegen sowohl Zeitlich als auch >> was die Anzahl der Änderungen im Code betrifft nahe beieinander, bei >> OOo liegt Zeitlich ein riesen-Abstand dazwischen, und dann können auch >> die Änderungen dazwischen mehr oder weniger Umfang haben) >> * selber bauen/dev-builds verwenden >> * Warten, bis neues Release kommt (das kommt bei LO wiegesagt >> schneller als bei OOo) >> >> Und ja, dadurch kann auch mal ein Bug, der bei OOo aus diesen Gründen >> ein Stopper wäre aufs nächste Release verschoben werden. Bei OOo würde >> das dann das komplette Release wochen-monatelang verzögern, bei LO >> bekommen die Nutzer die neuen Features, die Bugfixes in anderen >> Bereichen. Und der eine Stopper-Bug wird halt dann im nächsten >> micro-Release gefixed. >> >> Ich sehe also keine Nachteile in dem geänderten Prozeß. >> Man kann natürlich nur die Fehler fixen, die man auch kennt. Das ist >> bei OOo genauso wie bei LO. >> > Ich weiss, dass man im System von LO keine Nachteile sieht. und deswegen > sehe ich auch keine Möglichkeit zusammen zu Arbeiten. Ich behaupte nicht, > dass das OOo Entwicklungssystem das beste war, und auch für Kompromisse wäre > ich bereit. Aber ich fürchte, dass da kaum Verhandlungsspielraum besteht. > > So und nun habe ich meine Argumente dargelegt. Ich hoffe, niemand damit > persönlich angegriffen zu haben. Nebenbei möchte ich sagen, ich akzeptiere, > wenn man meine Meinung nicht teilt. Aber für mich sind dies Gründe die für > mich persönlich eine Beteiligung bei LibreOffice ausschliessen, ganz > unabhängig ob es bei OOo weiter geht oder nicht. > > > Gruss Raphael > > -- > My private Homepage: http://www.raphaelbircher.ch/ > -- > ----------------------------------------------------------------- > To unsubscribe send email to [email protected] > For additional commands send email to [email protected] > with Subject: help > -- ----------------------------------------------------------------- To unsubscribe send email to [email protected] For additional commands send email to [email protected] with Subject: help
