Ist es möglich, einen Patch in die aktuelle Version aufzunehmen? Wenn das so ist, wie?

Vor einiger Zeit habe ich einen Fehler im Place Window-Plugin von Compiz gemeldet . Es ist eine ziemlich große Regression für die Menschen, die davon betroffen sind: vor allem diejenigen, die Gnome-Fallback verwenden, nach den Berichten zu urteilen.

Ein Patch tauchte kurze Zeit später auf. Ich habe ein PPA zum Testen erstellt und alle Beteiligten berichten, dass die Probleme behoben sind. Es behebt sogar einen weiteren Fehler . Ich habe Tests mit einem Standard-Unity-Desktop durchgeführt und kann (für meine Tests) sagen, dass keine nachteiligen Auswirkungen sichtbar waren.

Ich möchte dies jetzt aus zwei Hauptgründen auf Ubuntu übertragen:

• Ich bin Egoistisch. Ich möchte meine PPA nicht jedes Mal aktualisieren müssen, wenn eine neue Version von Compiz auf 12.04 aktualisiert wird.
• Ich möchte nicht, dass Ubuntu-Benutzer ihre Fenster wegen eines dummen kleinen Fehlers herumfliegen sehen.

Ich möchte, dass dieser Patch so schnell wie möglich auf Ubuntus Compiz-Version übertragen wird, damit wir diese Fehler als behoben markieren und unser Leben fortsetzen können.

Wessen Bein muss ich jetzt humpen, um dies in Ubuntu zu bekommen?

Ich betreue dieses Projekt nicht und es ist eine vorgelagerte Sache, aber es ist ziemlich wichtig für Ubuntu. Ich könnte zu Compiz gehen, aber ich stelle mir vor, dass es Monate dauern wird (zumindest eine Veröffentlichung), bis der Patch irgendwo in der Nähe von Ubuntu ist, wenn sie den Patch akzeptieren.

Und wenn ich die richtige Person gefunden habe, wie kann ich den Prozess für sie so raffiniert wie möglich gestalten?

Ich möchte, dass sie meine Anfrage sehen, gehen Sie zu "Yup, das sieht alles gut aus, fertig" und das sei es. Ich möchte nicht, dass siebzehn E-Mail-Runden Aspekte des Patches ansprechen. Noch wichtiger ist, ich möchte auch nicht ihre Zeit verschwenden.

Und was muss ich ihnen bieten? Meine Verpackungsfähigkeiten sind ... bedauerlich. Dies war mein erster Versuch, ein Paket für die Neuverteilung zu patchen, sodass ich wahrscheinlich jeden einzelnen Verpackungsfehler dem Menschen bekannt gemacht habe. Werden sie mit dem Original-Patch zufrieden sein (damit sie ihn selbst anwenden können) oder sollte ich die Dinge neu packen, damit das Diff / Changelog ein wenig sauberer wird (es hat ein paar Mal gedauert und die Versionierung ist überall)?

_{Hinweis: Bei dieser Frage geht es um Compiz, aber ich würde es vorziehen, wenn die Antworten auch andere Arten von Paketen beantworten könnten.}

Wie Dobey bereits erwähnt hat, muss ein Patch, damit er in eine bereits veröffentlichte Version von Ubuntu aufgenommen werden kann, den SRU-Prozess ( Stable Release Update ) durchlaufen. Die Eintrittsbarriere für SRUs ist ziemlich hoch. Ein einfacher Weg, um das Denken hinter dem Prozess zusammenzufassen, könnte sein: "Der Fehler, den wir kennen, ist besser als der Fehler, den wir nicht kennen." In der Praxis bedeutet dies, dass nur gezielte Fehlerkorrekturen zulässig sind und keine zu "aufdringlichen" Änderungen.

Es gibt eine Reihe von Anforderungen, die erfüllt sein müssen, um mit einer SRU fortzufahren:

• Der Fehler ist in der aktuellen Entwicklungsversion behoben (dh quantal).
• Die Beschreibung des Fehlerberichts muss aktualisiert werden, um zu begründen, warum die Korrektur in der stabilen Version benötigt wird, einen Testfall, um den Fehler zu reproduzieren und zu überprüfen, ob er behoben wurde, und eine Erläuterung des Regressionspotenzials der Korrektur.
• Das Launchpad-Team ubuntu-srusollte den Fehlerbericht abonniert haben.
• Das Paket wird dann zur Veröffentlichung hochgeladen. -proposedDazu müssen Sie den Sponsoring-Prozess durchlaufen (weitere Informationen siehe unten).

Nach all dem überprüft das SRU-Team, ob das Paket -proposedden Fehler behebt. -updatesNach einer Mindestalterungszeit von 7 Tagen wird die Packung eingeschoben .

Die richtige Person finden

Ihre Frage deutet darauf hin, dass bei Launchpad manchmal Patches sterben. Leider kann es sich so anfühlen, wenn Sie den Prozess nicht kennen, aber ich schwöre, dass es nicht wirklich so schlimm ist. Zum Glück ist die Hauptsache, die Sie wissen müssen, einfach. Sehen Sie sich den Sponsoring-Prozess an, um alle Details und einige Hinweise zu erhalten. Der wichtigste Teil ist jedoch, das ubuntu-sponsorsTeam für den Fehlerbericht zu registrieren. Das stellt sicher, dass es in der Sponsoring-Warteschlange auftaucht und von einem ehrlichen Ubuntu-Entwickler angeschaut wird.

Wenn Sie in Echtzeit etwas #ubuntu-develbesprechen müssen, ist der IRC von Freenode genau das Richtige. Überprüfen Sie das Kanalthema für den aktuellen Patch-Pilot. Sie sind da, um dir zu helfen. Wenn kein Pilot im Dienst ist, können Sie im Kanal um Hilfe bitten, aber bitte haben Sie etwas Geduld.

Alles fertig machen

Damit der Prozess so schnell wie möglich abläuft, gibt es ein paar Dinge zu tun.

Aktualisieren Sie die Fehlerbeschreibung so, dass sie wie folgt aussieht:

[Einschlag]

Hier finden Sie eine Erläuterung der Auswirkungen des Fehlers auf die Benutzer und eine Begründung für das Zurückportieren des Fixes auf die stabile Version

[Testfall]

1. Schritt

2. Durch

3. Schritt

4. Anleitung

5. Verifizieren

6. Die Reparatur

[Regressionspotential]

Hier ist eine Diskussion über mögliche Rückschritte.

[Originalbericht]

Alles, was früher in der Beschreibung stand, bleibt unten erhalten.

Bereiten Sie als Nächstes Ihre Patches vor. Die Dinge werden viel schneller gehen, wenn Sie Debdiffs bereitstellen , die sich um alle Packungsbits kümmern , anstatt einen Patch gegen die Upstream-Quelle zu erstellen . Dies schließt die Verwendung des Paket-Patch-Systems ein, falls es eines verwendet. Zum Glück add-patchvon ubuntu-dev-Tools für Sie darum kümmern.

Lass uns das durchgehen. Holen Sie sich zuerst die Quelle und den Patch im Fehlerbericht:

$ pull-lp-source compiz precise
$ wget https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/974242/+attachment/3141645/+files/fix-974242.patch 

Jetzt fügen wir den Patch zum Quellpaket hinzu:

$ cd compiz-0.9.7.8/
$ add-patch ../fix-974242.patch

Dadurch wird der Patch hinzugefügt debian/patchesund ausgeführt, dchund Sie werden aufgefordert, einen neuen Eintrag hinzuzufügen, um debian/changelogden Eintrag an das vorgeschlagene Ziel anzupassen und die Versionsnummer zu erhöhen, sodass er unter der nächsten Version liegt, die in die Entwicklungsversion hochgeladen wurde. Wie so:

compiz (1:0.9.7.8-0ubuntu1.1) precise-proposed; urgency=low

  * debian/patches/fix-974242.patch: [DESCRIBE CHANGES HERE]

 -- Your Name <you@example.com>  Mon, 11 Jun 2012 17:37:59 -0400

Die Datei debian/patches/fix-974242.patchunter hat auch einige Überschriften, die Sie möglicherweise bearbeiten möchten:

## Description: add some description
## Origin/Author: add some origin or author
## Bug: bug URL

Erstellen Sie jetzt Ihr neues Quellpaket:

$ debuild -S -us

Und erstelle den Debdiff:

$ cd ..
$ debdiff compiz_0.9.7.8-0ubuntu1.dsc compiz_0.9.7.8-0ubuntu1.1.dsc > sru-for-lp-974242.debdiff

Sie können nun die resultierende debdiffDatei an Ihren Fehlerbericht anhängen .

Es würde ein Stable Release Update erfordern, um es am 12.04 zu versenden. Unter https://wiki.ubuntu.com/StableReleaseUpdates finden Sie Informationen zu akzeptablen Arten von Fixes und Verfahren zum Einspielen dieser Fixes.