Direkt zum Hauptbereich

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.

Kommentare

Beliebte Posts aus diesem Blog

Steuererklärung mit Aldi Steuer 2017 unter wine 3.0-rc2

Hallo zusammen,

bislang mache ich meine Steuererklärung über das ELSTER-Onlineportal, welches im Gegensatz zu einer Steuersoftware, jedoch keinen geführten Dialog hat.

Sowohl Steuerjahr und auch gleichzeitig das Kalenderjahr nähern sich nun dem Ende und die Discounter machen sich daran, vergünstigte Steuersoftware anzubieten.

Steuern ist für viele zwar ein dröges Thema und der alljährliche Akt des Formularausfüllens kann durchaus nervig werden. Hinzu kam in den letzten Jahren auch noch das Testen unter wine und im ubuntuusers.de Forum werden wahrscheinlich auch weitere Fragen zum Thema Steuern unter Linux aufschlagen.

Vorgestern wurde ich auf ein Posting im ubuntuusers.de Forum aufmerksam, in dem Probleme bei der Eingabe einer Seriennummer der Aldi Software Steuer 2017 gemeldet wurden. Ich erklärte mich bereit, diesen Sachverhalt angesichts der Tatsache, dass wine vor dem 3.0 Release steht, zu prüfen.


Meine Hochschule, die Hochschule Harz, legt großen Wert auf Nachhaltigkeit und ich ü…

HS Harz Memories - A Tribute to Prof. Dr. Felser and Leigh Thompson - Verhandeln auf ebay-Kleinanzeigen - "Waz is letzte Preis" wirklich?

Diesen Artikel widme ich insbesondere meinen "Lehrmeistern" die mir in der Vorlesung "Verhandlungsführung" an der Hochschule Harz im Studiengang "Business Consulting" (Master).

Ebenfalls nicht unerwähnt bleiben soll hier Kommiliton Thilo Gersten (Pseudonym) der das Buch "Erfolgreich mit ebay-Kleinanzeigen" geschrieben hat.

Die Vorlesung Verhandlungsführung habe ich im zweiten Semester des Studiums besucht wobei ich die Klausur aber wesentlich später geschrieben habe.

In der Vorbereitung für die Klausur habe ich mir aus Interesse Leigh Thompsons Videos "Negotiation Tactics 101" von der Kellog School of Management komplett angeschaut.

Wie stehen nun ebay-Kleinanzeigen und die "Negotiation Tactics 101" miteinander in Verbindung?


Leigh Thompson verwendet unter anderem die Begriffe des "Aspiration Point", "Reservation Point" sowie der BATNA (Best Alternative to a Negotiated Agreement).

Den "Aspiration Poi…

Exklusiver Rabattcode für CrossOver-Interessenten (30% Rabatt auf aktuellste Version und Abonnement)

Ich freue mich bekannt zu geben, dass ich mit Codeweavers eine Partnerschaft schließen konnte und mir ein exklusiver Rabattcode für meine Webseite und Blog eingerichtet wurde. Dabei erhalte ich keine Provision von Codeweavers solltet ihr im Onlineshop von Codeweavers den Code einlösen.

Der Code lautet LANGUAGEPORTS und bietet 30% Rabatt auf die aktuelle Version sowie das 1-Jahr-Abonnement von CrossOver Mac bzw. Linux.