Schlagwort: wine-staging

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.