Moin Thorsten,
Thorsten Behrens wrote:
> Andre hat noch die folgenden konkreten Punkte aufgef"uhrt, bei denen
> Sun entschieden hat, teilweise gegen den erkl"arten Willen der
> Community:
> * Verwendung von Pootle als "Ubersetzungstool
Korrekt. Ich war zwar nicht direkt dabei, aber zumindest ist das nach
meinem Wissensstand sehr stark von Sun forciert worden. Der Wille, hier
auf die Community einzugehen, war vorhanden, es scheint mir aber
fraglich, ob sich das auch im Ergebnis ausdrückt. Ich sage fraglich,
weil ich bisher nur die Aussage eines Beteiligten aus einem einzigen
NL-Projekt kenne. Ich habe keinen Grund, das als Einzelmeinung zu sehen,
ich möchte aber keine voreiligen Schlüsse ziehen, auch, weil mir in
diesem Bereich die Kompetenz fehlt. Also: ja, sieht so aus, ich würde
aber gerne auch noch die Meinung anderer Projekte dazu hören. (André,
ich hoffe, du kannst das so akzeptieren!)
> * zu enge Zeitfenster f"ur die "Ubersetzung
Das hat nicht Sun so "beschlossen", auch diese Themen sind besprochen
worden. Was offensichtlich stimmt, ist, dass von einmal festgelegten
Terminen nicht mehr ohne weiteres abgerückt wird. Halte ich aber erst
einmal für gut: Beschlüsse zu fassen und diese ernst zu nehmen ist ja
gerade das, was du forderst.
Ich sehe aber nicht, warum diese Terminfrage nicht insgesamt überdacht
werden kann, wenn jemand das mal einbringt, z.B. im ESC oder im Release
Status Meeting. Bisher ist das aber nicht passiert. Nicht immer ist ein
Sun-Beschluss Grund dafür, wenn etwas nicht funkioniert. Nach meiner
Beobachtung ist es vor allem die Entwicklung, die mit einem größeren
Zeitfenster für die Lokalisierung ein Problem hat, und nicht nur die von
Sun. Es bedeutet nämlich, dass wir den Feature Freeze für ein Release
noch weiter vorziehen müssen. Das ist ein Punkt, wo gerade die
Nicht-Sun-Entwickler eigentlich eher konträr eingestellt sind. Für mich
ist das kein "Sun vs. Nicht-Sun" Thema, sondern eher eines von
"Entwicklung vs. Lokalisierung". Wenn du das anders siehst, wäre ich
daran interessiert, das erläutert zu bekommen.
> * Effektiv geschlossener CWS-Prozess, d.h. Community kann den
> Prozess nur mithilfe von Sun korrekt durchf"uhren (setzt Sun-
> interne Builds oraus, eines der verwendeten Tools (TCM) ist
> closed-source)
Jein. Ich glaube nicht, dass man CWS-QA nur mit Hilfe von Sun
durchführen (lassen) kann. Deine Kollegen haben uns ja gerade das
Gegenteil gezeigt, und es hat auch in der Vergangenheit CWS gegeben, die
ohne Sun-Mitarbeit "qualitätsgesichert" wurden. Das erfordert aber
natürlich auch, dass man sich drum kümmert.
Dass man für das Durchführen der TCM-Tests Zugriff auf Sun-interne
Builds braucht, ist mir neu gewesen. Daher bin ich erst einmal
vorsichtig damit, das kann auch eine Fehlinformation sein. Thorsten, du
kennst das doch: oft funktionieren irgendwelche Tools nicht, wie es sein
sollte. Dann wird gerne mal statt das Problem zu fixen die einfache
Variante gewählt: "mach es so und so und dann geht es". Also, es scheint
so zu sein, dass das TCM-Testing (manchmal? immer? oft?) nur
funktioniert, wenn man irgendwo in dem Prozess Zugriff auf Sun-Builds
hat. Ob das so sein muss, oder ob das ein Workaround oder irgendwas
anderes ist, muss man noch herausfinden. Wenn es tatsächlich so ist,
dann haben wir ein Problem. Ich sage hier ausdrücklich "wir", weil ich
weiß, dass unsere QA sehr daran interessiert ist, den QA-Prozess so
offen wie möglich zu gestalten, damit eben auch andere hier mitarbeiten
und Verantwortung übernehmen können. Und genau deswegen ist es auch das
Ziel unserer QA, unser eigenes Testing selbst auf Build-Bot Builds
auszurichten (hat mit Thorsten Ziehm gerade noch einmal bestätigt).
Was hier aber unterschlagen wird: TCM ist kein Tool, das benutzt wird,
weil Sun es will. Das wird bei uns selbst z.B. gar nicht verwendet! IIRC
ist das etwas, was zwar von Sun stammt, aber der Community auf Anfrage
zur Verfügung gestellt wurde. Wenn die Community das will, können die
das noch heute in die Tonne kloppen und was anderes verwenden. Nur bitte
nicht immer verlangen, dass das dann von Sun kommen muss.
Niemand schreibt irgendwem vor, dass TCM verwendet wird, das war eine
Entscheidung der L10N-Community. Diese hat auch den kompletten
Freigabeprozess vollständig selbst definiert. Thorsten Ziehm hat zwar
gesagt, dass er einiges anders machen würde, hat aber nicht versucht,
das auch durchzusetzen, sondern sich rausgehalten. Eine andere Meinung
wird er ja noch haben dürfen.
Was immer also da auch schief läuft, das hat nichts mit "Sun-Kontrolle"
oder ähnlichem zu tun.
> Laut Rene hat er sich im ESC gegen die Extensions-Policy
> ausgesprochen.
So habe ich seine Mail hier nicht verstanden und auch nach meiner
Erinnerung hat er sich nicht wirklich in einem Meeting dazu explizit
geäußert. Das spielt aber auch keine Rolle, da wir das Thema ja sowieso
noch einmal diskutieren werden. Allerdings sollte man auch bedenken,
dass diese "Extension-Policy", wie wir sie momentan auslegen, ohnehin
bisher nur für die Sun-Builds gilt. Das Thema hat dann durchaus noch ein
paar Facetten mehr.
>
> Strittig ist nach wie vor:
> * Showstopper-Regeln.
>
> Jedoch schreibt Mathias dazu:
>> Wenn du daraus folgern würdest, dass Regelverletzungen leichter
>> "durchzuschummeln" sind, wenn man einen direkten Draht zur QA hat:
>> ja, das ist möglich.
>>
> Gut. Das bedeutet aber konkret, dass offensichtlich innerhalb von
> Sun jemand ohne Konsultation der Community (in diesem Fall
> stellvertretend die relea...@-liste) Bugs f"ur ein Release abnicken
> kann. Und das ist genau das, was ich meinte, denn es bedeutet *de
> facto* eben nicht, dass gleiches Recht f"ur alle gilt.
Nein, das habe ich nicht geschrieben. Meine Aussage ist so zu verstehen,
dass das, was jeder Entwickler sowieso machen kann, nämlich Code
irgendwo unterzubringen, ohne das von irgendjemandem "abnicken" zu
lassen, viel leichter fällt, wenn man "Beziehungen" hat. Was aber nicht
heißt, dass das auch jemand gemacht hat. Der Witz daran ist ja gerade,
*dass* dann niemand was davon erfährt. :-) Ich wollte nur das
Offensichtliche klarstellen, ohne zu behaupten, dass das auch
tatsächlich jemand tut. Und weil die Nichtexistenz von Beweisen kein
Beweis für Nichtexistenz ist, man also die Existenz nicht ausschließen kann.
Ich verstehe, dass es hier auf jeden Fall ein psychologisches Problem
gibt, weil ja offensichtlich der Eindruck da ist, dass man als
Sun-Entwickler andere Möglichkeiten hat. Nur sehe ich nicht, wie man das
lösen kann. Es gibt ja eine klare Beschlusslage, wenn alle sich daran
halten, hat keiner einen Vorteil. Andererseits kann man die Einhaltung
von Beschlüssung nur schwer durch andere Beschlüsse erzwingen. :-)
Das wird sich ja spätestens dann ändern, wenn auch andere CWS-QA machen.
Dann gilt auch für andere "entdecke die Möglichkeiten". Wie gesagt,
theoretisch eben. Dieser Punkt ist also für mich ein Nicht-Punkt. Macht
eure QA selbst, dann herrscht Chancen-Gleichheit.
Es gibt aber einen Fall, wo wir bei Sun tatsächlich auch Showstopper
fixen, ohne die Community zu befragen, und der ist bekannt und bisher
nicht in Frage gestellt worden.
Glücklicherweise haben wir ja Kunden, und die haben im Rahmen ihrer
Support-Verträge das Recht auf Bugfixes. Wenn irgendwie möglich legen
wir dazu Issues im Issue Tracker an, aber manchmal geht das einfach
nicht und wir tracken das nur im internen System. Und manchmal sind das
auch Showstopper (weil der Kunde das so sieht, und der Kunde hat immer
Recht). Es kann also gelegentlich passieren, dass in einem
Showstopper-CWS im EIS ein "interner Issue" auftaucht. Das ist aber
meines Wissens für jeden erkennbar und war bisher auch für niemanden ein
Problem. Ist AFAIK auch extrem selten.
Unser Problem ist hier, dass "unsere" Builds auch die "offiziellen"
sind. Wir haben also nur die Möglichkeit, das wie bisher zu handeln oder
manche Fixes eben erst einmal z.B. nur in StarOffice einzubauen. Wenn
das dann aber mal bekannt wird, ist das Geschrei auch wieder groß ("Sun
enthält der Community was vor"). Größere Fixes oder gar Enhancements,
die nach Feature Freeze von Kunden angefragt werden, machen wir so
allerdings nicht, diese kommen erst in sogenannte "Release CWS" (aus
denen dann nur dieser Kunde beliefert wird) und erst im nächsten Release
in die normale Version. Das aber für jeden kleinen Showstopper-Fix zu
machen, wäre einfach nicht machbar.
> Einigkeit herrschte beim Problem des Inhouse-Buildsystems, und dem
> Problem, dass Sun-intern inkrementell gebaut wird.
Korrekt.
> Diskutiert, aber aneinander vorbei geredet haben wir bei:
> - Entwicklungsplanung
> * welche Features
> * welche Bugs
> * Deadlines
Wieso haben wir aneinander vorbeigeredet? Du hast einige Behauptungen
aufgestellt, für die ich Gegenbeispiele gegeben habe, den letzten Punkt
sehe ich sogar als widerlegt an. Du kannst also maximal den Fakt, dass
du darauf nicht eingegangen bist, als "aneinander vorbeireden" beschreiben.
Ich würde es lieber so formulieren wollen: du bist noch eine Antwort auf
die deinen Behauptungen widersprechenden Kommentare meinerseits schuldig
geblieben. Da du das aber angekündigt hast, hat es dann ja auch mit dem
"Vorbeireden" erst mal ein Ende. :-)
> * Ausnahmen
Inwiefern unterscheidet sich das von "Showstopper-Regeln"? Ausnahmen
werden genauso behandelt wie diese, nämlich im Release Status Meeting.
Und hier sehe ich auch keinen Vorteil durch "Ortsnähe". Einen kompletten
CWS kann man nicht "reinschummeln", irgendwer muss den nominieren, und
das ist öffentlich sichtbar.
> - welche Platformen supported werden
> - welche Ports man macht (oder eben nicht)
siehe die ersten drei Punkte
> - Fokus der Entwicklung
siehe die ersten drei Punkte
> * Features vs. Bugs vs. Performance vs. API vs. Dokumentation
> vs. Security
siehe die ersten drei Punkte
In Ergänzung dazu möchte ich noch anfügen, dass diese Frage noch niemals
wirklich diskutiert wurde, insofern liegt da auch kein "Beschluss" von
wem auch immer vor. Es hindert euch auch niemand daran, Bugs zu fixen,
die von Sun-Entwicklern nicht gefixt wurden, APIs zu verbessern, Doku zu
schreiben etc. Das ist auch innerhalb unserer Mannschaft ein
kontroverses Thema und es gibt keinen expliziten Beschluss dazu. Es ist
vielmehr bisher in der Regel eine individuelle Entscheidung des
Entwicklers. Für mich passt dieser Punkt nicht in deine Liste, sieht für
mich wie "Füllmaterial" aus.
Für mich liegt das Problem eher darin, dass alle sogar immer *erwarten*,
dass Sun die Richtung vorgibt, selbst wenn wir das gar nicht wollen.
Warum nicht einfach machen und dann andere einbeziehen? Fangt doch an,
verbessert das API, schreibt Dokumentation, sichtet Bugs etc. Was meinst
du, wie schnell dann auch andere, auch von Sun, dabei sind! Muss man für
alles immer erst Beschlüsse fassen? Muss man sich von seinen Zielen
abbringen lassen, nur weil Sun-Entwickler gerade sagen, dass sie selbst
was anderes machen wollen?
> - SCA/Verfasstheit von OOo
> - Prozesse und deren Ausgestaltung
Für mich ist dein Ansatz insgesamt nicht akzeptabel: du präsentierst
hier einen Mischmasch aus richtigen, falschen und teilweise richtigen
Aussagen und ziehst daraus verallgemeinernde Schlüsse. Das hat dann auch
ein Folgeproblem, denn wenn jemand deine verkürzte Darstellung liest,
wird er in der Regel vor allem von den "Signal-Wörtern" (z.B.
"Kontrolle") derart angezogen, dass er diese auch auf Bereiche anwendet,
wo sie gar nicht zutreffen.
Ich würde es daher begrüßen, wenn wir erst eine Bilanz aufstellen und
diskutieren, bevor wir Schlüsse ziehen. Und wie schon wiederholt gesagt:
bitte keine Verallgemeinerungen. Deine Liste ist dafür ein guter Ansatz,
aber nicht, wenn du das Ergebnis darin schon vorwegnimmst. Das zeigt
sich für mich schon darin, dass du Punkte, in denen offensichtlich
Kontroverse herrscht, als "da haben wir aneinander vorbeigeredet"
klassifizierst. Das ist unsachlich.
In diesem Fall bevorzuge ich einfach den Bottom-Up Ansatz. Also, lass
uns Punkt für Punkt ohne Vorurteile durchgehen (muss ja nicht auf dieser
Liste sein, auch ich finde das langsam anstrengend ;-) - warum nicht im
ESC?) und versuchen, gemeinsam festzustellen, woran es liegt, wenn was
nicht funktioniert. Ich habe mir hier viel Zeit genommen und auch sehr
offen geschrieben. Das sollte als Bereitschaftsnachweis doch genügen.
Und lass uns auch nicht aus Einzelmeinungen (so berechtigt sie auch sein
mögen) gleich Fakten ableiten, sondern ggf. auch mehr Informationen
einholen. Wenn wir dann eine fundierte Bilanz gezogen haben, können wir
dann auch eine Zusammenfassung machen. Und wenn es Punkte gibt, wo Sun
zuviel Kontrolle ausübt, lass uns diese benennen, aber nicht in so
pauschaler Form wie von dir in "In der Vergangenheit und gerade auch zum
jetzigen Zeitpunkt versucht Sun aber, die Arbeit am Projekt zu
kontrollieren." ausgedrückt.
Wenn du weiter lieber den Top-Down Ansatz wählst (also dein hier noch
einmal wiedergegebenes Zitat an den Anfang stellst und dann die weitere
Diskussion dem Zweck widmest, das auch nachzuweisen), hat sich das Thema
für mich erledigt.
Also bitte Bottom-Up. Und keine Rekursionen. Rekursiv geht's meistens
schief. :-)
Ciao,
Mathias
--
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't reply to "nospamfor...@gmx.de".
I use it for the OOo lists and only rarely read other mails sent to it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@de.openoffice.org
For additional commands, e-mail: dev-h...@de.openoffice.org
