Hi,
Mathias Bauer schrieb:
...
Nein, das beweist nur, dass Sun-Entwickler das tun, was Sun-Entwickler
tun wollen, Novell-Entwickler das, was Novell-Entwickler wollen etc. Das
klassische "scratch your own itch" eben. Mir ist nicht bekannt, dass das
mit dem Gedanken eines freien Projekts unvereinbar wäre.
Mit dem Konzept eines freien Projektes nicht. Allerdings mit dem
Konstrukt, welche OOo im Moment ist, bzw. sein will:
... eine internationale Gemeinschaft von Freiwilligen und Sponsoren,
allen voran Gründungsmitglied und Hauptsponsor Sun Microsystems.
(So der Abbinder jeder offiziellen Meldung des OOo-Projektes).
An ein derart exponiertes Mitglied, welches allen voran steht habe ich
durchaus den Anspruch, dass es mehr tut, als "ein Sun-Entwickler will".
Nur das zu tun, was man will hat wenig mit Zusammenarbeit im Sinne einer
Community zu tun und sollte auf ein führendes Mitglied nicht zutreffen.
Je größer die Beiträge zum Projekt sind, desto größer auch der Einfluss
im Projekt - das ist nur natürlich. Gleichzeitig wächst aber auch die
Verantwortung für das Gelingen des Projektes und die Entwicklung der
Community.
Letzteres ist aber nur selten spürbar.
Zur Verantwortung für das Gesamtprojekt gehört auch, Prozesse so zu
leben, dass sie für alle passen. Da geht es halt nicht an, dass
build-Fehler auf Mac PPC oder Linux 64bit (gar nicht zu erwähnen die
diversen Ports, die existieren und durchaus funktionieren, sich aber
nicht wirklich für eine enge Zusammenarbeit mit OOo interessieren) mit
der Begründung "Sund baut das nicht" ignoriert werden. Auch in
Werkzeugen, die von Sun zur Verfügung gestellt werden fehlen einfach
entsprechende Bereiche (ich beziehe mich hier auf QA, wo weder in Quaste
noch in TCM entsprechende Plattformen verfügbar sin. QUASTe ist dabei
noch nicht das wirkliche Problem, denn es ist open source, im gegensatz
zu TCM).
Den Vorwurf,
bei seiner Planung nicht vorher andere zu konsultieren, müsstest du dann
auch dir und deinen Kollegen machen. Das würde ihn aus meiner Sicht
nicht sinnvoller machen, aber wenigstens wäre das dann fair play.
Das ist allerdings vollkommen korrekt.
Oh, du missverstehst mich! Du kannst es natürlich ansprechen, so oft du
willst (hast du ja schon :-)). Aber eine "Anwärmung", sprich: eine
Diskussion werde ich nicht mitmachen, weil das nicht meine Baustelle
ist.
Allerdings ist es auch praktisch unmöglich, mit denjenigen direkt zu
diskutieren, deren Baustelle das ist.
Nochmal zum Spruch von oben: "Sun-Entwickler machen was Sun-Entwickler
wollen" passt nicht mit dem Anspruch zusammen "und Sun bekommt die
Rechte an allem".
Aber ok - nicht deine Baustelle.
Ich fasse deine *pauschalen* Vorwürfe als das auf, was sie sind:
Pauschalitäten.
Dann mal von mir ein paar Beispiele - keine "großen" Sachen (bis auf die
letzte), die es aber manchmal schwer machen, die Fahne für Sun hochzuhalten.
Wir hatten arge Startprobleme mit dem Lokalisierungsprozess, zu dem wir
mehr oder weniger gezwungen wurden, weil Sun ihn so für Deutsch
aufgesetzt hat, obwohl wir vorher explizit erklärt hatten "wir wollen
nicht mit Pootle arbeiten". Das hat insbesondere in den ersten
Übersetzungsrunden dazu geführt, dass diejenigen, die bei uns die
Übersetzer "betreuen" selbst mit massiven Probleme zu kämpfen hatten,
wodurch extreme Verzögerungen entstanden. Nachdem wir im direkten
Gespräch nochmal darauf hingewiesen haben und auch darauf, dass einige
Zeitfenster im Prozess einfach zu eng sind bekommt man dann die Antwort
"würden wir das an einen externen Vendor geben, hätte der sogar noch
weniger Zeit zur Verfügung." So eine Antwort motiviert extrem -
insbesondere dazu, in der nächsten Rund die Übersetzer wieder
anzuspornen, dass die Arbeit trotz knappen Zeitrahmens machbar ist
(Gruß an Thomas ;) ).
Was mich persönlich in dem Bereich besonders stört, ist dass unsere
direkte Ansprechpartnerin für die deutsche Lokalisierung bei Sun sich
nie wirklich am Community-Prozess beteiligt hat. Mal angenommen, die
zwei Community-Mitglieder, die regelmäßig die Lokalisierung hier
betreuen fallen weg - Sun wäre nicht in der Lage, diesen wieder zum
Laufen zu bekommen (und müsste wieder ein Übersetzungsbüro beauftragen).
Die Entscheidung über Bugs und Features, die integriert werden, ist
leider nicht ganz so "Sun-unabhängig", wie es oft dargestellt wird. Wir
haben einen recht restriktiven CWS-Prozess, mit sehr ausgeprägter
Qualitätssicherung. An und für sich ok. Das Problem ist allerdings, dass
es ausserhalb Sun nahezu unmöglich ist, diesen korrekt zu befolgen. Es
wird hier viel Wert auf umfangreiche automatische Tests gelegt, um
Regressionen zu vermeiden. Allerdings müssen diese Tests unter
wohldefinierten Bedingungen erfolgen, um überhaupt aussagekräftig zu
sein. Testergebnisse sind in der Regel nur mit Tests aus einem
Sun-Build vergleichbar. Für die Community sind aber builds von
buildbots der einzig sinnvolle weg für CWS-Tests. D.h. im Moment
haben wir einen Freigabeprozess, der weitgehend von Sun definiert wurde,
aber in der Community nur erschwert umzusetzen ist. hier ist z.B. ein
hindernis für mehr Community-Beteiligung - und das auch Sun-QAler
zunächst mal das erledingen, was Sun-QAler wollen ergibts isch mehr oder
weniger automatisch, dass SUN-CWSse leichter integriert werden.
Persönlich habe ich auch den Eindruck, dass es für Sun-CWSse leichter
ist, die Richtlinien zu beugen. Mir ist es nicht verständlich, wie in
einem Bugfix-Release überhaupt ein CWS mit UI-Änderungen integriert
werden konnte. Entweder sind keine UI-Änderungen notwendig, dann macht
man sie nicht - oder es sind UI-Änderungen notwendig, dann macht man sie
dann, wenn sie auch vom Rest der Beteiligten bearbeitet werden können.
Letzter Punkt - und für mich aus Sicht der Projektstrukturen der, der
mir am schwersten im Magen liegt - die Besetzung der
Projektleiterposten. Diese wurde von Michael Meeks bekanntermaßen auch
gern kritisiert. In der direkten Diskussion habe und werde ich immer
darauf hinweisen, dass er sich an die entsprechenden Stellen im Projekt
wenden soll, wenn er mit einem Projektleiter unzufrieden ist. Je weiter
ich hinter die Kulissen blicke scheint aber wirklich bei Sun die Meinung
zu bestehen, dass zunächst Sun Mitarbeiter Projektleiter werden sollten
(das QA-Projekt möchte ich hier mal explizit ausnehmen). Wenn ich dann
noch im direkten Gespräch mit Council-Mitgliedern die Ansicht
präsentiert bekomme "Projektleiterposten wurden bei Projektgründung
besetzt - das hat auch einen Grund und da lassen wir uns nicht
reinreden" wird mir übel.
Ich habe hier schon einige Diskussionen geführt, dass das OOo-Projekt
nicht vollständig demokratisch organisiert ist und auch nicht
vollständig demokratisch organisiert werden kann - aber ein bisschen
mehr Basar oder mehr Bewegung in der Kathedrale würde ich sehr begrüßen.
Gruß,
André
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@de.openoffice.org
For additional commands, e-mail: dev-h...@de.openoffice.org
