wine 2.20 und CrossOver Beta 5

Hallo zusammen,

es gibt einige kleine Neuigkeiten:

  • Heute habe ich auf meinem sogenannten librerig-PC mal wieder ein Slackwarepaket von wine-2.20 gebaut aber nicht veröffentlicht, da hier im Wohnheim einige Uploadports im Netzwerk gesperrt sind, die ich dafür benötigen würde.
  • Paint Shop Pro 2018 wurde mit CrossOver 17 Beta 5 getestet aber der Versuch war leider nicht erfolgreich: Es wird über unzureichende JavaScript-Privilegien gemeckert so dass die Installation garnicht startet. 
  • Bericht über diese Thematik ist bei Codeweavers eingereicht, jedoch handelt es sich nicht um eine “supported App” wo in Bugfällen nachgebessert wird. Wäre aber schön wenn sich CodeWeavers um die Corelinstaller kümmern würde, da ich kein CreativeCloud-Abo von Adobe mit monatlichen Gebühren möchte.

Wünsche ein schönes Wochenende!

CrossOver 17 in der Betaphase – Omniscient Rang geknackt!

Als Teilnehmer der “closed betas” von CrossOver nehme ich aktuell an der Betaphase für CrossOver 17 teil, wobei das fertige Produkt in den kommenden Wochen erscheinen wird.

Weiterhin wurde das deutsche Sprachpaket der Software vervollständigt und CrossOver 17 wird somit komplett auf Deutsch verfügbar sein.

Codeweavers, die Firma hinter CrossOver bietet bei den Tests ein sogenanntes Gamificationsystem an, wobei man Erfahrungspunkte für abgegebene Reports, Kommentare, Screenshots etc. sammeln kann. Insbesondere bei den Betareports kann man ganz gut Experiencepoints abräumen und so gelang es mir, den Rang des:

Omniscient Mystical Exalted Nigh-invincible Supreme Raging Atomic Dragon Turbo Chief Senior Advocate

zu erreichen. Dieser stellt in der regulären Entwicklung den höchsten Rang dar. Später werden dann noch Rank 2, Rank 3 etc. dem Titel hinzugefügt.
Damit bekomme ich nun das “Work Shirt” von Codeweavers und einen Aufkleber, den ich auf mein Sammelposter in meinem Zimmer kleben werde.
Weiterhin freue ich mich mitteilen zu können, dass ich meinen 2015 gehaltenen Vortrag über wine zur ubucon in Wolfsburg wieder ins Rennen geschickt habe und mich derzeit für einen Vortrag bewerbe. 
Großer Dank geht hier insbesondere an Michael von der FSFE Wolfsburg/WOBLUG dafür, dass er diese Veranstaltung nach Wolfsburg geholt hat.

Bericht von der odoo-Präsentation im Novotel, Hannover

Ich hatte ja in diesem Blog angekündigt, dass ich am Freitag den 20. Januar 2017 eine odoo-Präsentation im Novotel, Hannover besucht habe. Hier folgt ein kurzer Bericht über die Veranstaltung.

Aufmerksam wurde ich durch die Gruppe „ERP auf Basis freier Software“ auf Xing, die mein Hauptgrund war, überhaupt mich wieder bei Xing zu registrieren.
Ausrichter der Veranstaltung waren odoo, die Firma ecoservice, IFE GmbH und Hucke Media. Die beiden letztgenannten Firmen sind sogar so aktiv in der odoo-Szene, dass sie 2014 seitens odoo die Auszeichnung „EMEA Partner of the Year 2014“ verliehen bekommen haben.
Ich entschloss mich, früh anzureisen und konnte vorab noch mit den beiden odoo-Repräsentanten ein paar Worte wechseln. Insbesondere ergab sich die seltene Möglichkeit, in Niedersachsen mal wieder Französisch zu sprechen. Ich erfuhr dabei, dass die beiden Repräsentatien Nicholas (Channel Account Manager) und Charles demnächst in Lausanne und anschließend in Mailand sprechen werden. Für die anschließenden Präsentationen wünsche ich natürlich von dieser Stelle aus „Bon Courage“.
Ich sicherte mir gleich einen Platz in der ersten Reihe und erfuhr, dass sich etwa 90 Leute zu der Veranstaltung angemeldet hatten. Durch ein Gespräch mit meinem Stuhlnachbarn erfuhr ich, dass dieser sogar aus Berlin nach Hannover angereist war.
Nach und nach füllte sich der Saal und es mussten noch einige zusätzliche Stühle heran geschafft werden. Dennoch ging es pünktlich los und man einigte sich darauf, dass Nicholas und Charles als erstes Sprechen und die drei odoo-Partner dann später zu Wort kommen.
Der odoo-Vortrag wurde in vier Bereiche unterteilt, die nun durchgegangen werden. Dank meines mitgebrachten Laptops konnte ich mir zahlreiche Notizen machen.

I. About odoo / Über odoo

Die belgische Firma odoo wurde vorgestellt und die Zuhörer erfuhren, dass die Wurzeln dieses Unternehmens bereits auf die Jahre 2002-2005 zurück gehen. Man sieht also, dass man es mit einer Firma zu tun hat, die schon seit über 10 Jahren im Geschäft ist.
Es sei anzumerken, dass sich der Name des Produkts im Laufe der Zeit mehrmals geändert hat: Hiess das ERP-System ursprünglich noch Tiny ERP (tiny = winzig) wandelte sich der Name in OpenERP und anschließend in den aktuellen Namen odoo.
Odoo hat zwei Büros in Belgien, eins für den Vertrieb sowie eins für Entwicklung und Administration. Weiterhin ist man in den USA aktiv und verfügt über Entwicklerressourcen in Indien.
Ein besonderes Augenmerk wird auf das Partnergeschäft gelegt, die lokal vor Ort agieren, zertifiziert sind und letztendlich die Lösung beim Kunden implementieren.
Einige weitere Key-facts, die ich mir von der Folie abgeschrieben habe:
  • 32 languages
  • 308 employees
  • 700 partners
  • 1000 installations
  • 2 million users

II Odoo Value Proposition

Im Anschluss wird eine Matrix bzw. ein Koordinatensystem gezeigt, welche an der einen Achse einmal mit „product scope“ und auf der anderen „flexibility“ aufzeigt. Verschiedene ERP-Systeme sind dort gelistet, wobei odoo ganz alleine rechts oben (also stark auf beiden Achsen) steht. Die Folie ist auch auf der odoo-Webseite zu sehen.
Product scope bezieht sich nach Aussagen odoos auf Aspekte wie beispielsweise: Wie viele Funktionen hat das Produkt, bietet es ein kleines Set von Features oder einen Großen Umfang von Merkmalen. Hier wurde beispielsweise das Produkt Salesforce.com angesprochen, welches meines Wissens nach im CRM Bereich sehr stark ist, aber sonst relativ wenig Merkmale hat.
Die Achse „flexibility“ bezieht sich auf Themen wie beispielsweise: Ist die Software leicht zu nutzen? Ist sie benutzerfreundlich?
Die Kernaussage ist jedoch, dass odoo beide Aspekte abdecken möchte.
Weiterhin wurde angesprochen, dass moderne ERPs buchhaltungszentriert sind (Vertrieb, Einkauf, Eingehende Waren, Lagerhaltung, Lieferung) aber die Anforderungen der heutigen Unternehmen sich nicht ausschließlich darauf beziehen: Vielmehr sei es wichtig, dass man eine Webseite oder einen Shop zuerst hat, da man als Firma bekannt werden und auf sich aufmerksam machen möchte. Da gilt es letztendlich darum, etwas zu zeigen.

In Folge wird die Integration von Front- und Backend angesprochen: Als Beispiel wurde eine Bestellung, die über die Webseite herein kommt genommen und dass eine Rechnung daraus erstellt wird. Gleichzeitig wird ein Fokus auf Benutzerfreundlichkeit gelegt, das das Arbeiten angenehm macht, während tradionelle ERPs eher für Reportingaufgaben und das Management ausgelegt sind. Odoo möchte gleichzeitig die Verwaltung einer Firma bei gleichzeitiger Benutzerfreundlichkeit realisieren.

III Odoo 10 Demo and Overview (Odoo 10 Demo und Überblick)

odoo wird als vollständige Weblösung angeboten, die über den Browser verwaltet wird. Im Vorfeld des Vortrages hatte ich nach dem alten GTK-Client von TinyERP gefragt, ob es diesen noch gibt. – Den gibt es nicht mehr.
In der Demonstration sind einige Module installiert wobei man nicht alle Module installiert haben muss. Auch der Start mit einem Modul (beispielsweise CRM) ist möglich. Ein Application Store wird angeboten, wo man per Klick einzelne Module nachrüsten kann. Dieses Modul wird dann auch dem zentralen Panel hinzugefügt.
Der Vertrieb ist rund um den Kunden organisiert und das entsprechende Modul kann dann Fragen beantworten wie beispielsweise: Welche Treffen hatte ich? Anschließend werden diese Leads dann in der Sales Pipeline gebündelt.
Es wird ebenso ein dynamisches Suchfeld vorgestellt. Somit ist es möglich, nach der Angebotsfunktion zu suchen und diese Schnellzugriffe wurden hinzugefügt um die Arbeit mit dem System zu vereinfachen.
Dies sei nötig um komplexe Themen leichter verständlich zu machen: Als Beispiel nennt man hier die Thematik des Projektmanagements.
Es wird anschließend ein Angebot erstellt, über die Schnellsuche die Funktion lokalisiert und darauf zugegriffen. Anstelle Emails hin und her zu schicken, geht odoo auch hier einen eigenen Weg. Das Angebot wird online hinterlegt und kann auch online unterschrieben werden. Dies soll die Art unserer Geschäftstätigkeiten ändern. Natürlich wird dies auch alles in der Datenbank gespeichert und man kann über die Buchhaltung prüfen, wie der Status der Rechnung ist.
Brandneu ist die mobile Anwendung um Zugriff von überall zu ermöglichen, da viele Tätigkeiten nun auch über große Distanzen erledigt werden. Odoo meint, dass die Mitarbeiter teils schon von ihren Autos aus Zugriff auf Daten der Firma brauchen. Dazu werden multi-accounts, smart notifications und native Widgets geboten.
Ein Video, welches auch auf YouTube zu sehen ist, stellt den Website Builder und die Integration in eCommerce vor.
Ebenso wird die Helpdeskanwendung vorgeführt wobei hier insbesondere die Konfigurationsmöglichkeiten verfeinert wurden. Ein Dashboard wurde integriert, ebenso ein Konfigurationsschirm um die Anwendung an sich zu konfigurieren. Ein Emailkonto um Mail zu empfangen wird mit dem Ticketsystem verknüpft.
Eine direkte Chatfunktion (auf der Webseite befindet sich rechts unten eine Funktion, dass man mit einem Mitarbeiter chatten kann) ist mit dem System ebenfalls verbunden.
Die Erstellung von eigenen Formularen und SSL-Policies sowie die Definition von Service Level Agreements sind ebenfalls möglich. Die Unternehmensleitung kann somit überprüfen, ob Servicetickets zeitnah abgearbeitet wurden und natürlich sind auch Anfragen nach der Zufriedenheit des Kunden mit dem Support möglich. (Sind Sie mit dieser Antwort zufrieden?)
Als nächtes geht es um die Auswertung von Belegen (Expense Management). Belege (Hotelrechnungen, Taxiquittungen) etc. können direkt mobil hochgeladen werden und werden dem entsprechenden Datensatz angehängt. Das Resultat ist eine enorme Erleichterung für die Buchhaltung und die Rückzahlung von Ausgaben geschieht wesentlich schneller. Eine Filterung nach Art (Reise, Hotelrechnung etc.) macht das ganze System dann schnell und effizient.
Die odoo-Repräsentanten gehen dann zu dem Aspekt der Fertigung über: Der Slogan „MRP, PLM (Product Lifecycle Management), Quality and Maintenance (Wartung) – Together at last!“ macht dabei Appetit auf mehr.
Im Durchschnitt verwenden Fertigungsbetriebe teils bis zu 10 Anwendungen um ihre Geschäftsprozesse zu verwalten (Quickbooks für Buchhaltung etc.) während odoo alle Aspekte in eine Anwendung komprimiert.
Es wird das Master Production Module vorgestellt: Als Beispiel wählt man zwei Produkte, einen Computer und eine Mouse und erklärt „direct and indirect demand“, die beispielsweise Verkaufsprognosen berücksichtigen. Herstellungsorder können somit direkt geplant werden und in Form von „work orders“ an die einzelnen Arbeitsplätze geschickt werden. Eine Zeiterfassung, die pausiert werden kann, darf da natürlich nicht fehlen.
Die Produktionslinie kann bei einem schweren Fehlen blockiert werden und die Produktionsleitung wird alarmiert. Ebenso kann man bei dem Defekt eines Teils eine Wartungsanfrage stellen. Bezieht man dabei Teile vom Lager werden die Lagerbestände entsrechend angepasst. Ein Journal und Aufzeichungen etc. werden ebenfalls gepflegt.
Präventive Wartung bei Geräten kann ebenso geplant werden, wobei die MTBF (mean time between failure) herangezogen wird.
Eine Oberfläche eines Workflows (In Progress – Approved – Validated) wird vorgestellt.
Weiterhin wurden Innovationen im Qualitäts Management vorgestellt. Eine Prüfung zwischen einzelnen Belegen kann beispielsweise zeitlich mit einer spezifizierten Toleranz geplant werden. Beispielsweise kann ein gefertigter Artikel so definiert werden, dass es als unverkäuflich gilt sofern die Qualität noch nicht überprüft wurde.
Im Anschluss ging man auf Odoo Studio ein. Von den Referenten wurde angemerkt “Our CTO gave us some superpowers.” Nun ist es auch ohne Entwicklungskenntnisse möglich, ein Feld beispielsweise zu Sales Orders (z.B. Kundenreferenz) einem Formular hinzufügen. Ebenso ist es möglich, zu definieren ob es sich um ein Pflichtfeld handelt, welches unter allen Umständen ausgefüllt werden muss. Das Feld kann auch aus den Ansichten entfernt werden. Diese Funktion ist jedoch nicht in der Communityversion sondern erst ab Status Enterprise vorhanden.
Auf dieser Basis ist es somit möglich, eingene Apps in odoo zu erstellen. Insbesondere dieses Merkmal stieß bei den Besuchern auf großes Interesse.

IV Questions and Answers

Falk Neubert von ecoservice, Hannover, der seit 6 Jahren mittlerweile odoo betreut und Partner ist, stellte sein Angebot vor. Dies besteht insbesondere aus der Einführung, Schulung und Entwicklung kundenspezifischer Lösungen sowie Branchenlösungen. Ebenso berät er sehr intensiv über Organisationsentwicklung und den Aufbau von Workflows innerhalb von odoo.
Insbesondere ist hervorzuheben, dass ecoservice selbst eine DATEV-Schnittstelle entwickelt hat, dabei die Version 10 bald erscheinen wird. Den Standort Hannover bereichnete er als “odoo Hauptstadt”.
Wolfram Müller, Geschäftsführer von IDE sowie Herr Passmeier von hucke media stellten sich ebenfalls vor. IFE wurde 1990 gegründet und ist Gold Partner von odoo. Das Team von 40 Personen wurde 2014 als bester Partner von odoo ausgezeichnet. Weltweit hat IFE die meisten Kunden unter allen odoo-Partnern. Einige Kunden sind dabei im Ausland ansässig wobei der größte Kunde um die 1000 User umfasst. Referenzen sind unter anderem Airbus und Metro.
In der Vergangenheit wurde so eine DATEV-XML-Schnittstelle programmiert, die Belege zum Steuerberater übermittelt. Ein starker Fokus liegt auch auf der Beratung zu den 10000 Modulen im odoo-Markt. Entsprechende Videos findet man auf IFE-Webseite und es wurde ein Vergleich von verschiedenen ERP-Systemen in der Computerwoche präsentiert.

Ich selbst nutzte die Frage und Antwort-Stunde zur Frage nach der Implementierung eines Rollenkonzepts in odoo. Dies wurde eindeutig bejaht: Zugriffsrechte seinen nicht nur auf einzelne Module möglich sondern entsprechende “Rules” sind auch auf Datenebene möglich. So ist es beispielsweise möglich, dass ein Verkäufer nur seine eigenen Verkäufe oder Kontakte sehen kann.

Weiterhin kamen aus dem Publikum Fragen zur Implementierung von Multi-Company: Mehrere Firmen mit eigenen Kontenrahmen allerdings mit gemeinsamen Artikelstamm.

Bezüglich der Buchhaltung und DATEV wurde angemerkt, dass odoo eher eine “one size fits all” Lösung ist aber unser deutsches Steuerrecht sehr speziell sei. Mit odoo 11 möchte man stärker die Lokalisierung der Buchhaltung voran treiben.

Weiterhin ist ein Dokumentenmagement in odoo implementiert. Jedem Datenobjekt können Daten angehängt werden, die im Filestore gesichert werden und in eine Datensicherung einbezogen können. Dies sei auch in Verbindung mit agorum möglich, welches wiederum zertifiziert ist.
Zum Thema Point of Sales wurde nach der Zertifizierung für Deutschland gefragt. Dies sei noch derzeit noch nicht vorhanden. Der Hintergrund ist, dass seit Beginn des Jahres 2017 dies bei elektronischen Kassen vorgeschrieben sein. Bei odoo geschieht die Eingabe über die Weboberfläche und die Nachvollziehbarkeit wird durch die Datenbank realisiert. Insbesondere müssen die Daten nachvollziehbar und unveränderbar sein. Das Finanzamt erteile aber selbst keine Zertifikate. Es sei ein ein “Mythos, der durch die Landschaft geistere”.

Ebenso kam die Frage auf, eine Agfeoanlage an der CRM anzubinden. Odoo 10 hat ein Voice over IP-Modul integriert. Zu einer Asterisk-basierten Lösung wurde Cyfon, Hannover angesprochen. Schnittstellen gäbe es aus der Community.

Eine weitere Frage war die Integration mehrerer Googlekalender.

Das Plenum wurde auch auf verschiedene Codestänge aufmerksam gemacht: So sei die OCA (odoo Community Association) in Frankreich und Belgien sehr groß aber die deutsche Community eher klein dazu. Die Enterpriseversion bestünde zu 80% aus der Communityversion. Manche Funktionen seinen aber in der Communityversion abgeschaltet. Die OCA diene ebenso auch sehr zur Qualitätssicherung des Produkt, da es auf die Grundmodule Gewährleistungen der Firma odoo gebe.

Release- und Developmentbranches in Wine und CrossOver

Kürzlich erschien im offiziellen CodeWeavers-Blog eine Erläuterung, wie wine und CrossOver zusammen hängen. Mit der Erlaubnis von Josh DuBois habe ich diesen Artikel übersetzt:

Hier bei CodeWeavers fragen die Kunden oft wie CrossOver hergestellt wird. Wir bekommen Anfragen, die von ziemlich einfach bis extrem technisch reichen. Beteiligte und neugierige Nutzer sind unter den Freuden, dass wir unser Produkt auf einem Open-Source Projekt basieren.

Jetzt wo CrossOver 16.2 erscheint, denke ich, dass es eine gute Zeit ist, darüber zu sprechen wie wir Entwicklungs- und Releasezweige für CrossOver verwalten. Im Spektrum dieser Dinge, die man über Wine sagen könnte, ist dieses Thema nur bedingt technisch. Es ist eine häufige Frage von unseren Benutzern, sowohl in unseren Webforen und in unserem Livesupport-Kanal.

Grundlegend: CrossOvers Fähigkeit, Windowsanwendungen laufen zu lassen kommt aus Wine. Wine ist ein Open-Source Softwareprojekt mit einer über zwanzigjähigen Geschichte. Der interessante Teil, unsere internen Sourcecode Zweige zu verwalten ist, wie diese mit Wine integriert werden. Um unseren Releasezyklus zu verstehen, muss man Wines Entwicklungszyklus verstehen.

Der Entwicklungszyklus von wine

Wines Haupt git-repository befindet sich unter

 git://source.winehq.org/git/wine.git
 
  

Mitwirkende schicken täglich Patches an wine und jeden Tage committet Alexandre Juillard, unser furchloser Leiter, akzeptierte Patchen in Wine’s Hauptrepository. Hier bei CodeWeavers ist unser grundlegender Arbeitsprozess, dass unsere eigenen Wineentwickler ihre Arbeit an wine über den regulären Einreichungsprozess einbringen (und hoffen, dass es akzeptiert wird!). Standardmäßig geht also der Code, den wir scheiben zuerst in das Open Source Repository bevor es in unsere eigenen git-Zweige kommt.

Wine erfährt alle zwei Woche eine nummerierte Entwicklungsveröffentlichung, zu wechselnden Freitagen. Diese Veröffentlichungen erhalten ein Tag und werden gebaut und weit in der Open Source Gemeinschaft verwendet. Es wird keine Magie bei den Entwicklungsversionen angewendet – keine speziellen Tests werden durchgeführt und keine Meilensteine für diese Entwicklung erreicht. Es sind einfach und praktisch nummerierte Schnappschüsse der Wine-Entwicklung innerhalb regulärer Zeitintervalle.

Bei CodeWeavers nennen wir unseren Haupt-git-Zweig den ‘crossover’ Zweig. Sofort nach jeder Wineentwicklungsveröffentlichung verbindet Alexandre Wine’s Hauptzweig in unseren internen CrossOver Zweig. So bekommen wir neue Arbeit von Upstream in die Codebasis, die wir nutzen um CrossOver zu bauen. Dies bedeutet, dass für unseren “Standardprozess” ist der zweiwöchige Winemerge das erste Mal einem bestimmten Teil von Wineentwicklungsarbeit – selbst Arbeit von unseren eigenen Entwicklern – unser internes Quellenrepository betritt. [1]

Entwicklungsveröffentlichungen sind spannend, da sie all die neuesten Änderungen beinhalten. Allerdings bedeutet diese Spannung, dass sie instabil sein können. Um dies zu verwalten, ist es nicht überraschend, dass wir einen Releasezweig verwenden.

Release-Zweige

Wir veröffentlichen eine Major-Version von CrossOver einmal im Jahr, irgendwann im Herbst. Etwa zwei Monate vor unserem Veröffentlichungsdatum machen wir einen neuen Zweig basierend auf unserem “crossover” Hauptzweig. Dieser Zweig widmet sich unserer kommenden Veröffentlichung. Unsere Releasezweige starten ihr Leben somit wie es jede Entwicklungsveröffentlichung von Wine tun würde – einfach ein Schnappschuss der Wineentwicklung, die zu einem bestimmten Zeitpunkt gemacht wird.

Wir machen unsere Releasezweige stabiler indem wir durchgehend testen. Wir testen, testen und testen, beheben Bugs und testen noch mehr. Wir testen einige Wochen bei uns und starten eine Beta wobei über zweihundert engagierte Betatester auf CrossOver herumhammern und Probleme berichten. Am Ende unserer Betyzyklen wurde der Code zuverlässiger und vorhersehbar.

Normalerweise machen wir keine weiteren Merges von Wine entlang eines Major-Releases von CrossOver. Somit kann man sagen, üblicherweise hat eine bestimmte Version von CrossOver immer die Version von Wine, die sie hatte, als wir zuerst den Releasezweig von Wine für diese Version erstellten.

Natürlich beheben wir Bugs während der Lebenszeit einer Version aber wir halten diese Behebungen gezielt so dass wir bezüglich ihrer Sicherheit sicher sein können.

Einige Veröffentlichungen sind außergewöhnlich und wir manchen gelegentlich eine vollständige Einbeziehung zwischen Major-Releases. Dies passiert selten. CrossOver 16.2 ist eine dieser Ereignisse! Dies macht es etwas zu einem besonderen Fall. Wenn wir wirklich einen wine-Merge machen, tendieren wir dazu, eine weitere Runde von Betatests zu machen (obwohl diese etwas kürzer als die erste sind).

Hacks

Wine hat sehr hohe Standards bezüglich welches Code in das Masterrepository kommt. Als kommerzielles Produkt weichen CrossOvers Bedürfnisse oft aus pragmatischen Gründen ab. Normalerweise bedeutet dies, dass ein Entwickler ein Problem sieht und kann sagen, dass die elegante Lösung einige Monate Arbeit braucht oder höchst destabilisierend wirkt. Dann bitte ich um eine Lösung, die in der Praxis funktioniert, selbst wenn sie unsauber ist oder das Problem nur in begrenzter Weise löst. Wine wird im Allgemeinen solche Lösungen nicht akzeptieren aber diese verbessern die Lage für unsere Kunde. Wir halten diese Lösungen in unserem eigenen Sourcerepository und nennen diese “Hacks”.

Hacks sind ein Problem, da sie dafür sorgen, dass unsere Quellen von Wines Masterrepository abweichen. Dies macht das Leben für Alexander schwierig denn es ist schwierig Wines Master-Sourcecode in unseren Zweig zu integrieren wenn es Unterschiede dieser Art gibt. Die Unterschiede, die durch unsere “Hacks” entstehen verursachen Konflikte während der Zusammenführung und Alexandre muss jederzeit um diese herumarbeiten wenn eine neue Zusammenführung gemacht wird. Dies ist anstrendend, fehleranfällig und unangenehm.
Aus diesen Gründen war es so, dass wir es vorzogen unsere Hacks in Releasezweig zu bringen. Wir fingen bei CrossOver 16 damit an von unserem Haupt “crossover” Zweig zu branchen und dann zogen wir sofort alle Hacks aus CrossOver 15 herein. Auf diese Art versuchten wir, Hacks in unserem Master ‘crossover’ Zweig zu verhinden in dem Alexandre alle zwei Wochen Merges macht. Die Vermeidung von Hacks auf diesem Zweig machte sein Leben einfacher (und verhinderte eine potentielle Fehlerquelle).

Es gab jedoch Probleme mit diesem Ansatz. Hacks tendierten dazu, von einer Veröffentlichung zur nächsten, zu verschwinden. Somit könnten wir einen Bug mit einem Hack von CrossOver 15 beheben aber wenn wir vergessen würden, den Hack auf unser neues CrossOver 16 anzuwenden, würde der Bug wieder auftreten. Ebenso bedeutete es, dass wir gewisse Windowsprogramme mit unserem Haupt ‘crossover’ Zweig nicht testen konnten, da manche von diesen Hacks zur Funktion benötigten (und diese Hacks waren nur in Releasezweigen vorhanden). Diese Dinge konnten ohne Tests lange Zeit bestehen und wir könnten die Fehlfunktionen nur innerhalb eines Betazyklus für eine neue Veröffentlichung feststellen. Aus diesen Gründen begannen wir fast alle unsere Hacks im crossover Masterbranch zu halten. Dies macht es schwieriger, die zweiwöchigen Merges zu machen aber verhindert andere Probleme.

Trotzdem gibt es immer noch Ausnahmen. Einige “hacks” oder diffs vom upstream wine, sind tatsächlich enorme Massen an Arbeit, die in Hunderte von individuellen Patches enden und viele, viele Datein berühren. Momentan ist der “Command Stream” von wine3d das Hauptbeispiel für einen so großen “Hack”. Es ist nicht realistisch so etwas in unserem Master ‘crossover’ Zweig zu halten da Merges danach wirklich zu schwierig wären, um diese alle zwei Wochen durchzuführen. Somit liegt so etwas nur in den Releasezweigen und wird von einem Releasezweig auf den nächsten bei jedem Zyklus portiert. Es ist schwer und insbesondere mit dem Command Strem versuchen wir, dies upstream zu bringen damit wir diesen nicht mehr weiter verwalten müssen. Zum Glück tendieren wir dazu nicht zu viele solcher enormen “Hacks” zu einem bestimmten Zeitpunkt zu haben. Wenn dies der Fall ist, kann dies Dinge enorm kompliziert oder teuer machen. Somit versuchen wir den Rahmen unserer “Hacks” klein zu halten oder sie upstream zu bringen.

Zusammenfassung

Grundlegendes:

  • CrossOver hat eine Version von Wine für jedes Majorrelease mit seltenen aber wichtigen Ausnahmen. Wir testen diese Versionen rigoros um diese zu stabilisieren.
  • Unser allgemeiner Arbeitsprozess ist, dass Entwickler Patches an Upstream Wine senden bevor diese unsere interne Repositories erreichen. Somit ist die meiste unserer Arbeit öffentlich verfügbar bevor wir diese selbst nutzen. (Natürlich finden wir einen Weg dies zu bekommen wenn wir in Eile sind und es schnell gehen muss)
  • Benutzer mit Privilegien unsere Nightly Builds zu nutzen werden feststellen, dass ein Winemerge alle zwei Wochen stattfindet, da die Nightly Builds im Allgemeinen von unserem Haupt ‘crossover’ Zweig kommen. Diese Build werden den wine3d Command Stream nicht enthalten.

Wenn dich Wine interessiert, kannst Du www.winehq.org besuchen oder den Quelltext unter

git://source.winehq.org/git/wine.git
 

auschecken… und es selbst bauen. Patches sind Willkommen! 

1. Natürlich brauchen wir mache Dinge manchmal schneller und lassen nicht zu, dass unser ‘Standard-Arbeitsprozess’ uns zurückhält. Wenn wir in Eile für eine bestimmte Arbeit sind, können wir uns immer die Rosinen heraus suchen  oder es direkt an wenden.

Über Josh DuBois
Josh DuBois ist ein Ingenieur und Produktmanager für CrossOver.

Über CodeWeavers

Im Jahre 1996 als allgemeine Softwareberatung gegründet, konzentriert sich CodeWeavers auf die Entwicklung von Wine – die Kerntechnologie, die sich in allen CrossOver Produkten befindet. Das Ziel des Unternehmens ist es, erweiterte Marktchancen für Windowssoftwareentwickler zu bieten indem die Portierung von Windows-Software auf Mac und Linux einfacher, schneller und schmerzloser gemacht wird. CodeWeavers gilt als führend in der Open Source Windows Portierungstechnologie und unterhält Entwicklungsbüros in Minnesota, im Vereinigten Königreich und rund um die Welt. Die Firma befindet sich im Privatbesitz.

Umlautproblem bei osCommerce-Deutsch behoben

Ein Item, welches lange auf meiner ToDo-Liste stand, kann nun endlich entfernt werden: Es handelt sich um die Problematik, dass bei meinem Fork von osCommerce, basierend auf dem Projekt oscommerce-deutsch.de die Umlaute nicht richtig dekodiert wurden.

Beispielsweise wurden in den vorgegebenen Artikeln die Kategorie “Mäuse” und “Neue Produkte im März” der Umlaut “ä” nicht richtig dekodiert. Dieses Problem hatten wohl schon ein paar andere Leute vorher und ich bin auf einige Codezeilen aufmerksam geworden, die ich letztendlich in mein Repository auf github.com eingepflegt habe. (Link zum commit)

Weiterhin habe ich einige Formatierungsfehler in den Terms & Conditions entfernt, so dass diese nun etwas genauer dargestellt werden. Beispielsweise wurde ein überflüssiges <LI></LI>-Element entfernt, welches einen leeren Bulletpoint erzeugt.

Ebenso wurde das Produktbild zu Unreal Tournament im Shop ausgetauscht, welches nun in einer besseren Qualität vorliegt aber immer noch etwas groß ist.

Happy hacking und schönes Wochenende!

Slackware Paketbau

Auf meinem freien Software PC mit Trisquel 7 liefen viele meiner WLAN-Sticks nicht, da zwingend eine proprietäre Firmware vorausgesetzt wird, diese im Linux-libre-Kernel nicht mitgeliefert wird.
Ich habe daraufhin mich entschlossen, zu einem meiner stillen Favoriten, der Slackware-Distribution zurück zu kehren und mich heute ein wenig mit dem Paketbau wieder beschäftigt.

Insgesamt konnte ich folgende Pakete bauen, die ich nun auch der Allgemeinheit zum Download für 64-Bit Systeme anbiete:

  • lyx-2.2.2 – ein LaTeX-Editor, den ich zum Kompilieren von libdsk benötigt habe.
  • libdsk – eine Bibliothek zum Lesen von Schneider CPC-Floppydisks.
  • xcpc – ein Amstad CPC-Emulator.
  • Penguin Command – ein Missile Command Klon.

Viel Spaß damit!

Meine neuen freien ERP-Projekte

Letzten Freitag habe ich eine Präsentation des ERP-Systems odoo besucht und bin schwer beeindruckt. Organisiert wurde diese Veranstaltung in Zusammenarbeit mit den hannoveraner Firmen ecoservice und IFE GmbH.

Ich entschloss mich, schon etwas vor der Veranstaltung dort zu sein und nach einem kleinen Imbiss bei meinem Lieblingsgriechen Iridion kam ich dann schließlich im Vier-Sterne-Hotel Novotel an.

Natürlich durfte der Laptop nicht fehlen und ein Stuhl aus der vorderen Sitzreihe wurde dann prompt als Laptopunterlage umfunktioniert. Insgesamt habe ich drei Seiten an Notizen gemacht, die ich in einem separaten Blogartikel präsentieren werde damit auch Leute, die nicht an der Veranstaltung teilnehmen konnten, einen Eindruck bekommen, um was es bei odoo geht.

Ansonsten habe ich mich die Tage etwas mit IBM DB2 beschäftigt. IBM hat sich wieder im Rahmen der CeBIT großzügig gezeigt und einen Full-Event-Pass geschickt. Hier ein großes Danke an Ginnis Team!

Meine Pläne sind, SQL Ledger auf DB2 zu portieren: Ich weiss, dass dies einige Konsequenzen für den freien Softwarestack hat auf dem DB2 basiert. Das nehme ich vorerst in Kauf.

IBM bietet mit der DB2 Express-C eine kostenlose und unbeschränkte Version ihres Datenbankservers an. Allerdings wird der Sourcecode von DB2 Express-C nicht veröffentlicht.

Warum mache ich das?

Ich bin ziemlich von IBMs Technologien beeindruckt, insbesondere vom Supercomputer Watson, den POWER-Servern, Notes, Bluemix sowie der Analytics-Sparte. Meine Initiative dient dazu, sich IBM etwas anzunähern.

Die Anstrengungen, SQL Ledger auf DB2 zu portieren, dürften überschaubar sein. SQL Ledger kann durch die Programmierung in Perl ein Modul namens DBI verwenden, welches eine Verbindungsschnittstelle zu verschiedenen Datenbankservern im Backend aufbauen kann. Laut des Gründers von SQL Ledger dürfte es reichen, den Connect-String und die Konfigurationsdatei anzupassen.

Voraussichtlich wird es dann auch wieder etwas Aktivität in meinem github-Repository mit einem speziellen SQL Ledger-Fork geben.

Ansonsten habe ich für meinen eeepc-Laptop ein neues Netzteil gekauft und das Aufladen der Batterie funktioniert nun auch wieder. Allerdings scheint der eeepc bei der Installation eines Linuxbetriebssystems doch etwas zu zicken, da sich der Computer während der Installation von Trisquel Mini und Lubuntu (Alternate ISO) in der Mitte der Installation aufhing. Weiterhin habe ich eine Netzwerkinstallation von openSUSE i586 mit den Netzwerkinstallationsmedien versucht. Aber auch dies hat leider nicht geklappt, da nach Laden des Installationssystems eine Inkompatibilität mit dem Bootmedium monierte. (Installation system does not match your boot medium, Sorry, this will not work.)

Frohes neues Jahr! – Aktuelle Hacks mit GNUcash und ebay

Ich wünsche den Lesern dieses Blogs erst einmal etwas verspätet ein Frohes Neues Jahr.

Ich selbst habe die letzten Tage damit verbracht, mir GNUcash nochmals anzuschauen und bin insbesondere auf einige YouTube-Videos von einem YouTuber namens “Test IT” aufmerksam geworden, der sich mit Haushaltssoftware beschäftigt.

Inspiriert durch die Onlinebanking-Funktion von GNUcash habe ich ebenfalls versucht, mit GNUcash eine Verbindung mit meiner Bank, Sparkasse Gifhorn-Wolfsburg, eine HBCI-Verbindung aufzubauen.

Mir ist dabei aufgefallen, dass die Server-URLs noch nicht im Programm eingetragen waren. Also habe ich die Online Banking Hotline angerufen, die mir diese Informationen dann auch sehr schnell per Email zusendete.

Diese Konfigurationsdaten habe ich anschließend per Mail an die GNUcash-Mailingliste weitergeleitet. Mal schauen ob sie mit diesen Daten etwas anfangen können und diese in das Hauptprogramm integrieren.

Ansonsten habe ich mich auch etwas mit ebay beschäftigt und festgestellt, dass sowohl Perl als auch Postgres von ebay offiziell unterstützt werden. Mittlerweile bin ich nun im ebay-Developerprogramm in der Hoffnung, mein Warenwirtschaftssystem “SQL Ledger” an diesen Marktplatz anbinden zu können.