Einblicke in den Merge-Prozess

  • Am Ende jedes Versionszyklus gibt es ja einen Merge-Prozess. Meinem Verständnis nach sieht der seit dem Wegfall des Aurora-Channels im Wesentlich so aus:
    Nightly: Versionsnummer wird inkrementiert und Code für Iteration xx.1 darf landen.
    Beta: Code, der bereits als "betatauglich" markiert wurde, wird in den Betabuild übernommen, bei noch nicht entschiedenen Abschnitten wird diskutiert und entschieden was übernommen wird und was nicht.
    Release: Ähnlicher Prozess wie beim Beta-Merge, was noch nicht gut genug funktioniert kann noch im Beta-Channel verbleiben oder hinter Flags oder A/B-Tests versteckt werden.

    Daneben gibt es noch Uplifts, sprich Fixes, die für eine neuere Version vorgesehen sind, aber aufgrund ihrer Dringlichkeit zB direkt von Nightly in Release landen können.

    Ist das soweit korrekt? Wird der eigentliche Merge-Prozess öffentlich einsehbar diskutiert oder passiert das hinter verschlossenen Türen? Wird da überhaupt diskutiert oder ist das im Wesentlichen ein automatisch stattfindender Prozess?
    Entscheidet hier ein Team über das Vorgehen oder gibt es entsprechend befugte Mitarbeiter, die solche Entscheidungen treffen? Oder geschieht das rein auf einer Datenbasis von Telemetriedaten, für die zuvor Kriterien definiert wurden?

  • hi, der merge vorgang ist eigentlich ein rein technischer prozess, der von keinen großen diskussionen begleitet wird. wenn (experiementelle) features, einstellungen etc nicht in den nächsten release kanal mitwandern sollen, ist das in der regel schon im vorhinein klar und wird mittels build-flags im code festgelegt, ohne dass es dann am merge-day noch einen manuellen eingriff dafür braucht.
    code-änderungen in nightly können eigentlich jederzeit landen, sobald sie von einem zweiten entwickler überprüft worden sind und alle automatischen tests erfolgreich durchlaufen haben. alle änderungen, die nicht den normalen zyklus durchwandern, sondern einen kanal überspringen sollen (uplifts - und die finden nicht nur rund um den merge day statt sondern eigentlich durchgehend), brauchen dafür eine spezielle rechtfertigung und zumindest die genehmigung durch einen "release manager", der für die jeweilige version zuständig ist - das findet in der regel öffentlich im jeweiligen bugzilla ticket statt:
    https://wiki.mozilla.org/Release_Management/Uplift_rules

  • Danke für die Klarstellung!

    Warum dann die relativ lange Zeitdauer zwischen Merge und Beta 1-Release? Versucht man dort bereits die gröbsten Probleme auszubügeln, um auf ein Betalevel an Stabilität zu kommen? Oder hat das eher organisatorische Gründe?

  • bis zum letzen mal fand der merge day am vortag des release statt, nun zum ersten mal am mittwoch in der vorwoche. das hat einerseits, wie du schon vermutet hast, den vorteil dass die entwickler weiterhin durchgehend ihren code in nightly landen können, man aber dadurch automatisch eine art code freeze bzw stabilisierungsphase für 56.0b erhält (weil alles was seit mittwoch für beta landen soll braucht wieder uplift approval). andererseits fallen meistens bei jedem merge ein paar brösel an - es muss sichergestellt werden dass der code auch in der neuen umgebung alle tests durchläuft, erfolgreich kompiliert etc - in den letzten tagen wurde also geschaut dass da wieder alle indikatoren auf grün sind.
    zudem wird noch jeder beta build vor der freigabe manuell von qa-testern geprüft - in der release woche kümmern die sich aber vordringlich um das absegnen der release builds, update-tests etc...