cvs: peardoc /hu/chapters contributing.xml

norbert_m Sat Apr 3 12:56:58 2004 EDT Added files: /peardoc/hu/chapters contributing.xml Log: initial commit http://cvs.php.net/co.php/peardoc/hu/chapters/contributing.xml?r=1.1&p=1 Index: peardoc/hu/chapters/contributing.xml +++ peardoc/hu/chapters/contributing.xml <?xml version="1.0" encoding="iso-8859-2" ?> <!-- Sync: 1.9 --> <chapter id="contributing"> <docinfo> <author> <firstname>Tal</firstname> <surname>Peer</surname> </author> <author> <firstname>Martin</firstname> <surname>Jansen</surname> </author> <date>2003-03-21</date> </docinfo> <title>Közremûködés</title> <simpara> Ez a fejezet a PEAR-ben való közremûködési lehetõségekrõl nyújt leírást. </simpara> <sect1 id="contributing.introduction"> <title>Bevezetés</title> <simpara> A PEAR egy nyílt forrású projekt, ami azt jelenti, hogy mindenki részt vehet a fejlesztésében. A PEAR fejlesztése alatt nem csak kód írását értjük. Beletartozik bug-ok jelentése, visszajelzés nyújtása, új funkcionalitások igénylése és anyagi támogatás is. </simpara> </sect1> <sect1 id="contributing.newpackage"> <title>Új csomagok készítése</title> <para> Új csomagok készítésérõl részletes leírás található a <link linkend="guide-developers">Fejlesztõk Kalauzá</link>ban. </para> </sect1> <sect1 id="contributing.patches"> <title>Foltok készítése</title> <para> 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). </para> <para> 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): <screen> <command>cvs -d:pserver:cvsread@cvs.php.net:/repository login</command> a jelszó "phpfi" <command> cvs -z3 -d:pserver:cvsread@cvs.php.net:/repository co pear/Foo_Bar </command> </screen> 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. </para> <para> 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: <screen> <command>cd pear/Foo_Bar</command> <command>cvs diff -u >Foo_Bar.diff</command> </screen> 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. </para> <para> A következõ lépés a patch elküldése. Küldjünk egy mailt a &email.pear.dev; 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 &url.pear; címen. </para> <note> <para> 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 <literal>text/plain</literal> típusként ismeri fel a fájlt, és a PEAR szerver levelezõlista-szoftvere elutasítaná azt. </para> </note> <note> <para> 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. </para> </note> </sect1> <sect1 id="contributing.bugs"> <title>Bugok jelentése</title> <para> Ha úgy gondoljuk, hogy találtunk egy bug-ot egy PEAR csomagban, elsõként mindig gyõzõdjünk meg róla, hogy a csomag legfrissebb verzióját használjuk, és hogy az általunk használt rendszer eleget tesz a csomag követelményeinek. </para> <para> Ha a bug a csomag legutóbbi verziójában is jelen van, töltsünk ki egy hibajelentést (bug report). Ennek a legegyszerûbb módja, ha a <quote>Package Bugs</quote> linkre kattintunk a csomag információs lapján a <ulink url="&url.pear;">PEAR weboldalon</ulink>. Ezzel eljutunk a csomag hibáinak listájához. Ellenõrizzük kétszer, hogy a bug-ot nem jelentették-e már elõttünk! Ha nem találjuk a listában, kattintsunk a <quote>Report a new bug</quote> linkre az ûrlap kitöltéséhez! </para> <para> További információ és a hibajelentés megfelelõ módjával kapcsolatos tippek <ulink url="&url.php.bugs.howto;">ezen a címen</ulink> találhatók. </para> <para> Ha kijavítottunk egy talált hibát a csomagban, olvassuk el <link linkend="contributing.patches">ezt!</link> </para> </sect1> <sect1 id="contributing.wishlist"> <title>Kívánságlisták</title> <para> Néhány PEAR fejlesztõnek saját kívánságlistája van az Amazonon, vagy valamilyen hasonló szolgáltatást nyújtó weboldalon. Ha elismerjük egy-egy fejlesztõ munkáját, vásároljunk valamit a kívánságlistájáról. A kívánságlista megtalálásához keressük ki a fejlesztõt az <ulink url="&url.pear.account;">account listából</ulink>, nézzük meg a fejlesztõrõl szóló részletes leírást, és látni fogjuk, hogy rendelkezik-e kívánságlistával. A fejlesztõ megajándékozása még a bugok javításának idejét is lerövidítheti ;-) </para> </sect1> </chapter> <!-- Keep this comment at the end of the file Local variables: mode: sgml sgml-omittag:t sgml-shorttag:t sgml-minimize-attributes:nil sgml-always-quote-attributes:t sgml-indent-step:1 sgml-indent-data:t sgml-parent-document:nil sgml-default-dtd-file:"../../manual.ced" sgml-exposed-tags:nil sgml-local-catalogs:nil sgml-local-ecat-files:nil End: vim600: syn=xml fen fdm=syntax fdl=2 si vim: et tw=78 syn=sgml vi: ts=1 sw=1 -->