Hallo Mechtilde, Am Wed, 13 Jan 2010 17:47:25 +0100 schrieb Mechtilde: > Hallo André, *, > > Andre Schnabel schrieb: >> Hallo, >> >> ich präzisiere das thema mal ein wenig, da es hier nicht um die Tests >> ans isch geht, sondern darum, welche Installationspakete überhaupt >> zum Testen (und letztendlich für die Endanwender) verfügbar sind. >> >> >> -------- Original-Nachricht -------- >>> Von: Mechtilde <[email protected]> >> ... >> >>> Auf der Wiki-Seite sind auch alle bisher verfügbaren Builds abgebildet. >>> http://wiki.services.openoffice.org/wiki/DE/3.2_Release_Test >>> >>> Bitte kommentiert dort, wenn dies nicht den Erfordernissen entspricht. >> >> >> Hier aber bitte darauf achten, dass es nicht darauf an kommt, ob >> "ich selbst" einen besimmten Build testen will (und er deshalb verfügbar >> gemacht werden muss). Die Frage ist eher, ob unsere Anwender Bedarf >> an einem bestimmten Build haben und er deshalb für die Tests verfügbar >> und auch getestet werden muss. > > Den "Anwender-Bedarf" bei Windows kann ich selber nur schlecht > einschätzen. Deshalb bin ich auf entsprechende Informationen anderer > Community-Mitglieder angewiesen.
Ich versuche es mal mit den Erfahrungen die ich so im Bekannten-/Freundeskreis gemacht habe. Wenn ich selbst den Rechner der Person, die mich um Hilfe bittet, in der Hand hatte, hat er meist zum damaligen Zeitpunkt ein aktuelles Java installiert bekommen und da Java sich, ich weiß eigentlich gar nicht so genau seit wann, selbst sehr gut aktuell hält, ist meist ein gar nicht so weit vom aktuellen Release installiertes Java auf dem jeweiligen Rechner und es reicht ein Klick auf die Aufforderung in der Taskleiste um Java ganz aktuell zu haben. Dann noch ein wenig die Rest alter JRE deinstallieren und ich hab bis zum nächsten Hilferuf Ruhe mit Java. Hat der Anwender zusätzlich noch OpenOffice.org installiert brauch ich theoretisch keinen Installationssatz von OOo der ein JRE mitbringt. Hatte ich den Rechner vorher noch nicht in der Hand finde ich es natürlich sehr praktisch in einem Rutsch OOo und Java installieren zu können und nehme gerne den Installationssatz mit JRE nur jetzt kommt das ABER Es kann ja vorkommen, dass wir einen Installationssatz mit einer JRE Version anbieten die bekannte Sicherheitslücken enthält und dann muss theoretisch sofort nach der Installation auch das Java aktualisiert werden, nur wie kommunizieren wir das? Gibt es dann eine Pressemeldung im Sinne von "Der Installationssatz von OpenOffice.org enthält eine unsichere Javaumgebung bitte aktualisieren sie sofort nach der Installation von OpenOffice.org ihr Java"? Oder stellen wir dann neue Installationssätze zur Verfügung, denn wenn in sagen in Update 17 eine Sicherheitslücke gefunden und behoben wird, müssten wir theoretisch die Installationspakte für Windows neu mit dem Update 18 ausliefern und neu testen. Daher lade ich meist ein aktuelles JRE herunter und einen Windowsinstallationssatz ohne JRE. So sind OOo und JRE auf dem aktuellen Stand und können unabhängig voneinander aktuell gehalten werden. Zusätzlich kann ich mir vorstellen, dass Administratoren in großen Firmen auf eine bestimmte Java Version angewiesen sind und die werden sich freuen, wenn OOo mal ebenso ein JRE installiert und das Programm, welches Java benötigt, auf das neueste JRE zurückgreift und eventuelle nicht mehr, nicht richtig funktioniert. Klar gibt es auch Anwender deren PC ich vielleicht unregelmäßiger sehe und für die ist es ein klarer Vorteil mit OpenOffice.org auch ein neues JRE zu bekommen, da sie meist gar über potentielle Sicherheitslücken im JRE informiert sind und gar nicht wissen, wie viele Programme u.U auf das JRE zugreifen oder das sogar ihr Homebanking über JRE läuft. Im Endergebnis fände ich es wirklich praktischer Windows Installationssätze mit und ohne JRE anzubieten und dem Anwender zu überlassen, welche Version er herunterlädt. Freundliche Grüße Eric Hoch -- ## 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]
