Hallo *, > From: RA Stehmann [mailto:[email protected]]
> Tatsächlich ist die Situation im Projekt alles andere als > einfach. Nach > dem Wegfall der Unterstützung durch IBM brauchen wird nicht nur fähige > Entwickler, sondern mussten auch eine neue Umgebung zum Bauen der > Binär-Pakete aufbauen, was nicht ganz trivial ist. Und wir haben versäumt organisatorische Änderungen im PMC durchzuführen. Sorry, mir liegt diese ganze Projekt*politik* wenig, weswegen ich mich da (leider?) rausgehalte, aber die Tatsache das IBM das Projekt verlässt das aber nicht sichtbar zu personellen Änderungen im PMC führt ist doch sicher nicht vernünftig. Das ist kein Vorwurf, sondern eine Sachfrage. > Auch ist eine verlangsamte Entwicklung - sofern sicherheitsrelevante > Fehler zügig angegangen werden - gut vertretbar, AOO ist eine > bewährtes > Produkt, dass seine reife für einen professionellen Einsatz > seit langem > bewiesen hat. Auch sind in diesem Umfeld lange Updatezyklen > üblich, denn > dort wechselt man nicht alle halbe Jahre auf eine neue Officeversion > (Never change a running system (without a good cause)). So ist es. (Zu) Kurze Update-Zyklen sind kein Vor- sondern ein Nachteil. Man muss hierbei mit Sorgfalt argumentieren und mangelnde Ressourcen auch also Solche benennen, aber Updatezyklen in Größenordnung 12...24 Monate, _soweit es Features betrifft und keine notwendigen Sicherheitsupdates_ wären das eigentlich richtige Maß für die Praxis. Die Tatsachen das wir bei Nennung von "12...24 Monate" schon virtuell Luftholen, weil wir doch wissen wie schnell andere Projekte updaten, ist schon Teil des Verständnisproblems für den praktischen Einsatz in Unternehmen, denn da heisst jedes Update das es zunächst zu prüfen gilt ob das Update nicht zu Fehlern bei eingesetzten Fachanwendungen, Makros usw. führt und das ist Kostenaufwand. (Das ist auch bei LO nicht anders, denn da ich beruflich sowohl Kunden unterstütze die OO oder LO einseten weiß ich natürlich das LO-Kunden normalerweise (aus vorstehenden Gründen) auch nicht jedes Update 'mitnehmen'. Größere Kunden tun das schon von sich aus nicht, Einzelunternehmer die von gewisser 'Updateritis' befallen sind lernen es meist wenn sie einmal durch ein Upate aus dem Tritt geraten eil plötzlich ein Makro nicht mehr richtig funktioniert, Calc-Formeln 'anders' rechnen oder anderes mehr.) > AOO muss seit kurzem Apache monatlich Bericht erstatten. Ich habe > neulich mit einer Person gesprochen, die diese Berichte liest. Sie > meinte, wir sollten dies nicht als Belastung verstehen, sondern als > Chance begreifen. Seitens Apache finde ich diesen Weg sogar vernünftig, denn er zeugt davon das Apache seine Prozesse zur allgemeinen Qualitätssicherung im Griff hat. Den Fehler sehe ich eher bei Teilen der Community, nämlich denen die (wie ich) von OOo kamen und die um die Spezific des Projektes wussten und nicht mit ausreichend Nachdruck 'Regeländerungen' für OO gefordert haben. Auch meine Position war diesbezüglich, ab einem gewissen Punkt, leider so das ich den eher bequemen Weg gewählt habe meine Arbeit auf die http://www.prooo-box.org zu konzentieren, als geduldig mit Apache um Verbesserung der Organisation zu ringen. Ich denke (auch) wir (de-AOO) müssen uns (nochmals) aufraffen und an diesem Punkt ansetzen. Wir sollten uns dabei auf die Erfahrung mit der Liste hier besinnen, die wir ja quasi Apache auch 'abgetrotzt' haben. Letzteres sollte niemand missverstehen, ich glaube Apache verfolgt einen sehr vernünftigen und überlegten Kurs, was das Gesamtkonzept betrifft. Einzig müssen wir unsererseits verstehen das unser 'Kampf' bestimmte Dinge durchzusetzen, eigentlich Teil des Konzeptes ist das Apache verfolgt und nicht dessen Gegenteil, denn worum es geht ist das Apache mit Regeln die ganze Struktur stabilisiert, um zu verhindern das quasi diverse beliebige Vorschläge (im Sinne eines Strohfeuers) das Projekt immer wieder schwanken lassen. Gruß Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
