Ha módosítunk egy csomagot (akár a funkcionalitása kibővítésével, akár egy bug javításával), küldjük vissza a módosított változatot a PEAR közösségnek (néhány licensz kötelez erre, de "erkölcsileg" egyébként is ajánlott a visszajuttatás).

Mielőtt elkészítjük a patch-et, elsőként szerezzük be a patch-elendő csomag legfrissebb forrásait a CVS-ből a következő parancssor segítségével (a csomag neve a következő példában Foo_Bar):

cvs -d:pserver:[email protected]:/repository login
a jelszó "phpfi"

cvs -z3 -d:pserver:[email protected]:/repository co pear/Foo_Bar

   

Most, hogy hozzájutottunk a legfrissebb forrásokhoz, szerkeszthetjük a tárgyhoz tartozó fájl(oka)t. Győződjünk meg róla, hogy a patch teljesen kompatibilis a PEAR kódolási szabványokkal.

Miután befejeztük a kód hozzáadását/módosítását, TESZTELJÜK: a PEAR közösség nem fogadja el a nem gondosan tesztelt kódokat. Ha teljesen biztosak vagyunk benne, hogy az új kód nem vezet új bug-okhoz, készítsünk egy "unified diff"-et a következő parancssor lefuttatásával:

cd pear/Foo_Bar
cvs diff -u >Foo_Bar.diff
   

A keletkező .diff fájl tartalmazza a patch-et. Ez a diff teszi könnyűvé a PEAR közösség számára a változások áttekintését.

A következő lépés a patch elküldése. Küldjünk egy mailt a [email protected] címre, és Cc-zzük a levelet a csomag karbantartójának (karbantartóinak). A tárgyat a '[Patch]' szóval prefixejük, hogy ránézésre látszódjon az e-mailről, hogy patch küldésről van szó. Ezen kívül mellékeljünk részletes magyarázatot arról, hogy a patch mit tesz pontosan. Ne felejtsük el a .diff fájlt csatolni az e-mailhez. A csomag karbantartóinak listáját általában megtaláljuk minden forrásfájl fejlécében. Ettől függetlenül az e-mail címeik mindig megtalálhatók az adott csomag információs lapján a http://pear.php.net/ címen.

Outlook és Outlook Express levelezőkliens használata esetén változtassuk a diff kiterjesztést .txt-re, egyébként az Outlook MIME-típus felismerője nem text/plain típusként ismeri fel a fájlt, és a PEAR szerver levelezőlista-szoftvere elutasítaná azt.

A csomag karbantartói valószínűleg nem fogadják majd túl boldogan a patch-et, ha az megtöri a visszafelé-kompatibilitást. Ezért mindig próbáljunk úgy javítani egy-egy hibát, hogy az ne változtasson komolyan a publikus API-n. Ha egyáltalán nincs mód a kompatibilitás megőrzésére és/vagy a patch egetrengető fejlesztéseket tartalmaz, még az API változtatások is elfogadhatók lehetnek.