perlpolicy - Online sa Cloud

PROGRAMA:

NAME

perlpolicy - Iba't iba at sari-saring mga patakaran at pangako na nauugnay sa core ng Perl

DESCRIPTION

Ang dokumentong ito ay ang pangunahing dokumento na nagtatala ng lahat ng nakasulat na patakaran tungkol sa kung paano ang Perl
5 Ang mga porter ay sama-samang bumuo at nagpapanatili ng Perl core.

PAMAMARAAN

Perl 5 Mga porter
Ang mga subscriber sa perl5-porter (ang mga porter mismo) ay may iba't ibang lasa. Ang ilan ay
tahimik na curious lurkers, na bihirang mag-pitch at sa halip ay panoorin ang patuloy na pag-unlad sa
tiyaking binalaan sila ng mga bagong pagbabago o feature sa Perl. Ang ilan ay mga kinatawan ng
mga vendor, na naroroon upang matiyak na patuloy na mag-compile at magtrabaho si Perl sa kanilang
mga platform. Ang ilan ay nag-patch ng anumang naiulat na bug na alam nila kung paano ayusin, ang ilan ay aktibo
paglalagay ng kanilang pet area (mga thread, Win32, ang regexp -engine), habang ang iba ay tila ginagawa
walang iba kundi magreklamo. Sa madaling salita, ito ang iyong karaniwang halo ng mga teknikal na tao.

Sa grupong ito ng mga porter ang namumuno kay Larry Wall. Nasa kanya ang huling salita sa kung ano ang ginagawa at
ay hindi nagbabago sa alinman sa mga wikang programming ng Perl. Sa mga araw na ito, si Larry ang higit na gumagastos
ng kanyang panahon sa Perl 6, habang ang Perl 5 ay pinapastol ng isang "pumpking", isang porter na responsable
para sa pagpapasya kung ano ang papasok sa bawat release at pagtiyak na ang mga release ay nangyayari nang regular
batayan.

Nakikita ni Larry ang pag-unlad ng Perl sa mga linya ng gobyerno ng US: nariyan ang Lehislatura
(ang mga porter), ang Executive branch (ang -pumpking), at ang Korte Suprema (Larry). Ang
maaaring talakayin at isumite ng lehislatura ang mga patch sa sangay ng ehekutibo sa lahat ng gusto nila, ngunit ang
Ang sangay ng ehekutibo ay malayang i-veto ang mga ito. Bihira, ang Korte Suprema ay papanig sa
ehekutibong sangay sa lehislatura, o ang lehislatura sa ehekutibong sangay.
Kadalasan, gayunpaman, ang lehislatura at ang ehekutibong sangay ay dapat na magkasundo at
ayusin ang kanilang mga pagkakaiba nang walang impeachment o mga kaso sa korte.

Minsan maaari kang makakita ng reference sa Rule 1 at Rule 2. Ang kapangyarihan ni Larry bilang Supreme Court
ipinahayag sa The Rules:

1. Laging tama si Larry sa kahulugan tungkol sa kung paano dapat kumilos si Perl. Ibig sabihin meron siya
panghuling kapangyarihan ng veto sa pangunahing pag-andar.

2. Pinahihintulutan si Larry na magbago ng isip tungkol sa anumang bagay sa ibang araw, anuman ang
kung dati niyang ginamit ang Rule 1.

Nakuha na? Si Larry ay palaging tama, kahit na siya ay mali. Ito ay bihirang makita ang alinman sa Rule
ginagamit, ngunit madalas silang tinutukoy.

Pagpapanatili AT SUPORTA

Ang Perl 5 ay binuo ng isang komunidad, hindi isang corporate entity. Nag-ambag ang bawat pagbabago
ang Perl core ay resulta ng isang donasyon. Kadalasan, ang mga donasyong ito ay mga kontribusyon ng
code o oras ng mga indibidwal na miyembro ng ating komunidad. Kung minsan, pumapasok ang mga donasyong ito
ang anyo ng corporate o organizational sponsorship ng isang partikular na indibidwal o proyekto.

Bilang isang boluntaryong organisasyon, ang mga pangakong ginagawa namin ay lubos na nakadepende sa mabuting kalooban
at pagsusumikap ng mga indibidwal na walang obligasyon na mag-ambag sa Perl.

Iyon ay sinabi, pinahahalagahan namin ang katatagan at seguridad ni Perl at matagal nang hindi nakasulat
nakipagtipan sa mas malawak na komunidad ng Perl na suportahan at panatilihin ang mga release ng Perl.

Kino-code ng dokumentong ito ang mga pangako sa suporta at pagpapanatili ng komunidad ng Perl
dapat asahan mula sa mga developer ng Perl:

· "Opisyal" naming sinusuportahan ang dalawang pinakabagong serye ng stable na release. 5.16.x at mas maaga
wala na ngayon sa suporta. Sa paglabas ng 5.22.0, "opisyal" naming tatapusin ang suporta
para sa Perl 5.18.x, maliban sa pagbibigay ng mga update sa seguridad tulad ng inilarawan sa ibaba.

· Sa abot ng aming makakaya, susubukan naming ayusin ang mga kritikal na isyu sa dalawa
kamakailang stable 5.x release series. Mga pag-aayos para sa kasalukuyang paglabas ng serye
nangunguna sa mga pag-aayos para sa nakaraang serye ng paglabas.

· Sa abot ng aming makakaya, magbibigay kami ng "kritikal" na mga patch / release para sa seguridad
anumang pangunahing bersyon ng Perl na ang 5.x.0 ay inilabas sa loob ng nakaraang tatlong taon. kaya natin
mangako lamang sa pagbibigay ng mga ito para sa pinakakamakailang .y na release sa anumang serye ng 5.xy.

· Hindi kami magbibigay ng mga update sa seguridad o pag-aayos ng bug para sa mga pagpapalabas ng development ng Perl.

· Hinihikayat namin ang mga vendor na ipadala ang pinakabagong sinusuportahang release ng Perl sa oras ng
nag-freeze ang kanilang code.

· Bilang isang vendor, maaaring mayroon kang isang kinakailangan upang i-backport ang mga pag-aayos sa seguridad lampas sa aming 3 taon
pangako ng suporta. Maaari kaming magbigay ng limitadong suporta at payo sa iyo habang ginagawa mo ito
at, kung saan posible ay susubukan na ilapat ang mga patch na iyon sa mga nauugnay na -maint na sangay sa
git, kahit na maaari o hindi namin piliin na gumawa ng mga paglabas na may numero o "opisyal" na mga patch
magagamit. Makipag-ugnayan sa amin sa[protektado ng email]> upang simulan ang prosesong iyon.

BALIK Kakayahan na AT DEPRECATION

Ang aming komunidad ay may matagal nang paniniwala na ang backward-compatibility ay isang birtud, kahit na kailan
ang functionality na pinag-uusapan ay isang depekto sa disenyo.

Gusto nating lahat na alisin ang ilang mga pagkakamaling nagawa natin sa nakalipas na mga dekada. Kasama si
bawat pagkakamali sa disenyo na nagawa natin ay maaaring humantong sa masakit na pagwawalang-kilos. Pag-alis ng ating mga pagkakamali
ay napakahirap. Ang paggawa nito nang hindi aktibong sinasaktan ang aming mga user ay halos
imposible.

Kamakailan lamang, ang pagbabalewala o aktibong pagsalungat sa pagiging tugma sa mga naunang bersyon ng Perl ay dumating
sa uso. Minsan, iminungkahi ang isang pagbabago na gustong agawin ang syntax na dati
nagkaroon ng ibang kahulugan. Minsan, gustong pahusayin ng pagbabago ang dating nakakabaliw na semantika.

Sa kalsadang ito ay namamalagi ang kabaliwan.

Nangangailangan sa mga end-user programmer na baguhin lamang ang ilang mga construct ng wika, maging ang wika
mga konstruksyon na hindi sinasadyang gamitin ng walang mahusay na pinag-aralan na developer ay katumbas ng
nagsasabing "hindi ka dapat mag-upgrade sa isang bagong release ng Perl maliban kung mayroon kang 100% na saklaw ng pagsubok
at makakagawa ng buong manu-manong pag-audit ng iyong codebase." Kung magkakaroon tayo ng mga tool na kayang gawin
mapagkakatiwalaang pag-upgrade ng Perl source code mula sa isang bersyon ng Perl patungo sa isa pa, ang pag-aalalang ito
maaaring makabuluhang bawasan.

Nais naming matiyak na ang Perl ay patuloy na lalago at yumayabong sa mga darating na taon at
dekada, ngunit hindi sa kapinsalaan ng aming komunidad ng gumagamit.

Ang umiiral na syntax at semantics ay dapat lamang markahan para sa pagkasira sa napakalimitado
mga pangyayari. Kung ang mga ito ay pinaniniwalaan na napakabihirang gamitin, tumayo sa paraan ng aktwal
pagpapabuti sa Perl na wika o perl interpreter, at kung maaapektuhan ang code ay madali
na-update upang magpatuloy sa pagtatrabaho, maaari silang isaalang-alang para sa pag-aalis. Kapag may pagdududa, mag-ingat
nagdidikta na papaboran natin ang backward compatibility. Kapag ang isang feature ay hindi na ginagamit, a
Ipo-post ang pahayag ng pangangatwiran na naglalarawan sa proseso ng pagpapasya, at isang link dito
ibibigay sa mga nauugnay na dokumento ng perldelta.

Ang paggamit ng lexical pragma upang paganahin o huwag paganahin ang legacy na pag-uugali ay dapat isaalang-alang kung kailan
naaangkop, at sa kawalan ng anumang pragma legacy na pag-uugali ay dapat paganahin. Alin
Ang paatras na hindi tugmang mga pagbabago ay hindi tuwirang kinokontrol ng isang 'paggamit ng v5.xy' ay isang desisyon
na dapat gawin ng pumpking sa konsultasyon sa komunidad.

Sa kasaysayan, pinananatili namin ang aming sarili sa isang mas mataas na pamantayan kaysa sa backward-compatibility --
bugward-compatibility. Anumang aksidente ng pagpapatupad o hindi sinasadyang side-effect ng
Ang pagpapatakbo ng ilang piraso ng code ay itinuturing na isang tampok ng wikang magiging
ipinagtanggol na may parehong kasigasigan tulad ng anumang iba pang tampok o pag-andar. Gaano man
maaaring nakakabigo sa hindi sinasadyang mga tampok na ito sa amin habang patuloy naming pinapahusay ang Perl,
ang mga hindi sinasadyang tampok na ito ay kadalasang nararapat sa ating proteksyon. Napakahalaga niyan
ang umiiral na software na nakasulat sa Perl ay patuloy na gumagana nang tama. Kung mayroon ang mga developer ng end-user
nagpatibay ng isang bug bilang isang tampok, kailangan namin itong tratuhin bilang ganoon.

Ang mga bagong syntax at semantics na hindi sumisira sa mga umiiral na construct ng wika at ang syntax ay may a
mas mababang bar. Kailangan lang nilang patunayan ang kanilang sarili na maging kapaki-pakinabang, matikas, mabuti
dinisenyo, at mahusay na nasubok. Sa karamihan ng mga kaso, ang mga karagdagan na ito ay mamarkahan bilang pagsubok
para sa ilang oras. Tingnan sa ibaba para sa higit pa tungkol diyan.

Terminolohiya
Upang matiyak na pareho ang pinag-uusapan natin kapag tinatalakay natin ang pag-alis ng mga feature o
functionality mula sa Perl core, mayroon kaming mga tiyak na kahulugan para sa ilang salita at
parirala.

pagsubok
Kung ang isang bagay sa Perl core ay minarkahan bilang pagsubok, maaari nating baguhin ang pag-uugali nito,
tanggalin o alisin ito nang walang abiso. Habang lagi naming gagawin ang aming makakaya upang pakinisin ang
transition path para sa mga user ng mga pang-eksperimentong feature, dapat kang makipag-ugnayan sa
perl5-porters mailinglist kung nakita mong kapaki-pakinabang ang isang pang-eksperimentong feature at gusto mong tumulong
hubugin ang kinabukasan nito.

Dapat na pang-eksperimento ang mga pang-eksperimentong feature sa dalawang stable na release bago mamarkahan
hindi pang-eksperimento. Ang mga pang-eksperimentong feature ay magkakaroon lamang ng kanilang pang-eksperimentong katayuan
binawi kapag wala na silang anumang mga bug sa pagbabago ng disenyo na bukas laban sa kanila at kung kailan
sila ay nanatiling hindi nagbabago sa pag-uugali para sa buong haba ng isang ikot ng pag-unlad.
Sa madaling salita, ang isang tampok na nasa v5.20.0 ay maaaring mamarkahan na hindi na pang-eksperimento
v5.22.0 kung at kung ang pag-uugali nito ay hindi nagbabago sa lahat ng v5.21.

hindi na ginagamit
Kung ang isang bagay sa Perl core ay minarkahan bilang hindi na ginagamit, maaari naming alisin ito mula sa core
sa hinaharap, kahit na maaaring hindi. Sa pangkalahatan, ang mga pabalik na hindi tugmang pagbabago ay gagawin
may mga babala sa paghinto sa paggamit para sa dalawang ikot ng paglabas bago alisin, ngunit maaaring
inalis pagkatapos lamang ng isang cycle kung ang panganib ay tila medyo mababa o ang mga benepisyo ay medyo mataas.

Simula sa Perl 5.12, ang mga hindi na ginagamit na feature at module ay nagbababala sa user habang ginagamit ang mga ito. Kailan
ang isang module ay hindi na ginagamit, ito rin ay gagawing available sa CPAN. Pag-install nito mula sa
Patahimikin ng CPAN ang mga babala sa paghinto sa paggamit para sa module na iyon.

Kung gumagamit ka ng hindi na ginagamit na feature o module at naniniwala na ang pag-alis nito sa Perl
core ay isang pagkakamali, mangyaring makipag-ugnayan sa perl5-porters mailinglist at makiusap sa iyo
kaso. Hindi namin binabalewala ang mga bagay nang walang magandang dahilan, ngunit minsan may isang
kontraargumento na hindi namin isinasaalang-alang. Sa kasaysayan, hindi namin pinagkaiba ang pagitan
"hindi na ginagamit" at "nasiraan ng loob" na mga feature.

nasiraan ng loob
Paminsan-minsan, maaari naming markahan ang mga pagbuo ng wika at mga tampok na isinasaalang-alang namin
ay mga pagkakamali bilang nasiraan ng loob. Kasalukuyang hindi mga kandidato ang mga hindi hinihikayat na feature
para sa pag-alis, ngunit maaari naming ihinto ang paggamit sa mga ito sa ibang pagkakataon kung sila ay mapag-alamang humahadlang sa a
makabuluhang pagpapabuti sa Perl core.

inalis
Kapag ang isang feature, construct o module ay namarkahan bilang hindi na ginagamit, maaari naming alisin ito
mula sa Perl core. Hindi nakakagulat, sinasabi namin na kami inalis mga bagay na ito. Kapag ang isang module
ay inalis, hindi na ito ipapadala kasama ng Perl, ngunit patuloy na magiging available sa
CPAN.

Pagpapanatili MGA BRANCHES

Ang mga bagong release ng mga sangay ng pagpapanatili ay dapat lamang maglaman ng mga pagbabago na nahuhulog sa isa sa
"katanggap-tanggap" na mga kategoryang itinakda sa ibaba, ngunit hindi dapat maglaman ng anumang mga pagbabagong nahuhulog sa isa
ng "hindi katanggap-tanggap" na mga kategorya. (Halimbawa, ang pag-aayos para sa isang nag-crash na bug ay hindi dapat
kasama kung sinisira nito ang binary compatibility.)

Hindi kinakailangang isama ang bawat pagbabagong nakakatugon sa mga pamantayang ito, at sa pangkalahatan ang
dapat na tumuon sa pagtugon sa mga isyu sa seguridad, mga pag-crash na bug, regression at seryoso
mga isyu sa pag-install. Ang tuksong magsama ng napakaraming maliliit na pagbabago na hindi
makakaapekto sa pag-install o pagpapatupad ng perl (hal. pagwawasto ng spelling sa dokumentasyon)
ay dapat labanan upang mabawasan ang pangkalahatang panganib na matanaw ang isang bagay. Ang
ang intensyon ay gumawa ng mga maintenance release na parehong kapaki-pakinabang at kung aling mga user ang magagawa
magkaroon ng buong pagtitiwala sa katatagan ng. (Ang pangalawang alalahanin ay upang maiwasan ang pagkasunog
ang patuloy na pagbobomba o napakaraming iba pang mga committers na bumoboto sa mga pagbabagong isasama (tingnan
"Pagkuha ng mga pagbabago sa isang pangunahing sangay" sa ibaba).)

Ang mga sumusunod na uri ng pagbabago ay maaaring ituring na katanggap-tanggap, hangga't hindi rin
nabibilang sa alinman sa mga kategoryang "hindi katanggap-tanggap" na itinakda sa ibaba:

· Mga patch na nag-aayos ng mga CVE o mga isyu sa seguridad. Ang mga pagbabagong ito ay dapat isagawa sa pamamagitan ng
[protektado ng email] mailing list sa halip na direktang inilapat.

· Mga patch na nag-aayos ng mga nag-crash na bug, mga pagkabigo sa paninindigan at pagkasira ng memorya ngunit nagagawa
hindi baguhin ang functionality ng perl o negatibong nakakaapekto sa pagganap.

· Mga patch na nag-aayos ng mga regression sa gawi ni perl na may kaugnayan sa mga nakaraang release, hindi
kahit gaano katagal ang regression, dahil maaaring mag-upgrade ang ilang tao mula sa napakalumang bersyon ng
perl sa pinakabagong bersyon.

· Mga patch na nag-aayos ng mga bug sa mga feature na bago sa kaukulang 5.x.0 stable
pakawalan.

· Mga patch na nag-aayos ng anumang bagay na pumipigil o seryosong nakakaapekto sa build o
pag-install ng perl.

· Pag-aayos ng portable, tulad ng mga pagbabago sa I-configure at ang mga file sa mga pahiwatig/ folder.

· Mga kaunting patch na nag-aayos ng mga pagkabigo sa pagsubok na partikular sa platform.

· Mga update sa dokumentasyon na nagwawasto ng mga factual na error, nagpapaliwanag ng mga makabuluhang bug o
mga kakulangan sa kasalukuyang pagpapatupad, o ayusin ang sirang markup.

· Ang mga update sa dual-life module ay dapat na binubuo ng kaunting mga patch upang ayusin ang mga nag-crash na bug o
mga isyu sa seguridad (tulad ng nasa itaas). Anumang mga pagbabagong ginawa sa dual-life modules kung saan ang CPAN ay
kanonikal ay dapat na coordinated sa upstream na may-akda.

Ang mga sumusunod na uri ng pagbabago ay HINDI katanggap-tanggap:

· Mga patch na sumisira sa binary compatibility. (Mangyaring makipag-usap sa isang pumpking.)

· Mga patch na nagdaragdag o nag-aalis ng mga feature.

· Mga patch na nagdaragdag ng mga bagong babala o error o hindi na ginagamit ang mga feature.

· Mga Port ng Perl sa isang bagong platform, arkitektura o paglabas ng OS na kinasasangkutan ng mga pagbabago sa
ang pagpapatupad.

· HINDI dapat i-import sa maint ang mga bagong bersyon ng dual-life modules. Kasama ang mga iyon
ang susunod na matatag na serye.

Kung mayroong anumang tanong tungkol sa kung ang isang naibigay na patch ay maaaring maging karapat-dapat na maisama sa isang pagpapanatili
ilabas, kung gayon halos tiyak na hindi ito dapat isama.

Pagkuha mga pagbabago sa a mapanatili sangay
Sa kasaysayan, tanging ang pumpking cherry-picked ang nagbabago mula sa bleadperl patungo sa maintperl. Ito
may mga problema sa scaling. Kasabay nito, ang mga sangay ng pagpapanatili ng mga matatag na bersyon ng Perl
kailangang tratuhin nang may matinding pag-iingat. Sa layuning iyon, mula sa Perl 5.12, mayroon kaming bagong proseso
para sa mga pangunahing sangay.

Ang sinumang committer ay maaaring pumili ng anumang commit mula sa blead patungo sa isang pangunahing sangay kung magpapadala sila ng mail sa
perl5-porters na nag-aanunsyo ng kanilang layunin na pumili ng isang partikular na commit kasama ng a
katwiran para sa paggawa nito at hindi bababa sa dalawang iba pang committers tumugon sa listahan na nagbibigay ng kanilang
pagsang-ayon. (Nalalapat ang patakarang ito sa kasalukuyan at dating pumpking, pati na rin sa iba pa
mga committers.)

Ang iba pang mga mekanismo sa pagboto ay maaaring gamitin sa halip, hangga't ang parehong bilang ng mga boto ay
natipon sa isang malinaw na paraan. Sa partikular, ang mga panukala na nagbabago sa cherry-pick
ay dapat na nakikita ng lahat sa perl5-porter upang ang mga pananaw ng lahat ng interesado ay magkaroon
marinig.

Hindi kinakailangan para sa pagboto na gaganapin sa cherry-picking perldelta entries na nauugnay
na may mga pagbabagong napili na ng cherry, o para makuha ng maint-pumpking
mga boto sa mga pagbabagong kinakailangan ng Pag-port/release_managers_guide.pod kung saan magagawa ang mga ganitong pagbabago
ilapat sa pamamagitan ng paraan ng cherry-picking mula sa blead.

NAG-AMBAG MGA MODULO

A sosyal Kontrata tungkol sa Artistic Kontrolin
Ang sumusunod ay isang pahayag tungkol sa masining na kontrol, na tinukoy bilang kakayahan ng mga may-akda ng
mga pakete upang gabayan ang hinaharap ng kanilang code at mapanatili ang kontrol sa kanilang trabaho. Ito ay isang
pagkilala na ang mga may-akda ay dapat magkaroon ng kontrol sa kanilang gawa, at ito ay a
responsibilidad ng iba pang komunidad ng Perl na matiyak na mapapanatili nila ang kontrol na ito.
Ito ay isang pagtatangka na idokumento ang mga pamantayan kung saan kami, bilang mga developer ng Perl, ay nilalayon na hawakan
ating sarili. Ito ay isang pagtatangka na isulat ang mga magaspang na alituntunin tungkol sa paggalang na dapat nating bayaran sa bawat isa
iba pa bilang mga developer ng Perl.

Ang pahayag na ito ay hindi isang legal na kontrata. Ang pahayag na ito ay hindi isang legal na dokumento sa alinman
paraan, hugis, o anyo. Ang Perl ay ipinamamahagi sa ilalim ng GNU Public License at sa ilalim ng
Artistic License; iyon ang mga tiyak na legal na termino. Ang pahayag na ito ay hindi tungkol sa batas
o mga lisensya. Ito ay tungkol sa komunidad, paggalang sa isa't isa, pagtitiwala, at pakikipagtulungan ng may mabuting pananampalataya.

Kinikilala namin na ang Perl core, na tinukoy bilang ang software na ibinahagi sa puso ng
Ang Perl mismo, ay isang pinagsamang proyekto sa bahagi nating lahat. Paminsan-minsan, isang script,
module, o hanay ng mga module (pagkatapos dito ay tinutukoy lamang bilang isang "module") ay magpapatunay nito
malawak na kapaki-pakinabang at/o napakahalaga sa tamang paggana ng Perl mismo na dapat nito
ipamahagi gamit ang Perl core. Hindi ito dapat gawin nang wala ang may-akda
tahasang pagsang-ayon, at isang malinaw na pagkilala sa lahat ng bahagi na nangangahulugan ito na ang module ay ginagawa
ibinahagi sa ilalim ng parehong mga termino bilang Perl mismo. Dapat itong maunawaan ng isang may-akda ng module
Ang pagsasama ng isang module sa Perl core ay mangangahulugan ng ilang pagkawala ng kontrol sa
ito, dahil ang mga pagbabago ay maaaring paminsan-minsan ay kailangang gawin sa maikling paunawa o para sa pagkakapare-pareho sa
ang natitirang bahagi ng Perl.

Kapag naisama na ang isang module sa core ng Perl, gayunpaman, lahat ng kasangkot
ang pagpapanatili ng Perl ay dapat magkaroon ng kamalayan na ang module ay pag-aari pa rin ng orihinal
may-akda maliban kung ang orihinal na may-akda ay tahasang isuko ang kanilang pagmamay-ari nito. Sa
partikular:

· Ang bersyon ng module sa Perl core ay dapat pa ring ituring na gawa ng
orihinal na may-akda. Ang lahat ng mga patch, ulat ng bug, at iba pa ay dapat ibalik sa kanila.
Ang kanilang mga direksyon sa pag-unlad ay dapat igalang hangga't maaari.

· Ang mga patch ay maaaring ilapat ng may hawak ng kalabasa nang walang tahasang pakikipagtulungan ng
may-akda ng module kung at kung sila ay napakaliit, kritikal sa oras sa ilang paraan (tulad ng
bilang agarang pag-aayos sa seguridad), o kung hindi maabot ang may-akda ng module. Yung mga patch
ay dapat pa ring ibalik sa may-akda kung maaari, at kung ang may-akda ay nagpasya sa isang
kahaliling pag-aayos sa kanilang bersyon, ang pag-aayos na iyon ay dapat na mas gusto maliban kung mayroon
isang seryosong problema dito. Ang anumang mga pagbabagong hindi inendorso ng may-akda ay dapat mamarkahan bilang
ganoon, at kinilala ang nag-ambag ng pagbabago.

· Ang bersyon ng module na ipinamahagi sa Perl ay dapat, hangga't maaari, ay ang
pinakabagong bersyon ng module na ipinamahagi ng may-akda (ang pinakabagong bersyon na hindi beta
sa kaso ng mga pampublikong paglabas ng Perl), kahit na ang may hawak ng kalabasa ay maaaring tumigil
pag-upgrade ng bersyon ng module na ipinamahagi sa Perl sa pinakabagong bersyon hanggang
ang pinakabagong bersyon ay nagkaroon ng sapat na pagsubok.

Sa madaling salita, ang may-akda ng isang modyul ay dapat isaalang-alang na may pinal na pasya
mga pagbabago sa kanilang module hangga't maaari (tandaan na inaasahan na
lahat ng kasangkot ay magtutulungan at makakarating sa mga makatwirang kompromiso kapag mayroon
hindi pagkakasundo).

Bilang isang huling paraan, gayunpaman:

Kung ang pananaw ng may-akda sa kinabukasan ng kanilang modyul ay sapat na naiiba sa
pangitain ng may hawak ng kalabasa at mga perl5-porter sa kabuuan upang magdulot ng malubhang problema
para sa Perl, maaaring piliin ng may hawak ng kalabasa na pormal na i-fork ang bersyon ng module sa
Perl core mula sa pinananatili ng may-akda. Ito ay hindi dapat gawin nang basta-basta at
dapat palagi kung maaari ay gawin lamang pagkatapos ng direktang input mula kay Larry. Kung ito ay
tapos na, dapat itong gawing tahasan sa module bilang ibinahagi kasama ang Perl core na
ito ay isang sanga na bersyon at habang ito ay batay sa orihinal na gawa ng may-akda, ito ay hindi
mas matagal nilang pinananatili. Dapat itong tandaan sa parehong dokumentasyon at sa
komento sa pinagmulan ng modyul.

Muli, ito ay dapat na isang huling paraan lamang. Sa isip, hindi ito dapat mangyari, at lahat
posibleng pagsisikap sa pakikipagtulungan at kompromiso ay dapat gawin bago gawin ito. Kung ito
ay nagpapatunay na kinakailangan upang i-fork ang isang module para sa pangkalahatang kalusugan ng Perl, nararapat na kredito
ibigay sa orihinal na may-akda nang walang hanggan at ang desisyon ay dapat na patuloy na muling
sinusuri upang makita kung posible ang muling pagsasama-sama ng dalawang sangay sa daan.

Sa lahat ng pakikitungo sa mga naiambag na module, dapat isaisip ng lahat na nagpapanatili ng Perl
na ang code ay pagmamay-ari ng orihinal na may-akda, na maaaring wala sila sa mga perl5-porter sa anuman
ibinigay na oras, at ang isang patch ay hindi opisyal maliban kung ito ay isinama sa
kopya ng may-akda ng modyul. Upang tumulong dito, at sa mga puntos #1, #2, at #3 sa itaas,
ang impormasyon sa pakikipag-ugnayan para sa mga may-akda ng lahat ng naiambag na mga module ay dapat itago sa
Pamamahagi ng Perl.

Sa wakas, kinikilala ng komunidad ng Perl sa kabuuan ang paggalang sa pagmamay-ari ng code,
paggalang sa masining na kontrol, wastong kredito, at aktibong pagsisikap na maiwasan ang hindi sinasadya
Ang code skew o communication gaps ay mahalaga sa kalusugan ng komunidad at ng Perl mismo.
Ang mga miyembro ng isang komunidad ay hindi dapat karaniwang gumamit ng mga tuntunin at batas na dapat harapin
isa't isa, at ang dokumentong ito, bagama't naglalaman ito ng mga panuntunan upang maging malinaw, ay tungkol sa isang
saloobin at pangkalahatang diskarte. Ang unang hakbang sa anumang hindi pagkakaunawaan ay dapat na bukas
komunikasyon, paggalang sa magkasalungat na pananaw, at pagtatangka sa isang kompromiso. Sa halos
bawat pangyayari ay wala nang kakailanganin, at tiyak na wala nang marahas na hakbang
dapat gamitin hanggang sa mabigo ang bawat paraan ng komunikasyon at talakayan.

Dokumentasyon

Ang dokumentasyon ng Perl ay isang mahalagang mapagkukunan para sa aming mga gumagamit. Ito ay hindi kapani-paniwalang mahalaga para sa
Ang dokumentasyon ni Perl ay makatwirang magkakaugnay at tumpak na sumasalamin sa kasalukuyang
pagpapatupad.

Kung paanong sama-samang pinapanatili ng P5P ang codebase, sama-sama naming pinapanatili ang
dokumentasyon. Ang pagsulat ng isang partikular na piraso ng dokumentasyon ay hindi nagbibigay ng kontrol sa may-akda
ng hinaharap ng dokumentasyong iyon. Kasabay nito, tulad ng dapat baguhin ng source code
tumugma sa istilo ng kanilang mga nakapaligid na bloke, kaya dapat magbago ang dokumentasyon.

Ang mga halimbawa sa dokumentasyon ay dapat na naglalarawan ng konseptong ipinapaliwanag nila.
Minsan, ang pinakamahusay na paraan upang ipakita kung paano gumagana ang isang feature ng wika ay sa isang maliit na program na
ang mambabasa ay maaaring tumakbo nang walang pagbabago. Mas madalas, ang mga halimbawa ay binubuo ng isang snippet ng
code na naglalaman lamang ng "mahalaga" na mga piraso. Ang kahulugan ng "mahalaga" ay nag-iiba mula sa
snippet to snippet. Minsan mahalagang ideklara ang "gamitin nang mahigpit" at "gamitin ang mga babala",
simulan ang lahat ng mga variable at ganap na mahuli ang bawat kundisyon ng error. Mas madalas kaysa sa hindi,
gayunpaman, ang mga bagay na iyon ay nakakubli sa aral na nilayon na ituro ng halimbawa.

Dahil ang Perl ay binuo ng isang pandaigdigang pangkat ng mga boluntaryo, kadalasang naglalaman ang aming dokumentasyon
mga spelling na mukhang nakakatawa isang tao. Ang pagpili ng American/British/Other spellings ay
iniwan bilang isang ehersisyo para sa may-akda ng bawat piraso ng dokumentasyon. Kapag nagtagpi-tagpi
dokumentasyon, subukang tularan ang dokumentasyon sa paligid mo, sa halip na baguhin ang
umiiral na tuluyan.

Sa pangkalahatan, dapat ilarawan ng dokumentasyon kung ano ang ginagawa ni Perl "ngayon" kaysa sa dati
gawin. Ito ay ganap na makatwiran upang isama ang mga tala sa dokumentasyon tungkol sa kung paano mayroon ang pag-uugali
nagbago mula sa mga nakaraang release, ngunit, na may napakakaunting mga pagbubukod, ang dokumentasyon ay hindi "dual-
buhay" -- hindi nito kailangang ganap na ilarawan kung paano gumagana ang lahat ng lumang bersyon dati.

Pamantayan OF PAG-UUGALI

Ang opisyal na forum para sa pagbuo ng perl ay ang perl5-porters mailing list,
nabanggit sa itaas, at ang bugtracker nito sa rt.perl.org. Lahat ng kalahok sa talakayan doon
ay inaasahang sumunod sa isang pamantayan ng pag-uugali.

· Laging maging sibil.

· Pakinggan ang mga moderator.

Ang pagkamagalang ay simple: manatili sa mga katotohanan habang iniiwasan ang mga mapang-uyam na pananalita at panunuya. Ito
ay hindi sapat upang maging makatotohanan. Dapat civil ka din. Ang pagtugon sa kabaitan sa kawalang-kilos ay
hindi katanggap-tanggap.

Bagama't kailangan ang pagkamagalang, hinihikayat ang kabaitan; kung mayroon kang anumang pagdududa tungkol sa kung
you are being civil, simply ask yourself, "Mabait ba ako?" at hangarin iyon.

Kung sasabihin sa iyo ng mga moderator ng listahan na hindi ka sibil, pag-isipang mabuti kung paano mo
ang mga salita ay lumitaw bago tumugon sa anumang paraan. Mabait ba sila? Maaari kang magprotesta, ngunit
hindi katanggap-tanggap ang paulit-ulit na protesta sa harap ng paulit-ulit na pagpapatibay.

Ang hindi katanggap-tanggap na pag-uugali ay magreresulta sa isang pampubliko at malinaw na natukoy na babala. Paulit-ulit
hindi katanggap-tanggap na pag-uugali ay magreresulta sa pag-alis mula sa mailing list at pagbawi ng
mga karapatang i-update ang rt.perl.org. Ang unang pagtanggal ay para sa isang buwan. Mga kasunod na pagtanggal
ay doble ang haba. Pagkatapos ng anim na buwan nang walang babala, ire-reset ang haba ng pagbabawal ng user.
Ang mga pag-alis, tulad ng mga babala, ay pampubliko.

Ang listahan ng mga moderator ay magiging kaalaman ng publiko. Sa kasalukuyan, ito ay: Aaron Crane, Andy
Dougherty, Ricardo Signes, Steffen Mueller.

CREDITS

"Social Contract about Contributed Modules" na orihinal ni Russ Allbery[protektado ng email]>
at ang mga perl5-porter.

Gumamit ng perlpolicy online gamit ang mga serbisyo ng onworks.net