Hi Raphael, *, Du weichst der eigentlichen Frage immer noch aus, aber sei's drum. War halt wieder viel Wind um nix.
2011/4/20 Raphael Bircher <[email protected]>: > Am 20.04.11 16:01, schrieb Christian Lohmaier: >> 2011/4/20 michael<[email protected]>: >>> Christian Lohmaier schrieb: >>>> 2011/4/20 Jörg Schmidt<[email protected]>: >>>>> [email protected] schrieb: >>> [LO Beta1] >> >> Das hat nix mit technischer Infrastruktur zu tun. Das ist ein >> personelles Versehen/Unachtsamkeit. Aber wiegesagt kein Beinbruch, die >> nächste Iteration steht schon in den Startlöchern, dann auch mit >> aktualisierten Übersetzungen, etc. > > Wem bitte willst du die schuld dafür in die Schuhe schieben? Schuld ist das falsche Wort, aber Verantwortlich dafür, daß man zumindest überprüft ob sich die Builds über den normalen Installationsprozeß installieren lassen sind diejenigen Personen, die die Builds letztendlich zur Verteilung auf den Server hochladen. > Sorry > Christian, das ist kein persönliches Versagen, sondern die konsequenzen aus > unzureichenden Workflows. Ja klar, und wer arbeitet solche Workflows ab? Deine Katze? > [...] Die einzige "Qualitätsbedingung" die ihr stellt, > ist dass der Code compillieren muss. Was Du hier schreibst ist einfach Quatsch. > Und genau da liegt ein riesiger Unterschied zwischen OOo und LibO. OOo hat > diverse obligatorische Tests, und diverse Stellen, wo die Notbremse gezogen > werden kann. Bei LibO gibt es diese Mechanismen fast gar nicht. Wie kommst Du denn auf sowas? Es gibt genau wie bei OOo einen entsprechenden Sammel-Bug für Blocker. Es gibt genauso wie bei OOo eine Mailingliste auf der man entsprechende Probleme melden kann. > Der Hauptgrund für diese Politik ist wohl, dass Novell kein Geld für QA's > haben will. Noch 'ne Märchenstunde... Was hat Novell damit zu tun? > Deshalb versucht man das QA auf die Community abzuwälzen. Ahäm, der Unterschied ist, daß bei TDF /alle/ "die Community" sind. Da gibt es nicht "Oracle und den Rest", es ist nicht "Novell und die anderen". > Um die > Entwicklung nicht zu bremsen weigert man sich, eine gewisse obligatorische > Qualitätssicherung einzubauen. Christian, du bist schon lange bei OOo, hast > du in der ganzen Zeit eine nicht funktionierende Beta erlebt. Ja, klar gab katastrophale pre-releases. Die redet man sich (und anderen) auf Messen, etc. dann natürlich schön. Und die waren genau nach dem Muster "hätte das wer installiert und gestartet, dann wäre das aufgefallen". Bei OOo fängt man ja traditionellerweise immer mit der "nächsten" Sufe an, sprich man läßt eine eigentlich nötige Beta aus und startet gleich mit RC (deshalb braucht man dann am Ende auch 8 Stück). > Ausserdem ist dieser Vorfall ja nur das Tüfchen auf dem i. Zur 3.2 gab es > den nicht funktionierenden Serienmail Versand, der abstürzte, war bekannt > wurde aber nicht gefixt. Dann die kuriose Entscheidung, die Binfilter für > alte StarOffice Files zu entfernen. Wieder Schwachsinn gemischt mit FUD. Binfilter zu entfernen ist auch bei OOo schon lange ein Thema, mach doch mal die Hausaufgaben. Und von Entfernen ist bei LO noch nicht die Rede, erstmal wird der Schreib-Support verschwinden, aber lesen kann man die Dokumente dann trotzdem noch. > Ausser politischen Motiven fällt mir > dazu kein passendes Argument ein. Es gab Protest von Usern, aber Novell > schien das egal. Novell kritisierte SUN über Jahre, eigenmächtig zu handeln, > macht aber bei LO genau das selbe. Nicht gerade sehr Vorbildlich. Das ist Dummfug. Verlaß Dich nicht auf Informationen, die Dich über 20 Ecken erreichen. > Ein Problem ist auch, dass man als QA gar keine Veto Möglichkeit hat. Auch das ist kompletter Unfug. Bei LO hat man einen kürzeren Draht, da hat man erst Recht die Möglichkeit zum Veto (bzw. die Chance gehört zu werden ist größer) > Bei > OOo est es für ein gestandenen QA relativ leicht etwas zu blocken. Sorry, aber man könnte fast meinen, du hast von QA im OOo Projekt auch nicht so wirklich Ahnung. Zugegebenermaßen ist das in den Letzten Jahren immer besser geworden, aber "relativ leicht", darüber kann ich nur lachen, nicht wenn man "nur" aus der Community kommt. Nach 10 Jahren OOo war der Prozeß soweit. Und jetzt nach noch nichtmal einem Jahr TDF kommt sowas? Da kann ich nur den Kopf schütteln. Der Prozeß bei OOo funktioniert nur, weil sich langjährige Community Mitglieder dafür aufopfern. Du hast nur das Bild vom letzten Jahr im Kopf, ich auch die 10 Jahre davor. Bis zu dem jetzigen Release Prozeß bei OOo war es ein /sehr/ langer und auch sehr steiniger Weg. > Da > grundsätzlich in CWS entwickelt wird, hat der QA ein Druckmittel. "Entweder > du fixt das noch, oder dein CWS kommt nicht durch." Ja, und beim nächstem mal macht jemand die QA der sich nicht drum schert. Aber darüber kann ich wirklich nur lachen. Was glaubst Du, wie oft ich in EIS einen Kommentar hinterlassen habe müssen weil die Änderungen nicht kompilieren. Und das als der CWS schon auf approved oder nominated stand. Und rate mal wie beliebt das bei den beteiligten Personen war. Schau nur mal auf Tinderbox, wie es jetzt ist, ohne daß man nachhakt ist. Buildbots so gut wie alle tot oder fehlgeschlagen, bei Mac tinderbox ist es auch Glückssache ob der MWS baut oder nicht. Schert aber keine Sau mehr. Früher hab ich den Fehlern hinterhergejagt und entsprechend Leute genervt (nur um dann immer hinterher sagen zu können "hab ich doch gesagt"). Klar gibts auch hier Ausnahmen, die die Regel bestätigen. Aber um das nochmals zu betonen: Es war ein sehr weiter weg zum jetzigen Release-Management bzgl. Blocker issues. Mal abgesehen davon, daß die CWS-Handhabe einer der Ursachen der Qualitätsprobleme mancher OOo-Releases waren. Da parken CWS für Wochen und Monate und nix tut sich am status, dann ist Codefreeze und auf alle Fälle wollen 50 CWS auf einmal integriert werden. Macht man dann auch und dann wundert man sich, daß in den Builds ohne die 50 integrierten CWS noch alles funktioniert hat... Und ja, auch das ist kein technisches, sondern ein administratives Problem. CWS an sich sind nicht schlecht, aber wenn es dann darauf hinausläuft, daß am Tag vor Codefreeze noch zig Änderungen, womöglich auch noch ein komplett neues Feature reinkommt, dann ist der ganze Vorteil, der ein seperates Testen bringt dahin. > Bei LibO hab ich nichts > dersgleichen. Ich kann nur hoffen dass mich ein Programmierer ernst nimmt. > QA hat deshalb auch gar keinen Reiz, da man eigentlich völlig machtlos ist. Wieder kann ich nur sagen: So ein Schmarrn. > Der Fehler der beta 3.4 war übrigens schon in Nightly builds vorher, was > darauf schliessen lässt, dass fast niemand die Nightly Builds benutzt. Wie ich schrieb, sind die relativ neu. Und ja, die benutzt (noch) kaum einer. Zum einen, weil viele selber bauen, zum anderen weil die Leute noch nix davon wissen. Wieviele Nutzen denn die OOo-Dev-Milestones? > Wenn > das alles nicht nachdenklich stimmt, und fragen aufwirft, dann kann ich auch > nicht mehr helfen. Ja, manchen Leuten ist halt nicht mehr zu helfen. > Ich sage nicht, dass bei OOo alles perfekt lief, ganz und gar nicht, aber > ich finde es auch ziemlich fahrlässig, wenn LibO alle Vorfälle als > Einzelfälle abtut und verharmlost. Aber eben, das ist meine Meinung, und ich > fürchte dass die viele nicht teilen. "alle Vorfälle", genau dieser einer Vorfall, der ist zwangsläufig ein Einzelfall. ciao Christian -- ----------------------------------------------------------------- To unsubscribe send email to [email protected] For additional commands send email to [email protected] with Subject: help
