Re: [de-dev] Absturz Base 2.3.0

[Eric Hoch]

Hallo Guido, 
Am Fri, 7 Sep 2007 00:18:37 +0200 (CEST) schrieb Guido Ostkamp:
> Hallo Martin,
> 
>> Das immer wieder neu Auflegen eines release candidate 
>> verschlingt auch resourcen ohne Ende in den QA Teams und an 
>> anderen Stellen haben wir Abhaengigkeiten (releases von 
>> Linuxdistros, press releases, security patches) die nicht ein 
>> Schieben mit offenem Ende erlauben.
> 
> zusammengefaßt kann man daraus doch nur eines ableiten: Termin 
> geht vor Qualität - sehr bedauerlich.
> 
> Wenn schon beim Test des ersten(!) RC die Meinung vertreten wird, 
> daß Korrekturen nun wg. Termindrucks nicht mal für Crashes, die 
> außerdem noch eine Regression darstellen, mehr drin sind, frage 
> ich mich ernsthaft, wozu man die RCs dann überhaupt macht.

Irgendwann müssen wir Releasen, jede QA wird Fehler finden und so 
kommt OOo 2.3.0 nie raus.

Glaub mir 2.3.0 fühlt sich auch für mich irgendwie schwammig an und 
wir suchen schon den Showstopper der sie aufhält und uns mehr Zeit 
verschafft, nur den gibt es nicht und die vielen kleinen Gefühle 
und Issues, dass es bei der 2.3.0 irgendwas gibt, was wir 
übersehen, sind nur Bauchgefühle und keine Showstopperissues, die 
es wirklich erlauben, die 2.3.0 noch x Runden in der QA drehen zu 
lassen.

Weiter hat jeder RC die unangenehme Folge, dass es mit jedem RC 
immer weniger Tester werden. Ich weiß nicht zu welcher 2.x oder ob 
es noch zu 1.1.x Zeiten war, als wir mal 1x RCs hatten, das hat uns 
auf dem Mac nahezu alle Tester gekostet und am Ende hatten wir zwar 
alle Showstopper raus, aber der Ruf war ruiniert. 

Und nochmal: Du bist herzlich willkommen in der QA und darfst auch 
gerne im Release Meeting Deine Meinungen kund tun. 

Gruß
Eric

-- 
## de.OpenOffice.org - Office für MacOS X, Linux, Solaris & Windows
## Openoffice.org - ich steck mit drin!

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [de-dev] Absturz Base 2.3.0

[André Schnabel]

Hi,

Guido Ostkamp schrieb:

Hallo Martin,

Das immer wieder neu Auflegen eines release candidate verschlingt 
auch resourcen ohne Ende in den QA Teams und an anderen Stellen haben 
wir Abhaengigkeiten (releases von Linuxdistros, press releases, 
security patches) die nicht ein Schieben mit offenem Ende erlauben.


zusammengefaßt kann man daraus doch nur eines ableiten: Termin geht 
vor Qualität - sehr bedauerlich.


Sorry,solche unsinnigen Behauptungen sind vollkommen deplaziert. Wenn du 
wirklich der Meinung bist, dass die Qualität bei OOo so katastrophal ist 
und das die Meinung mehrerer Anwender und Entwickler ist - mach eine 
Qualitätsfork. Das ist der Sinn von Open Source.


Im gegebenen Fall sogar einfach: einfach den Patch integrieren undneu 
bauen. Ich hätte aber so 10-20 Issues die ich auch gerne gefixed haben 
würde (zum teil liegen Patches vor). Nimmst  du die dann auch mit rein?


André

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [de-dev] Absturz Base 2.3.0

[André Schnabel]

Hi Guido.

Guido Ostkamp schrieb:


sorry, Andre. Ich kann mir beim besten Willen nicht vorstellen, daß es 
eine Woche geschweige denn "mehrere Mannwochen" dauern soll, eine neue 
OOo Version zu produzieren, wenn ein Entwickler eine wenige Zeilen 
umfassende Sourcekorrektur für ein bestimmtes Problem bringt und ein 
durchcompilierter Sourcetree bereits vorliegt, in dem dann bloß ein 
File neu zu übersetzen ist und noch ein paar Relinks und neue 
Paketierung stattfinden.


Meine eigene Erfahrung mit einer lokalen Linux-Produktion, in die ich 
bspw. einen existierenden Patch rückportiert hatte, beweist mir das 
Gegenteil.


Meine Erfahrung mit den Prozessen bei OOo ist aber die, die ich 
geschildert habe. Wenn du es ohne diesen Aufwand kannst, würde ich 
empfehlen, du übernimmst das Releaseengineering und strukturierst die 
Prozesse um. Es wären dir viele Leute dankbar, die dann Zeit für andere 
Sachen haben.




Oder fängt bei Sun die Produktion einer Version jedesmal wieder bei 
Null an?
Sun ist nur ein TEil. Es geht um  Sun. Novell, Pavel Janik, Nakata Maho, 
jede Linuxdistributon (die selbst schon zum Test die rcs gebaut hat), 
Dienstleister, die ebenfalls für eigene Tests RCs gebaut haben und deren 
entsprechende QA.


Wir sitzen hier an der Quelle für ca. 70 Sprachen und (keine Ahnung, 
wieviel genau ... 15 Plattformen / Paketformate). DAs ist etwas anderes, 
als eine lokale Änderung, die den eigenen Betrieb betrifft.


André


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [de-dev] Absturz Base 2.3.0

[Eric Hoch]

Hallo Guido, 
Am Fri, 7 Sep 2007 00:02:45 +0200 (CEST) schrieb Guido Ostkamp:
>> Warum wird der Fix nicht sofort integriert: ganz einfach .. es 
>> bedeuted eine weiter Runde:
>> - fix in cws integrieren
>> - cws testen
>> - cws in Master integrieren
>> - master bauen und alle relevanten Versionen als rc hochladen
>> - master testen
>> 
>> Das ist eben nicht nur ne weitere Woche Verzögerung sondern auch 
>> einige Mannwochen Arbeit. (Die man auch für andere Sachen 
>> verwenden kann).
> 
> sorry, Andre. Ich kann mir beim besten Willen nicht vorstellen, 
> daß es eine Woche geschweige denn "mehrere Mannwochen" dauern 
> soll, eine neue OOo Version zu produzieren, wenn ein Entwickler 
> eine wenige Zeilen umfassende Sourcekorrektur für ein bestimmtes 
> Problem bringt und ein durchcompilierter Sourcetree bereits 
> vorliegt, in dem dann bloß ein File neu zu übersetzen ist und 
> noch ein paar Relinks und neue Paketierung stattfinden.

Wenn es so einfach ist, dann schreib den Patch und wir erwarten 
morgen früh Pakete für Linux, Windows, Solaris, Mac OS X X11 und 
die entsprechenden Languagepacks auf den Mirrorservern, damit wir 
mit dem Testen anfangen können. Also fang an. Die Zeit läuft. 

 Ach stimmt ja, die Entwickler bei Sun nichts anderes zu 
tun, wie jetzt den Patch für Dein Problem zu testen und alles 
andere stehen und liegen zu lassen.  

> Meine eigene Erfahrung mit einer lokalen Linux-Produktion, in die 
> ich bspw. einen existierenden Patch rückportiert hatte, beweist 
> mir das Gegenteil.
> 
> Oder fängt bei Sun die Produktion einer Version jedesmal wieder bei Null an?

Klar, du musst um auf Nummer sicher zu gehen, jedesmal wieder, auch 
wenn Du ccache nutzt, ein dmake clean machen und dann komplett neu 
kompilieren. 

Ich hab gestern m4 auf nem CoreDuo unter Mac OS X kompiliert, der 
ccache war noch vom m3 am Tag vorher relativ "hot", trotzdem hat es 
für fünf Sprachen knapp 4h 30 gedauert. Hochgerechnet auf ich meine 
8 Sprachen sind es die Sun anbietet, plus language packst und so 
weiter bin ich locker bei 8h oder sogar 12h und mehr - und das auf 
nem CoreDuo! mit 1,25GB RAM. Jetzt nimm mal einen etwas älteren 
Prozessor und Du bist schon locker bei 16h oder mehr Buildtimme - 
aber das ist einer der Zeitfresser.  

Jeder Patch muss auf jeder Plattform, also Windows, Linux, Solaris 
und Mac OS X geprüft werden - wir haben schon mit manch einem Patch 
für OS X einen Buildbreaker unter Windows produziert. Jetzt nehm 
mal an, dass ein Kompilieren ca. 5h dauert, dass macht dann bei 4 
Plattformen schon 20 Stunden. 

Das ganze Prozedere mit dem Kompilieren muss aber minimum zweimal 
ablaufen einmal zum Erstellen der Pakete die verteilt werden und 
zuvor noch der Build in dem der cws integriert ist. 

Die automatischen und händischen Tests um zu verifizieren, dass der 
Bug nicht mehr da ist, dauern auch ein Weilchen. cws resync ist 
auch nicht mal eben in fünf Minuten getan. 

Also zwei, drei Arbeitstage minimum sind das schon einen Fix den 
Master und von da in OOG zu bekommen. 

> Wenn das Problem auf einen ganz bestimmten Fall beschränkt ist, 
> braucht deshalb auch nicht unbedingt der komplette QA-Test 
> wiederholt zu werden.

Herzlich Willkommen im QA Team. Auf geht's trag Dich für die noch 
freien Plattformen ein 
. 
Jeder Tester ist willkommen und so schwer ist es ja Deiner Meinung 
nach nicht und ganz schnell getan ist, schreibst du ja selber, 
auch. 

Gruß
Eric 

-- 
## de.OpenOffice.org - Office für MacOS X, Linux, Solaris & Windows
## Openoffice.org - ich steck mit drin!

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [de-dev] Absturz Base 2.3.0

[Guido Ostkamp]

Hallo Martin,

Das immer wieder neu Auflegen eines release candidate verschlingt auch 
resourcen ohne Ende in den QA Teams und an anderen Stellen haben wir 
Abhaengigkeiten (releases von Linuxdistros, press releases, security 
patches) die nicht ein Schieben mit offenem Ende erlauben.


zusammengefaßt kann man daraus doch nur eines ableiten: Termin geht vor 
Qualität - sehr bedauerlich.


Wenn schon beim Test des ersten(!) RC die Meinung vertreten wird, daß 
Korrekturen nun wg. Termindrucks nicht mal für Crashes, die außerdem noch 
eine Regression darstellen, mehr drin sind, frage ich mich ernsthaft, wozu 
man die RCs dann überhaupt macht.


Gruß

Guido
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [de-dev] Absturz Base 2.3.0

[Guido Ostkamp]

Warum wird der Fix nicht sofort integriert: ganz einfach .. es bedeuted eine 
weiter Runde:

- fix in cws integrieren
- cws testen
- cws in Master integrieren
- master bauen und alle relevanten Versionen als rc hochladen
- master testen

Das ist eben nicht nur ne weitere Woche Verzögerung sondern auch einige 
Mannwochen Arbeit. (Die man auch für andere Sachen verwenden kann).


sorry, Andre. Ich kann mir beim besten Willen nicht vorstellen, daß es 
eine Woche geschweige denn "mehrere Mannwochen" dauern soll, eine neue OOo 
Version zu produzieren, wenn ein Entwickler eine wenige Zeilen umfassende 
Sourcekorrektur für ein bestimmtes Problem bringt und ein 
durchcompilierter Sourcetree bereits vorliegt, in dem dann bloß ein File 
neu zu übersetzen ist und noch ein paar Relinks und neue Paketierung 
stattfinden.


Meine eigene Erfahrung mit einer lokalen Linux-Produktion, in die ich 
bspw. einen existierenden Patch rückportiert hatte, beweist mir das 
Gegenteil.


Oder fängt bei Sun die Produktion einer Version jedesmal wieder bei Null 
an?


Wenn das Problem auf einen ganz bestimmten Fall beschränkt ist, braucht 
deshalb auch nicht unbedingt der komplette QA-Test wiederholt zu werden.


Gruß

Guido
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [de-dev] Re: Aktuelle Aufgaben im Marketing

[Heinz W. Simoneit]

Hallo Marko,


Marko Moeller schrieb:
> Hallo @all,
> habe jetzt noch schnell mein Versprechen eingelöst und die Grundstruktur
> (ohne neue Inhalte) für die Marketing-Seiten umgesetzt und validiert.

sorry, aber wo finde ich (bzw. Thomas) die?

Gruß
Heinz

-- 
Have a nice time!


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [de-dev] Absturz Base 2.3.0

[André Schnabel]

Hi,

Thomas Krumbein schrieb:

Hey,

André Schnabel schrieb:
[..]
  
Das kann ich doch aber auch bei einem normalen Einfügen .. oder übersehe 
ich jetzt was?



Nein. Du übersiehst nichts - das ist auch ein Weg :-)

...
Wird deine Entscheidung nicht leichter machen - aber ich würde nicht zu
viel "Kraft" investieren.
  


Doch, das macht sie erheblich einfacher. Den crash finde ich 
selbstverständlich sehr ärgerlich. Alleridngs finde ich es 
wahrscheinlicher, dass jemand mit dem normalen "Einfügen" arbeitet, 
statt mit Inhalte-Einfügen. Wenn letzteres keinen  wirklichen Mehrwehrt 
bietet, ist die Funktionalität ja  trotzdem zugänglich.


Insofern kann mit dem Target 2.3.1 leben.

Warum wird der Fix nicht sofort integriert: ganz einfach .. es bedeuted 
eine weiter Runde:

- fix in cws integrieren
- cws testen
- cws in Master integrieren
- master bauen und alle relevanten Versionen als rc hochladen
- master testen

Das ist eben nicht nur ne weitere Woche Verzögerung sondern auch einige 
Mannwochen Arbeit. (Die man auch für andere Sachen verwenden kann).


André

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [de-dev] Absturz Base 2.3.0

[Martin Hollmichel]

Thomas Krumbein schrieb:

Aber ich habe es schon gelesen: Man wird eine Freigabe druchdrücken,
obwohl es ja wohl schon eine Lösung gibt - nur um den Build vor der
Konferenz fertig zu haben. Na ja, der Markt wird damit leben können ...

  
Es ist leider so, dass wir bei einem release immer known issues haben 
werden, mit denen wir leben muessen. Der Versuch, alle dieses issues zu 
beseitigen, wird in einem immer groesseren delay enden. Die Situation 
ist fuer alle Beteiligten nicht befriedigend. Das immer wieder neu 
Auflegen eines release candidate verschlingt auch resourcen ohne Ende in 
den QA Teams und an anderen Stellen haben wir Abhaengigkeiten (releases 
von Linuxdistros, press releases, security patches) die nicht ein 
Schieben mit offenem Ende erlauben. Wir im release status meeting 
muessen damit leben, dass ein Ausgleich der verschiedensten Interessen 
stattfinden muss und das dabei immer Traenen fliessen. Wir machen uns 
die Entscheidungen auch gewiss nicht leicht, allein die Laenge der 
Diskussionen zeigt, dass wir uns ernsthaft mit den verschiedenen 
Argumenten auseinandersetzen.
In einer unserer meeting haben wir uns auch bereits mit einer Analyse 
der Situation auseinander gesetzt, ein Resultat davon ist, dass Du bei 
den timelines fuer das Release der 2.4 und 3.0 schon weitaus groessere 
Zeitraueme zwischen den deadlines fuer Entwicklung und dem Release 
siehst. Ich gebe mich jedoch nicht der Illusion hin, dass dieses ein 
release mit Fehlern verhindert.

Fuer konstruktive Hinweise ist das Releaseteam sicherlich offen,

Gruss
Thomas

  

Martin


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [de-dev] Absturz Base 2.3.0

[Thomas Krumbein]

Hey,

André Schnabel schrieb:
[..]
> Das kann ich doch aber auch bei einem normalen Einfügen .. oder übersehe 
> ich jetzt was?

Nein. Du übersiehst nichts - das ist auch ein Weg :-)

> Danke für die Aufmunterung. Ich frage genau deshalb, weil ich mich nicht 
> an Konferenz oder Marketingargumente halten will sondern an die 
> Anforderungen der Anwender ..und dafür brauch ich Argumente.

> Aber wenn man die Diskussionen des Release Engineerings als Gottgegeben 
> akzeptiert dann schafft man sich irgendann selbst den Markt, der "damit 
> leben kann" (bzw. beschränkt man sich auf genau auf diesen Markt).

Es bringt aber auch nichts, jetzt lange "Gefechte" wegen dem Fehler
durchzuführen. Die Kraft brauchst du vielleicht noch woanders. Es gibt
ja einen Weg, es dennoch einzufügen - ist also nicht essentiell - nur
ärgerlich, wenn OOo "abschmiert".
Wieviel wirklich da draußen mit der Funktion arbeiten, kann ich dir
nicht sagen - nur auch wenige können laut schreien.
Und wenn etwas schon  mal funktioniert hat - und dann nicht mehr, finde
ich das immer ärgerlich. Wenn es dann auch noch offensichtlich eine
"einfache" Lösung gibt (der Issue war ja sehr schnell wieder
geschlossen) dann bleibt doch die Frage, warum man es nicht auch
einbaut. Aber es gibt halt auch andere Sichtweisen - ich komme ja vom
Marketing. Also, ich denke, man kann damit leben - auch wenn ich es
persönlich schade finde.
Ich kann dir also keine "echten" Argumente liefern, warum nun gerade
dieser Fehler gefixt werden sollte, da gibt es einfach auch noch
andere., vielleicht wichtigere.
Speziell in Base: Ich persönlich finde den Fehler Issue 81294
tragischer, auch wenn dieser wahrscheinlich seltener im Markt auftritt
(da muss man nämlich schon ziemlich viel Verständnis für
Base/Datenbanken/SQL haben, um mit den angezeigten Fehlermeldungen
überhaupt etwas anfangen zu können. Nur wer das kann - für den ist das
fürchterlich ärgerlich.
Aber so ist das: Keine Software wird fehlerfrei sein - und dann gilt es
eben, Kompromisse zu schliessen.

Wird deine Entscheidung nicht leichter machen - aber ich würde nicht zu
viel "Kraft" investieren.

Viele Grüße
Thomas




-- 
## Marketing deutschsprachiges Projekt
## http://de.openoffice.org  - www.openoffice.org
## Vorstand OpenOffice.org Deutschland e.V.
## Mitglieder willkommen: www.OOoDeV.org

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [de-dev] Absturz Base 2.3.0

[André Schnabel]

Hi,

Thomas Krumbein schrieb:


Eine Verständnisfrage: was ist in diesem Fall die Besonderheit von 
"Inhalte einfügen" und wie wichtig ist es, dass genau diese Funktion zur 
verfügung steht?



Hmm, ist der Weg, eine Tabelle einer Datenbank in eine andere Datenbank
einzufügen. So kannst du z.B. eine Calc-Datei in eine HSQLDB
"überführen" und so auch Daten eingeben - da jettz ein Primärschlüssel
gewählt werden kann.
  
Das kann ich doch aber auch bei einem normalen Einfügen .. oder übersehe 
ich jetzt was?




Aber ich habe es schon gelesen: Man wird eine Freigabe druchdrücken,
obwohl es ja wohl schon eine Lösung gibt - nur um den Build vor der
Konferenz fertig zu haben. Na ja, der Markt wird damit leben können ...
  


Danke für die Aufmunterung. Ich frage genau deshalb, weil ich mich nicht 
an Konferenz oder Marketingargumente halten will sondern an die 
Anforderungen der Anwender ..und dafür brauch ich Argumente.


Aber wenn man die Diskussionen des Release Engineerings als Gottgegeben 
akzeptiert dann schafft man sich irgendann selbst den Markt, der "damit 
leben kann" (bzw. beschränkt man sich auf genau auf diesen Markt).


André

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [de-dev] Absturz Base 2.3.0

[Thomas Krumbein]

Hey André,

André Schnabel schrieb:
[..]
> Eine Verständnisfrage: was ist in diesem Fall die Besonderheit von 
> "Inhalte einfügen" und wie wichtig ist es, dass genau diese Funktion zur 
> verfügung steht?

Hmm, ist der Weg, eine Tabelle einer Datenbank in eine andere Datenbank
einzufügen. So kannst du z.B. eine Calc-Datei in eine HSQLDB
"überführen" und so auch Daten eingeben - da jettz ein Primärschlüssel
gewählt werden kann.

Es ist halt "ein" Weg - nicht unbedingt der einzigste.

Aber: Mir ist es auch mehrmals gelungen, den Absturz zu erzeugen, wenn
du "Inhalte einfügen" z.B. in einer Writer-Datei versuchst - und das ist
ein Weg, eine Tabelle zu drucken (formatiert), und zwar der einfachste.
Allerdings konnte ich es da nicht sicher reproduzieren - es trat eher
"zufällig" auf. Dennoch hängt es wahrscheinlich mit dem selben Problem
zusammen. Es ist auf jedenfall ein deutlicher "Rückschritt" zu
bisherigen Versionen (da gab es diese Verhalten nicht) und führt sicher
nicht zur Akzeptanz der sowieso schon "schwächsten" Komponente.

Aber ich habe es schon gelesen: Man wird eine Freigabe druchdrücken,
obwohl es ja wohl schon eine Lösung gibt - nur um den Build vor der
Konferenz fertig zu haben. Na ja, der Markt wird damit leben können ...

Gruss
Thomas

-- 
## Marketing deutschsprachiges Projekt
## http://de.openoffice.org  - www.openoffice.org
## Vorstand OpenOffice.org Deutschland e.V.
## Mitglieder willkommen: www.OOoDeV.org

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [de-dev] Absturz Base 2.3.0

[André Schnabel]

Hi,

Thomas Krumbein schrieb:

wenn man in Base eine Datenbank erzeugt oder öffnet, dort dann eine
Tabelle kopiert, jetzt in eine andere Datenbank wechselt und dann aus
dem Kontextmenü "Inhalte einfügen" wählt, "semmelt" OOo gnadenlos ab.
Nur über "Einfügen" geht es übrigens :-)

Wenn sich das bestätigt, wäre das m.A. ein Stopper.
  


Eine Verständnisfrage: was ist in diesem Fall die Besonderheit von 
"Inhalte einfügen" und wie wichtig ist es, dass genau diese Funktion zur 
verfügung steht?


André

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [de-dev] OOo_2.3.0rc1 & Issue #4032

[André Schnabel]

Hi,

Jörg Schmidt schrieb:


Aus den bekannten Veröffentlichungen zu Tests(**) wie gut die Standards
eingehalten werden, kann ich nicht erkennen das OOo seinen Vorlauf
adäquat genutzt hätte so ich nicht sehe das OOo merklich besser als
KOffice dasteht.
  

Na ja .. ein einfacher "Selbsttest" würde das schon schnell belegen.
Aber zu den angeführten Tests: es gab dazu eine Diskussion auf der 
Projekt-Leads-Liste (die leider dort und nicht auf einer öffentlichen 
Liste gelandet ist, da der Aufhänger eigentlich ein ganz anderer war). 
Ich finde den thread jetzt nicht, deshalb aus der Erinnerung zitiert:
Die diskussion fand hauptsächlich zwischen "unseren" XML-Spezialisten 
und einem Entwickler aus dem KDE-Projekt statt, der auch an der 
entwicklung der Testsuite beteiligt war. Nach einigem Hin-und her war 
man sich einig, dass die Testsuite selbst durchaus verbesserungswürdig 
ist und in einigen Fällen OOo schlechter bewertet wurde, als es 
tatsächlich ist. Frag mich  nicht, wie es zusatende kommen konnte, aber 
einige Tests fielen für OOo negativ aus, obwohl ein kurzer manueller 
Test ergeben hätte, dass die entsprechenden Bereiche korerkt umgesetzt sind.


Endergebnis: Überarbeitung der Testsuite und natürlich weitere 
Verbesserung der ODF-Kompatibilität.


Achos .. gegenüber KOffice haben wir übrigens auch keine so großen 
Vorsprung. KDE war ebenfalls an der Spezifikation beteiligt und hat 
viele Anforderungen eingebracht.


Unabhängig davon, bleibe ich bei meinem "noch etwas traurig" .. da mir 
der Aufhänger der o.g.  Diksussion wieder einfällt.  Microsoft legte  
diese  Ergebnisse beim Franz. Parlament als Argument gegen ODF vor :-(


André

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [de-dev] OOo_2.3.0rc1 & Issue #4032

[Jörg Schmidt]

Mathias Bauer schrieb:
> > Ich finde sowas als Standardoption kontraproduktiv. (iehe
> Begründung von
> > Jörg).
> >
> > Da, woran gearbeitet werden sollte - und was wirklich jedem etwas
> > bringen würde ist die korrekte und vollständige Implementierung des
> > ODF-Standards. (Mit der esim Moment leider noch etwas
> traurig aussieht).
>
> "Traurig" finde ich etwas übertrieben.

Ich nicht, diese Formulierung ist m.E., der existierenden Situation,
angemessen.

ODF wird sich in dem Maße durchsetzen wie es allen Programmen die es
unterstützen gelingt es richtig abzubilden, hier hat OOo zugegeben keine
besondere Verantwortung im Vergleich zu  anderen Programmen, aber:

> Immerhin zeigt die
> Tatsache, dass
> auch OOo noch nicht alles korrekt umsetzt, dass die
> Behauptung, ODF sei
> einfach nur das OOo-Format, unsinnig ist.

Nein, das zeigt sie im angedeuteten Sinne nicht, denn es könnte so sein
oder es könnte nicht so sein, die Tatsache das die Implementierung nicht
perfekt ist hat weder für das Eine, noch für das Andere Beweiskraft.

Ich möchte hingegen erwähnen das wir uns bereits in der Vergangenheit
darüber unterhalten haben wie die Position von OOo zum ODF-Standard war,
der kam nämlich nicht einfach über uns. OOo war maßgeblich beteiligt,
hatte also insbesondere Vorlauf gegenüber anderen Programmen in sofern
der ODF-Standard sich ganz entscheidend an die OOo-1er-Formate
anlehnt.(*)

Wir können nun gerne juristische u.Ä. Spitzfindigkeiten austauschen
warum der Einfluß der OOo-Vertreter auf den ODF-Standard nicht größer
war als der Anderer - müssen wir das wirklich ...

> Das heißt jetzt aber nicht, dass wir "mit Absicht" das nicht
> verbessern
> wollen. :-)

Das sage ich auch nicht, ich trete nur der Annahme entgegen das OOo in
gleichem Maße wie jeder x-beliebige 'ODF-Format-Implementator' ohne
Informationsvorsprung bezüglich des Formats und notwendiger
Implemetierung war.





Gruß
Jörg

(*)
Aus den bekannten Veröffentlichungen zu Tests(**) wie gut die Standards
eingehalten werden, kann ich nicht erkennen das OOo seinen Vorlauf
adäquat genutzt hätte so ich nicht sehe das OOo merklich besser als
KOffice dasteht.
Nö, ich behaupte jetzt nicht das die Tests die Wahrheit sagen müssen,
nur da ODF wichtig ist, und der Testausgang kaum berauschend war, wäre
mir einsichtig das den Testergebnissen entschieden widersprochen worden
wäre, wenn sie substanziell falsch wären, allein das das nicht geschah,
reicht mir für eine allgemeine Mailingdiskussion für die Einschätzung
das die Tests nicht so falsch waren.

(**)
Link habe ich jetzt nicht, stand aber alles schon mal auf Liste, der
eine ist der der C't und der andere der einer amerikanischen
Einrichtung, ich glaube einer Universität

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [de-dev] OOo_2.3.0rc1 & Issue #4032

[Mathias Bauer]

Guido Ostkamp wrote:

> Hallo Mathias,
> 
>>> Ich hatte angenommen, im ODF-Dateiformat sei schlauerweise bereits ein 
>>> explizites aber optionales XML-Element vorgesehen, mit dem man die 
>>> Mindest-Requirements betreffend der zur Bearbeitung erforderlichen 
>>> Softwareversion festlegen kann, und daß dieses bisher wg. noch nicht 
>>> vorkommender inkompatibler Änderungen noch nicht verwendet worden sei, 
>>> man es aber durchaus bei durch die Version OOo 2.3.0 bearbeiteten 
>>> Dokumenten hätte aktivieren können.
>>
>> Was in ODF drin ist, spielt keine Rolle. Wenn die ältere Version das 
>> nicht auswertet und keine Fehlermeldung bringt, muss man genau das tun, 
>> was ich schrieb: man muss die ältere Version ändern und die Anwender 
>> müssen diese geänderte Version installieren. Dann können sie aber auch 
>> gleich die neue Version nehmen.
> 
> Ich hatte natürlich erwartet, daß sich ein SO-Designer bereits früher 
> Gedanken über das mögliche Auftreten solche Fälle gemacht hätte und 
> folglich in SO/OOo bereits eine solche Funktionalität implementiert sei.

"Natürlich" ;-) hat sich jemand Gedanken darüber gemacht. Aber
offensichtlich nicht befunden, daraus etwas abzuleiten.

> Ich verstehe Dich jetzt so, daß dies wohl nicht der Fall ist (in meinen 
> Augen stellt das leider eine Designschwäche dar) und damit gibt es, wie Du 
> ja richtig geschrieben hast, leider keinen Ausweg.

Keine Designschwäche, nur eine Implementierungsschwäche. Ich sehe nicht,
dass irgendein Design eine solche Funktion verhindern sollte. Genauso
wie beim Laden Fehler im Dateiformat erkannt werden können, kann man
natürlich auch Unbekanntes erkennen. Und genauso wie es bei Fehlern eine
Warnung oder gar eine Fehlermeldung gibt, kann man natürlich auch bei
unbekannten Elementen warnen. Bliebe noch die Frage, was man dem
Anwender erzählt.

Ich wäre etwas frustriert, wenn mir das Programm einfach lapidar
mitteilte, dass es irgendwas nicht verarbeiten konnte. Vor allem, weil
es wohl auch nicht möglich ist, dem Anwender irgendeinen Hinweis darüber
zu geben, welche Auswirkungen das haben kann. Es sollte daher auf jeden
Fall versucht werden, dem Anwender Lösungsmöglichkeiten aufzuzeigen.
Womit wir beim dem Punkt wären, den du am Ende ansprichst(s.u.).

> Ich wollte dieses Thema hier aber zumindest diskutieren, bevor das Kind in 
> den Brunnen gefallen ist und die 2.3.0 freigegeben wurde, um 
> festzustellen, ob es nicht doch einen Ausweg geben könnte. Ich denke, daß 
> ist auch in Eurem Sinne.

Vielen Dank, es ist immer gut, wenn so etwas angesprochen wird. Ich
denke allerdings nicht, dass der vorliegende Fall ein gravierendes
Problem ist.

> Man sollte aber wenigstens jetzt daraus lernen und baldmöglichst so etwas 
> einführen, und natürlich sollte das defaultmäßig aktiviert sein, sonst 
> nützt es wenig. Nebenbei gäbe es dem Benutzer auch ohne "nach Hause zu 
> telefonieren" einen Anreiz upzudaten, was ja auch im Sinne des Projektes 
> ist.

Du wirst lachen: wir haben in der Tat diskutiert, eine Funktion
einzubauen, die beim Vorliegen unbekannter Features in der Datei den
Anwender davon unterrichtet und ein Update empfiehlt. Eine solche
Funktion wurde aber als bedenklich eingestuft, was man vielleicht im
Lichte der damaligen Diskussion über Online-Notifikationen sehen muss.

Ich persönlich wollte sowas auch haben und werde jetzt diese Diskussion
hier mal dazu nutzen, so etwas wieder anzuregen. OOo 2.4 ist eine gute
und wohl auch letzte Gelegenheit, das noch einzubauen, bevor wir auf die
neue Code Line wechseln. Damit helfen wir sicherlich denjenigen, die aus
welchen Gründen auch immer den Schritt von 2.x auf 3.0 verschieben oder
gar nicht gehen wollen.

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 "[EMAIL PROTECTED]".
I use it for the OOo lists and only rarely read other mails sent to it.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [de-dev] OOo_2.3.0rc1 & Issue #4032

[Mathias Bauer]

André Schnabel wrote:

> Hi,
> 
> Guido Ostkamp schrieb:
>>
>> Man sollte aber wenigstens jetzt daraus lernen und baldmöglichst so 
>> etwas einführen, und natürlich sollte das defaultmäßig aktiviert sein, 
>> sonst nützt es wenig. Nebenbei gäbe es dem Benutzer auch ohne "nach 
>> Hause zu telefonieren" einen Anreiz upzudaten, was ja auch im Sinne 
>> des Projektes ist.
> 
> Ich finde sowas als Standardoption kontraproduktiv. (iehe Begründung von 
> Jörg).
> 
> Da, woran gearbeitet werden sollte - und was wirklich jedem etwas 
> bringen würde ist die korrekte und vollständige Implementierung des 
> ODF-Standards. (Mit der esim Moment leider noch etwas traurig aussieht).

"Traurig" finde ich etwas übertrieben. Immerhin zeigt die Tatsache, dass
auch OOo noch nicht alles korrekt umsetzt, dass die Behauptung, ODF sei
einfach nur das OOo-Format, unsinnig ist. Ich brauche ja hier nicht zu
erwähnen, wer dieses "Argument" immer gerne benutzt.

Das heißt jetzt aber nicht, dass wir "mit Absicht" das nicht verbessern
wollen. :-)

"ODF Compliance" hat einen hohen Stellenwert für uns. Gerade in der 2.3
sind dafür viele Issues geschrieben und auch gefixt worden.

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 "[EMAIL PROTECTED]".
I use it for the OOo lists and only rarely read other mails sent to it.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]