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. <Sarkasmus> 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. </Sarkasmus> > 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 <http://wiki.services.openoffice.org/wiki/De:2.3_Release_Test>. 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]
