Est-il possible d'obtenir un patch inclus dans la version actuelle? Si c'est le cas, comment?

Il y a quelque temps, j'ai signalé un bug dans le plugin Compiz's Place Window . C'est une régression assez importante pour les personnes concernées: principalement celles utilisant Gnome-Fallback, à en juger par les rapports.

Un patch est apparu peu de temps après. J'ai créé un PPA pour les tests et toutes les personnes impliquées jusqu'à présent signalent que les problèmes sont résolus. Il corrige même un autre bug . J'ai fait des tests avec un bureau Unity standard et je peux dire (pour mes tests) qu'aucun effet indésirable n'était visible.

Je veux que cela soit transmis à Ubuntu en ce moment pour deux raisons principales:

• Je suis égoïste. Je ne veux pas avoir besoin de mettre à jour mon PPA chaque fois qu'une nouvelle version de Compiz est poussée vers 12.04.
• Je ne veux pas que les utilisateurs d'Ubuntu voient leurs fenêtres voler à cause d'un petit bug idiot.

Je veux que ce correctif soit transmis à la version d'Ubuntu de Compiz dès que possible, afin que nous puissions marquer ces bogues corrigés et continuer notre vie.

Quelle jambe dois-je bosser pour que cela soit intégré à Ubuntu en ce moment?

Je ne maintiens pas ce projet et c'est une chose en amont mais il fait assez partie intégrante d'Ubuntu. Je pourrais aller à Compiz mais j'imagine que s'ils acceptent le correctif, il faudra des mois (au moins une version) avant qu'il ne se trouve près d'Ubuntu.

Et quand je trouve la bonne personne, comment puis-je rendre le processus aussi simple que possible pour eux?

Je veux qu'ils voient ma demande, disent "Ouaip, ça a l'air super, c'est fait" et que ce soit. Je ne veux pas dix-sept séries d'e-mails traitant des aspects du correctif. Plus important encore, je ne veux pas perdre leur temps non plus.

Et que dois-je leur fournir? Mes compétences en emballage sont ... lamentables. C'était ma première tentative de patcher un paquet pour la redistribution, j'ai donc probablement fait part de chaque erreur d'emballage à l'homme. Seront-ils satisfaits du patch d'origine (afin qu'ils puissent l'appliquer eux-mêmes) ou devrais-je reconditionner les choses pour que le journal des différences / modifications soit un peu plus propre (il m'a fallu quelques essais et le versioning est partout).

_{Note: Cette question est au sujet de Compiz , mais je préférerais que des réponses pourraient aborder d' autres styles du paquet trop si nous avons un fil et la plus complète de la façon de faire avancer les choses fixes.}

Comme Dobey l'a mentionné, pour qu'un correctif soit accepté dans une version déjà publiée d'Ubuntu, il doit passer par le processus de mise à jour de version stable (SRU). La barre à l'entrée pour les SRU est assez élevée. Un moyen simple de résumer la réflexion derrière le processus pourrait être: "Le bogue que nous connaissons est meilleur que le bogue que nous ne connaissons pas." En pratique, cela signifie que seules les corrections de bogues ciblées sont autorisées et aucune modification trop «intrusive».

Un certain nombre d'exigences doivent être remplies pour procéder à une SRU:

• Le bogue est corrigé dans la version de développement actuelle (c'est-à-dire quantique).
• La description du rapport de bogue doit être mise à jour pour inclure une justification de la raison pour laquelle le correctif est nécessaire dans la version stable, un scénario de test pour reproduire le bogue et vérifier qu'il a été corrigé, et une discussion sur le potentiel de régression du correctif.
• L'équipe Launchpad ubuntu-srudoit être abonnée au rapport de bogue.
• Le package est ensuite téléchargé pour être libéré-proposed Pour que cela se produise, vous devrez suivre le processus de parrainage (plus d'informations ci-dessous).

Après tout ce qui s'est passé, l'équipe SRU vérifiera que le package -proposedrésout le bogue. Ensuite, le colis sera poussé -updatesaprès avoir passé une période de vieillissement minimale de 7 jours.

Trouver la bonne personne

Votre question fait allusion au fait que parfois Launchpad semble être l'endroit où les correctifs vont mourir. Malheureusement, si vous ne connaissez pas le processus, cela peut ressembler à ça, mais je jure que ce n'est pas vraiment si mal. Heureusement, la principale chose que vous devez savoir est simple. Consultez le processus de parrainage pour tous les détails et quelques conseils, mais la partie la plus importante est de souscrire l' ubuntu-sponsorséquipe au rapport de bogue. Cela garantit qu'il apparaîtra dans la file d'attente de parrainage et sera examiné par un développeur honnête à Dieu Ubuntu.

Si vous avez besoin de discuter de quelque chose en temps réel, #ubuntu-develsur Freenode IRC fera l'affaire. Vérifiez la rubrique de canal pour le pilote de patch actuel. Ils sont là pour vous aider. S'il n'y a pas de pilote en service, n'hésitez pas à demander de l'aide sur le canal, mais soyez patient.

Tout est prêt à partir

Afin de faire avancer le processus le plus rapidement possible, il y a quelques choses à faire.

Mettez à jour la description du bogue pour qu'il ressemble à:

[Impact]

Voici une explication de l'impact du bogue sur les utilisateurs et une justification du rétroportage du correctif vers la version stable

[Cas de test]

1. Étape

2. Par

3. Étape

4. Instructions

5. Vérifier

6. The Fix

[Potentiel de régression]

Voici une discussion de tout potentiel de régression.

[Rapport original]

Tout ce qui était dans la description est conservé ci-dessous.

Ensuite, préparez vos patchs. Les choses iront beaucoup plus vite si vous fournissez des debdiffs qui prennent en charge tous les bits d'emballage plutôt qu'un correctif contre la source en amont. Cela inclut l'utilisation du système de correctifs des packages s'il en utilise un. Heureusement , add-patchde ubuntu-dev-tools peut prendre en charge pour vous.

Voyons cela. Saisissez d'abord la source et le correctif dans le rapport de bogue:

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

Nous allons maintenant ajouter le patch au package source:

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

Cela ajoutera le correctif debian/patcheset s'exécutera, dchvous invitant à ajouter une nouvelle entrée pour debian/changelogAjuster l'entrée à la cible proposée et incrémenter le numéro de version afin qu'il soit inférieur à la prochaine version téléchargée dans la version de développement. Ainsi:

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

Le fichier à debian/patches/fix-974242.patchcontient également des en-têtes que vous souhaiterez peut-être modifier:

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

Maintenant, construisez votre nouveau paquet source:

$ debuild -S -us

Et créez le debdiff:

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

Vous pouvez maintenant joindre le debdifffichier résultant à votre rapport de bogue.

Il faudrait une mise à jour de version stable pour l'expédier au 12.04. Voir https://wiki.ubuntu.com/StableReleaseUpdates pour les types de correctifs acceptables et la procédure pour les obtenir.