perlpolicy - ອອນລາຍໃນຄລາວ

ໂຄງການ:

NAME

perlpolicy - ນະ​ໂຍ​ບາຍ​ທີ່​ແຕກ​ຕ່າງ​ກັນ​ແລະ​ທີ່​ຫຍໍ້​ທໍ້​ແລະ​ຄໍາ​ຫມັ້ນ​ສັນ​ຍາ​ທີ່​ກ່ຽວ​ຂ້ອງ​ກັບ​ຫຼັກ Perl​

ລາຍລະອຽດ

ເອກະສານນີ້ແມ່ນເອກະສານຕົ້ນສະບັບທີ່ບັນທຶກນະໂຍບາຍລາຍລັກອັກສອນທັງຫມົດກ່ຽວກັບວິທີການ Perl
5 Porters ລວມກັນພັດທະນາແລະຮັກສາຫຼັກ Perl.

ລັດຖະບານ

Perl 5 Porter
ຜູ້ຈອງ perl5-porters (ຕົວເກັບຕົວມັນເອງ) ເຂົ້າມາໃນຫຼາຍລົດຊາດ. ບາງຄົນແມ່ນ
ງຽບ curious lurkers, ຜູ້ທີ່ບໍ່ຄ່ອຍ pitch ໃນແລະແທນທີ່ຈະສັງເກດເບິ່ງການພັດທະນາຢ່າງຕໍ່ເນື່ອງເພື່ອ
ໃຫ້ແນ່ໃຈວ່າເຂົາເຈົ້າໄດ້ຮັບການເຕືອນລ່ວງໜ້າກ່ຽວກັບການປ່ຽນແປງ ຫຼືຄຸນສົມບັດໃໝ່ໃນ Perl. ບາງຄົນເປັນຕົວແທນຂອງ
ຜູ້ຂາຍ, ຜູ້ທີ່ຢູ່ທີ່ນັ້ນເພື່ອໃຫ້ແນ່ໃຈວ່າ Perl ສືບຕໍ່ລວບລວມແລະເຮັດວຽກຂອງພວກເຂົາ
ເວທີ. ບາງຄົນແກ້ໄຂຂໍ້ບົກພ່ອງທີ່ຖືກລາຍງານທີ່ພວກເຂົາຮູ້ວິທີການແກ້ໄຂ, ບາງຄົນກໍ່ມີການເຄື່ອນໄຫວ
patching ພື້ນທີ່ສັດລ້ຽງຂອງພວກເຂົາ (ກະທູ້, Win32, regexp - ເຄື່ອງຈັກ), ໃນຂະນະທີ່ຄົນອື່ນເບິ່ງຄືວ່າຈະເຮັດ.
ບໍ່ມີຫຍັງແຕ່ຈົ່ມ. ໃນຄໍາສັບຕ່າງໆອື່ນໆ, ມັນເປັນການຜະສົມຜະສານຂອງບຸກຄົນດ້ານວິຊາການປົກກະຕິຂອງທ່ານ.

ໃນໄລຍະນີ້ຂອງ porters ກຸ່ມນີ້ເປັນປະທານ Larry Wall. ລາວມີຄໍາສຸດທ້າຍໃນສິ່ງທີ່ເຮັດແລະ
ບໍ່ມີການປ່ຽນແປງໃດໆຂອງພາສາການຂຽນໂປຼແກຼມ Perl. ມື້ນີ້, Larry ໃຊ້ເວລາຫຼາຍທີ່ສຸດ
ຂອງເວລາຂອງລາວໃນ Perl 6, ໃນຂະນະທີ່ Perl 5 ໄດ້ຖືກລ້ຽງແກະໂດຍ "pumpking", ເຈົ້າຫນ້າທີ່ຮັບຜິດຊອບ.
ສໍາລັບການຕັດສິນໃຈສິ່ງທີ່ເຂົ້າໄປໃນແຕ່ລະການປ່ອຍແລະໃຫ້ແນ່ໃຈວ່າການປ່ອຍອອກມາເປັນປົກກະຕິ
ບົນພື້ນຖານ.

Larry ເຫັນການພັດທະນາ Perl ຕາມເສັ້ນທາງຂອງລັດຖະບານສະຫະລັດ: ມີສະພານິຕິບັນຍັດ
(the porters), ສາຂາບໍລິຫານ (the -pumpking), ແລະສານສູງສຸດ (Larry). ໄດ້
ສະພານິຕິບັນຍັດສາມາດປຶກສາຫາລືແລະສົ່ງ patches ກັບສາຂາບໍລິຫານທັງຫມົດທີ່ເຂົາເຈົ້າມັກ, ແຕ່
ສາຂາບໍລິຫານແມ່ນບໍ່ເສຍຄ່າທີ່ຈະ veto ເຂົາເຈົ້າ. ບໍ່ຄ່ອຍ, ສານສູງສຸດຈະເຂົ້າຂ້າງ
ສາຂາບໍລິຫານຂອງສະພາບໍລິຫານ, ຫຼືສະພາບໍລິຫານຂອງສາຂາບໍລິຫານ.
ຢ່າງໃດກໍຕາມ, ສ່ວນໃຫຍ່, ສະພານິຕິບັນຍັດແລະສາຂາບໍລິຫານແມ່ນຄວນຈະເຂົ້າກັນແລະ
ແກ້ໄຂຄວາມແຕກຕ່າງຂອງເຂົາເຈົ້າໂດຍບໍ່ມີການຟ້ອງຮ້ອງຫຼືກໍລະນີສານ.

ບາງຄັ້ງເຈົ້າອາດຈະເຫັນການອ້າງເຖິງກົດລະບຽບ 1 ແລະກົດລະບຽບ 2. ອໍານາດຂອງ Larry ໃນຖານະທີ່ສານສູງສຸດແມ່ນ
ສະ​ແດງ​ອອກ​ໃນ​ລະ​ບຽບ​ການ​:

1. Larry ແມ່ນສະເຫມີໂດຍຄໍານິຍາມທີ່ຖືກຕ້ອງກ່ຽວກັບວິທີ Perl ຄວນປະພຶດ. ນີ້ຫມາຍຄວາມວ່າລາວມີ
ອຳນາດ veto ສຸດທ້າຍ ກ່ຽວກັບໜ້າທີ່ຫຼັກ.

2. Larry ໄດ້ຖືກອະນຸຍາດໃຫ້ປ່ຽນໃຈກ່ຽວກັບເລື່ອງໃດຫນຶ່ງໃນເວລາຕໍ່ມາ, ບໍ່ວ່າຈະເປັນ
ບໍ່ວ່າລາວໄດ້ຮຽກຮ້ອງກົດລະບຽບ 1 ມາກ່ອນ.

ເຂົ້າໃຈບໍ? Larry ແມ່ນຖືກຕ້ອງສະ ເໝີ ໄປ, ເຖິງແມ່ນວ່າລາວເຮັດຜິດ. ມັນຫາຍາກທີ່ຈະເຫັນທັງ Rule
ອອກກໍາລັງກາຍ, ແຕ່ພວກເຂົາມັກຈະຖືກກ່າວເຖິງ.

MAINTENANCE ແລະ ສະຫນັບສະຫນູນ

Perl 5 ຖືກພັດທະນາໂດຍຊຸມຊົນ, ບໍ່ແມ່ນອົງການຂອງບໍລິສັດ. ທຸກໆການປ່ຽນແປງປະກອບສ່ວນ
ຫຼັກ Perl ແມ່ນຜົນມາຈາກການບໍລິຈາກ. ໂດຍປົກກະຕິ, ການບໍລິຈາກເຫຼົ່ານີ້ແມ່ນການປະກອບສ່ວນຂອງ
ລະຫັດ ຫຼືເວລາໂດຍສະມາຊິກແຕ່ລະຄົນຂອງຊຸມຊົນຂອງພວກເຮົາ. ໃນໂອກາດ, ການບໍລິຈາກເຫຼົ່ານີ້ເຂົ້າມາ
ຮູບ​ແບບ​ການ​ສະ​ຫນັບ​ສະ​ຫນູນ​ບໍ​ລິ​ສັດ​ຫຼື​ອົງ​ການ​ຈັດ​ຕັ້ງ​ຂອງ​ບຸກ​ຄົນ​ໃດ​ຫນຶ່ງ​ຫຼື​ໂຄງ​ການ​ສະ​ເພາະ​ໃດ​ຫນຶ່ງ​.

ໃນ​ຖາ​ນະ​ເປັນ​ອົງ​ການ​ອາ​ສາ​ສະ​ຫມັກ, ຄໍາ​ຫມັ້ນ​ສັນ​ຍາ​ທີ່​ພວກ​ເຮົາ​ເຮັດ​ແມ່ນ​ຫຼາຍ​ຂຶ້ນ​ກັບ​ຄວາມ​ຫວັງ​ດີ
ແລະການເຮັດວຽກຫນັກຂອງບຸກຄົນທີ່ບໍ່ມີພັນທະທີ່ຈະປະກອບສ່ວນໃຫ້ Perl.

ວ່າໄດ້ຖືກກ່າວວ່າ, ພວກເຮົາໃຫ້ຄຸນຄ່າຄວາມຫມັ້ນຄົງແລະຄວາມປອດໄພຂອງ Perl ແລະໄດ້ມີເວລາດົນນານທີ່ບໍ່ມີລາຍລັກອັກສອນ
ພັນທະສັນຍາກັບຊຸມຊົນ Perl ທີ່ກວ້າງຂວາງເພື່ອສະຫນັບສະຫນູນແລະຮັກສາການປ່ອຍ Perl.

ເອກະສານນີ້ codifies ສະຫນັບສະຫນູນແລະຄໍາຫມັ້ນສັນຍາການຮັກສາທີ່ຊຸມຊົນ Perl
ຄວນຄາດຫວັງຈາກນັກພັດທະນາຂອງ Perl:

· ພວກເຮົາ "ຢ່າງເປັນທາງການ" ສະຫນັບສະຫນູນສອງຊຸດການປ່ອຍທີ່ຫມັ້ນຄົງຫຼ້າສຸດ. 5.16.x ແລະກ່ອນໜ້ານັ້ນ
ດຽວນີ້ບໍ່ມີການສະຫນັບສະຫນູນ. ໃນຖານະເປັນການປ່ອຍ 5.22.0, ພວກເຮົາຈະ "ຢ່າງເປັນທາງການ" ສິ້ນສຸດການສະຫນັບສະຫນູນ
ສໍາລັບ Perl 5.18.x, ນອກເຫນືອຈາກການສະຫນອງການປັບປຸງຄວາມປອດໄພຕາມທີ່ອະທິບາຍຂ້າງລຸ່ມນີ້.

· ໃນ​ຄວາມ​ສາ​ມາດ​ທີ່​ສຸດ​ຂອງ​ພວກ​ເຮົາ, ພວກ​ເຮົາ​ຈະ​ພະ​ຍາ​ຍາມ​ແກ້​ໄຂ​ບັນ​ຫາ​ທີ່​ສໍາ​ຄັນ​ໃນ​ສອງ​ຫຼາຍ​ທີ່​ສຸດ
ຊຸດການປ່ອຍ 5.x ທີ່ໝັ້ນຄົງຫຼ້າສຸດ. ການແກ້ໄຂສໍາລັບຊຸດການປ່ອຍປະຈຸບັນໃຊ້ເວລາ
ເໜືອກວ່າການແກ້ໄຂສຳລັບຊຸດລຸ້ນກ່ອນໜ້າ.

·ເພື່ອທີ່ດີທີ່ສຸດຂອງຄວາມສາມາດຂອງພວກເຮົາ, ພວກເຮົາຈະສະຫນອງ "ທີ່ສໍາຄັນ" ເພີ້ມຄວາມປອດໄພ / ການປ່ອຍສໍາລັບ
Perl ລຸ້ນໃຫຍ່ໃດໆກໍຕາມທີ່ມີການປ່ອຍ 5.x.0 ພາຍໃນສາມປີທີ່ຜ່ານມາ. ພວກ​ເຮົາ​ສາ​ມາດ
ພຽງແຕ່ໃຫ້ຄໍາຫມັ້ນສັນຍາທີ່ຈະສະຫນອງການເຫຼົ່ານີ້ສໍາລັບການປ່ອຍ .y ຫຼ້າສຸດໃນຊຸດ 5.xy ໃດ.

·ພວກເຮົາຈະບໍ່ສະຫນອງການປັບປຸງຄວາມປອດໄພຫຼືການແກ້ໄຂ bug ສໍາລັບການພັດທະນາການປ່ອຍ Perl.

·ພວກເຮົາຊຸກຍູ້ໃຫ້ຜູ້ຂາຍຈັດສົ່ງການປ່ອຍ Perl ທີ່ໄດ້ຮັບການສະຫນັບສະຫນູນຫຼ້າສຸດໃນເວລາຂອງ
ລະ​ຫັດ​ຂອງ​ເຂົາ​ເຈົ້າ freeze.

· ໃນຖານະເປັນຜູ້ຂາຍ, ທ່ານອາດຈະມີຄວາມຕ້ອງການແກ້ໄຂຄວາມປອດໄພ backport ເກີນກວ່າ 3 ປີຂອງພວກເຮົາ
ສະຫນັບສະຫນູນຄໍາຫມັ້ນສັນຍາ. ພວກ​ເຮົາ​ສາ​ມາດ​ສະ​ຫນອງ​ການ​ສະ​ຫນັບ​ສະ​ຫນູນ​ຈໍາ​ກັດ​ແລະ​ຄໍາ​ແນະ​ນໍາ​ທີ່​ທ່ານ​ເຮັດ​ແນວ​ນັ້ນ​
ແລະ, ບ່ອນທີ່ເປັນໄປໄດ້ຈະພະຍາຍາມນໍາໃຊ້ patches ເຫຼົ່ານັ້ນກັບສາຂາທີ່ກ່ຽວຂ້ອງ -maint ໃນ
git, ເຖິງແມ່ນວ່າພວກເຮົາອາດຈະຫຼືບໍ່ເລືອກທີ່ຈະເຮັດການປ່ອຍຕົວເລກຫຼື "ຢ່າງເປັນທາງການ" patches
ມີໃຫ້. ຕິດຕໍ່ພວກເຮົາທີ່perl5-security-report@perl.org> ເພື່ອເລີ່ມຕົ້ນຂະບວນການນັ້ນ.

ຝາປິດ ຄວາມເຂົ້າກັນໄດ້ ແລະ DEPRECATION

ຊຸມຊົນຂອງພວກເຮົາມີຄວາມເຊື່ອທີ່ມີມາແຕ່ດົນນານວ່າຄວາມເຂົ້າກັນໄດ້ໃນດ້ານຫຼັງແມ່ນເປັນຄຸນງາມຄວາມດີ, ເຖິງແມ່ນວ່າເວລາໃດ
ຫນ້າທີ່ຢູ່ໃນຄໍາຖາມແມ່ນຂໍ້ບົກພ່ອງຂອງການອອກແບບ.

ພວກເຮົາທຸກຄົນມັກທີ່ຈະຍົກເລີກຄວາມຜິດພາດບາງຢ່າງທີ່ພວກເຮົາໄດ້ເຮັດໃນໄລຍະທົດສະວັດທີ່ຜ່ານມາ. ອາໄສຢູ່ກັບ
ທຸກໆຄວາມຜິດພາດການອອກແບບທີ່ພວກເຮົາເຄີຍເຮັດສາມາດນໍາໄປສູ່ການຢຸດສະງັກທີ່ເຈັບປວດ. ແກ້​ໄຂ​ຄວາມ​ຜິດ​ພາດ​ຂອງ​ພວກ​ເຮົາ
ແມ່ນຫຼາຍ, ຍາກຫຼາຍ. ການເຮັດແນວນັ້ນໂດຍບໍ່ມີການທໍາຮ້າຍຜູ້ໃຊ້ຂອງພວກເຮົາແມ່ນເກືອບ
ເປັນໄປບໍ່ໄດ້.

ບໍ່ດົນມານີ້, ການບໍ່ສົນໃຈຫຼືກົງກັນຂ້າມຢ່າງຈິງຈັງກັບຄວາມເຂົ້າກັນໄດ້ກັບ Perl ຮຸ່ນກ່ອນຫນ້າໄດ້ມາ
ເຂົ້າໄປໃນ vogue. ບາງຄັ້ງ, ການປ່ຽນແປງໄດ້ຖືກສະເຫນີທີ່ຕ້ອງການທີ່ຈະ usurp syntax ທີ່ກ່ອນຫນ້ານີ້
ມີຄວາມຫມາຍອື່ນ. ບາງຄັ້ງ, ການປ່ຽນແປງຕ້ອງການປັບປຸງຄໍາສັບທີ່ບ້າໃນເມື່ອກ່ອນ.

ລົງຖະຫນົນຫົນທາງນີ້ແມ່ນ madness.

ຮຽກຮ້ອງໃຫ້ຜູ້ຂຽນໂປລແກລມຜູ້ໃຊ້ສຸດທ້າຍປ່ຽນໂຄງສ້າງພາສາຈໍານວນຫນ້ອຍ, ເຖິງແມ່ນວ່າພາສາ
ການກໍ່ສ້າງທີ່ບໍ່ມີຜູ້ພັດທະນາທີ່ມີການສຶກສາທີ່ດີຈະໃຊ້ໂດຍເຈດຕະນາແມ່ນເທົ່າກັບ
ໂດຍກ່າວວ່າ "ທ່ານບໍ່ຄວນອັບເກດ Perl ລຸ້ນ ໃໝ່ ເວັ້ນເສຍແຕ່ວ່າທ່ານມີການຄຸ້ມຄອງການທົດສອບ 100%.
ແລະສາມາດເຮັດການກວດສອບຄູ່ມືຢ່າງເຕັມທີ່ຂອງ codebase ຂອງເຈົ້າ." ຖ້າພວກເຮົາມີເຄື່ອງມືທີ່ມີຄວາມສາມາດ
ການຍົກລະດັບລະຫັດແຫຼ່ງ Perl ທີ່ເຊື່ອຖືໄດ້ຈາກສະບັບຫນຶ່ງຂອງ Perl ໄປອີກ, ຄວາມກັງວົນນີ້
ສາມາດໄດ້ຮັບການຫຼຸດຜ່ອນຢ່າງຫຼວງຫຼາຍ.

ພວກ​ເຮົາ​ຕ້ອງ​ການ​ເພື່ອ​ໃຫ້​ແນ່​ໃຈວ່​າ Perl ສືບ​ຕໍ່​ຂະ​ຫຍາຍ​ຕົວ​ແລະ​ຈະເລີນ​ຮຸ່ງ​ເຮືອງ​ໃນ​ຊຸມ​ປີ​ຕໍ່​ໄປ​ແລະ​
ທົດສະວັດ, ແຕ່ບໍ່ແມ່ນຄ່າໃຊ້ຈ່າຍຂອງຊຸມຊົນຜູ້ໃຊ້ຂອງພວກເຮົາ.

syntax ແລະ semantics ທີ່ມີຢູ່ແລ້ວຄວນຈະຖືກຫມາຍພຽງແຕ່ສໍາລັບການທໍາລາຍໃນຈໍາກັດຫຼາຍ
ສະຖານະການ. ຖ້າພວກເຂົາເຊື່ອວ່າຖືກນໍາໃຊ້ຫນ້ອຍຫຼາຍ, ຢືນຢູ່ໃນວິທີການຕົວຈິງ
ການປັບປຸງພາສາ Perl ຫຼືນາຍພາສາ perl, ແລະຖ້າລະຫັດທີ່ຖືກກະທົບສາມາດໄດ້ຢ່າງງ່າຍດາຍ
ປັບປຸງເພື່ອສືບຕໍ່ເຮັດວຽກ, ພວກເຂົາອາດຈະຖືກພິຈາລະນາສໍາລັບການໂຍກຍ້າຍ. ເມື່ອສົງໃສ, ຈົ່ງລະວັງ
dictates ວ່າພວກເຮົາຈະສະຫນັບສະຫນູນຄວາມເຂົ້າກັນໄດ້ກັບຄືນໄປບ່ອນ. ເມື່ອຄຸນສົມບັດໃດນຶ່ງຖືກຄັດຄ້ານ, ກ
ຖະແຫຼງການຂອງເຫດຜົນອະທິບາຍຂະບວນການຕັດສິນໃຈຈະຖືກປະກາດ, ແລະການເຊື່ອມຕໍ່ກັບມັນ
ຈະຖືກສະຫນອງໃຫ້ຢູ່ໃນເອກະສານ perldelta ທີ່ກ່ຽວຂ້ອງ.

ການໃຊ້ pragma lexical ເພື່ອເປີດໃຊ້ຫຼືປິດການປະພຶດແບບເກົ່າຄວນໄດ້ຮັບການພິຈາລະນາວ່າເວລາໃດ
ທີ່ເຫມາະສົມ, ແລະໃນກໍລະນີທີ່ບໍ່ມີພຶດຕິກໍາທີ່ເປັນມໍລະດົກຂອງ pragma ຄວນຖືກເປີດໃຊ້. ທີ່
ການ​ປ່ຽນ​ແປງ​ທີ່​ບໍ່​ເຂົ້າ​ກັນ​ໄດ້​ກັບ​ຄືນ​ຫຼັງ​ແມ່ນ​ໄດ້​ຖືກ​ຄວບ​ຄຸມ​ໂດຍ implicitly ໂດຍ 'ໃຊ້ v5.xy' ເປັນ​ການ​ຕັດ​ສິນ​ໃຈ
ທີ່ຄວນຈະເຮັດໄດ້ໂດຍການສູບນ້ໍາໃນການປຶກສາຫາລືກັບຊຸມຊົນ.

ໃນປະຫວັດສາດ, ພວກເຮົາໄດ້ຖືຕົວເຮົາເອງເປັນມາດຕະຖານທີ່ສູງກວ່າຄວາມເຂົ້າກັນໄດ້ກັບຫຼັງ -
bugward-ເຂົ້າກັນໄດ້. ອຸບັດເຫດໃດໆຂອງການປະຕິບັດຫຼືຜົນກະທົບຂ້າງຄຽງທີ່ບໍ່ຕັ້ງໃຈຂອງ
ແລ່ນບາງລະຫັດໄດ້ຖືກພິຈາລະນາວ່າເປັນລັກສະນະຂອງພາສາທີ່ຈະເປັນ
ປ້ອງກັນດ້ວຍຄວາມກະຕືລືລົ້ນຄືກັນກັບຄຸນສົມບັດຫຼືການທໍາງານອື່ນໆ. ບໍ່ວ່າແນວໃດ
ຄວາມອຸກອັ່ງຂອງລັກສະນະທີ່ບໍ່ຕັ້ງໃຈເຫຼົ່ານີ້ອາດຈະເປັນໃຫ້ພວກເຮົາຍ້ອນວ່າພວກເຮົາສືບຕໍ່ປັບປຸງ Perl,
ລັກສະນະທີ່ບໍ່ຕັ້ງໃຈເຫຼົ່ານີ້ມັກຈະສົມຄວນໄດ້ຮັບການປົກປ້ອງຂອງພວກເຮົາ. ມັນເປັນສິ່ງສໍາຄັນຫຼາຍທີ່
ຊອບແວທີ່ມີຢູ່ແລ້ວທີ່ຂຽນໄວ້ໃນ Perl ສືບຕໍ່ເຮັດວຽກຢ່າງຖືກຕ້ອງ. ຖ້າຜູ້ພັດທະນາຜູ້ໃຊ້ສຸດທ້າຍມີ
ໄດ້ຮັບຮອງເອົາ bug ເປັນລັກສະນະ, ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ປິ່ນປົວມັນເປັນດັ່ງກ່າວ.

syntax ແລະ semantics ໃຫມ່ທີ່ບໍ່ທໍາລາຍໂຄງສ້າງພາສາທີ່ມີຢູ່ແລ້ວແລະ syntax ມີ a
ແຖບຕ່ໍາຫຼາຍ. ພວກເຂົາເຈົ້າພຽງແຕ່ຕ້ອງການທີ່ຈະພິສູດຕົນເອງເປັນປະໂຫຍດ, elegant, ດີ
ການ​ອອກ​ແບບ​, ແລະ​ການ​ທົດ​ສອບ​ທີ່​ດີ​. ໃນກໍລະນີຫຼາຍທີ່ສຸດ, ການເພີ່ມເຕີມເຫຼົ່ານີ້ຈະຖືກຫມາຍເປັນ ທົດລອງ
ສໍາລັບບາງເວລາ. ເບິ່ງຂ້າງລຸ່ມນີ້ສໍາລັບການເພີ່ມເຕີມກ່ຽວກັບວ່າ.

Terminology
ເພື່ອໃຫ້ແນ່ໃຈວ່າພວກເຮົາກໍາລັງເວົ້າກ່ຽວກັບສິ່ງດຽວກັນໃນເວລາທີ່ພວກເຮົາສົນທະນາການໂຍກຍ້າຍຂອງລັກສະນະຫຼື
ການເຮັດວຽກຈາກຫຼັກ Perl, ພວກເຮົາມີຄໍານິຍາມສະເພາະສໍາລັບສອງສາມຄໍາແລະ
ປະໂຫຍກ.

ທົດລອງ
ຖ້າບາງສິ່ງບາງຢ່າງຢູ່ໃນຫຼັກ Perl ຖືກຫມາຍເປັນ ທົດລອງ, ພວກເຮົາອາດຈະມີການປ່ຽນແປງພຶດຕິກໍາຂອງມັນ,
ຄັດຄ້ານ ຫຼືລຶບມັນອອກໂດຍບໍ່ໄດ້ແຈ້ງໃຫ້ຮູ້ລ່ວງໜ້າ. ໃນຂະນະທີ່ພວກເຮົາສະເຫມີຈະເຮັດດີທີ່ສຸດຂອງພວກເຮົາເພື່ອເຮັດໃຫ້ກ້ຽງ
ເສັ້ນທາງການຫັນປ່ຽນສໍາລັບຜູ້ໃຊ້ລັກສະນະທົດລອງ, ທ່ານຄວນຕິດຕໍ່ກັບ
perl5-porters mailinglist ຖ້າເຈົ້າພົບເຫັນລັກສະນະທົດລອງທີ່ເປັນປະໂຫຍດແລະຕ້ອງການຊ່ວຍ
ສ້າງ​ອະ​ນາ​ຄົດ​ຂອງ​ຕົນ​.

ລັກສະນະການທົດລອງຈະຕ້ອງເປັນການທົດລອງໃນສອງການປ່ອຍທີ່ຫມັ້ນຄົງກ່ອນທີ່ຈະຖືກຫມາຍ
ບໍ່​ແມ່ນ​ການ​ທົດ​ລອງ​. ລັກສະນະການທົດລອງຈະມີພຽງແຕ່ສະຖານະການທົດລອງຂອງເຂົາເຈົ້າ
ຖອນຄືນເມື່ອພວກເຂົາບໍ່ມີຂໍ້ບົກພ່ອງທີ່ປ່ຽນແປງການອອກແບບເປີດຕໍ່ພວກເຂົາ ແລະເມື່ອໃດ
ພວກເຂົາເຈົ້າຍັງຄົງບໍ່ປ່ຽນແປງໃນພຶດຕິກໍາສໍາລັບຄວາມຍາວທັງຫມົດຂອງວົງຈອນການພັດທະນາ.
ໃນຄໍາສັບຕ່າງໆອື່ນໆ, ຄຸນນະສົມບັດທີ່ມີຢູ່ໃນ v5.20.0 ອາດຈະຖືກຫມາຍວ່າບໍ່ມີການທົດລອງໃນ
v5.22.0 ຖ້າ​ຫາກ​ວ່າ​ແລະ​ພຽງ​ແຕ່​ຖ້າ​ຫາກ​ວ່າ​ພຶດ​ຕິ​ກໍາ​ຂອງ​ມັນ​ບໍ່​ມີ​ການ​ປ່ຽນ​ແປງ​ທັງ​ຫມົດ​ຂອງ v5.21​.

ບໍ່ເຫັນແກ່ຕົວ
ຖ້າບາງສິ່ງບາງຢ່າງຢູ່ໃນຫຼັກ Perl ຖືກຫມາຍເປັນ ບໍ່ເຫັນແກ່ຕົວ, ພວກເຮົາອາດຈະເອົາມັນອອກຈາກຫຼັກ
ໃນອະນາຄົດ, ເຖິງແມ່ນວ່າພວກເຮົາອາດຈະບໍ່. ໂດຍທົ່ວໄປແລ້ວ, ການປ່ຽນແປງທີ່ບໍ່ເຂົ້າກັນໄດ້ກັບຫຼັງຈະ
ມີຄໍາເຕືອນ deprecation ສໍາລັບສອງວົງຈອນການປ່ອຍກ່ອນທີ່ຈະຖືກໂຍກຍ້າຍ, ແຕ່ອາດຈະເປັນ
ເອົາອອກຫຼັງຈາກພຽງແຕ່ຫນຶ່ງຮອບຖ້າຫາກວ່າຄວາມສ່ຽງເບິ່ງຄືວ່າຂ້ອນຂ້າງຕໍ່າຫຼືຜົນປະໂຫຍດທີ່ຂ້ອນຂ້າງສູງ.

ໃນຖານະເປັນຂອງ Perl 5.12, ຄຸນສົມບັດແລະໂມດູນທີ່ປະຕິເສດການປະກາດເຕືອນຜູ້ໃຊ້ຍ້ອນວ່າພວກເຂົາຖືກນໍາໃຊ້. ເມື່ອ​ໃດ​
ໂມດູນຖືກປະຕິເສດ, ມັນຈະມີຢູ່ໃນ CPAN ນຳ. ການຕິດຕັ້ງມັນຈາກ
CPAN ຈະປິດສຽງຄຳເຕືອນການຍົກເລີກການສະໜັບສະໜຸນສຳລັບໂມດູນນັ້ນ.

ຖ້າທ່ານໃຊ້ຄຸນສົມບັດຫຼືໂມດູນທີ່ຖືກປະຕິເສດແລະເຊື່ອວ່າການໂຍກຍ້າຍຂອງມັນອອກຈາກ Perl
core ຈະເປັນຄວາມຜິດພາດ, ກະລຸນາຕິດຕໍ່ mailinglist perl5-porters ແລະອ້ອນວອນຂອງທ່ານ
ກໍລະນີ. ພວກເຮົາບໍ່ໄດ້ປະຕິເສດສິ່ງຕ່າງໆໂດຍບໍ່ມີເຫດຜົນທີ່ດີ, ແຕ່ບາງຄັ້ງກໍ່ມີ
ການໂຕ້ຖຽງທີ່ພວກເຮົາບໍ່ໄດ້ພິຈາລະນາ. ໃນປະຫວັດສາດ, ພວກເຮົາບໍ່ໄດ້ຈໍາແນກລະຫວ່າງ
ລັກສະນະ "ປະຕິເສດ" ແລະ "ທໍ້ຖອຍໃຈ".

ທໍ້ຖອຍໃຈ
ໃນບາງເວລາ, ພວກເຮົາອາດຈະໝາຍເຖິງການສ້າງພາສາ ແລະລັກສະນະຕ່າງໆທີ່ພວກເຮົາພິຈາລະນາ
ໄດ້​ມີ​ຄວາມ​ຜິດ​ພາດ​ເປັນ ທໍ້ຖອຍໃຈ. ຄຸນ​ນະ​ສົມ​ບັດ​ທໍ້​ຖອຍ​ໃຈ​ບໍ່​ແມ່ນ​ຕົວ​ເລືອກ​ໃນ​ປັດ​ຈຸ​ບັນ​
ສໍາລັບການໂຍກຍ້າຍ, ແຕ່ພວກເຮົາອາດຈະປະຕິເສດໃຫ້ເຂົາເຈົ້າຕໍ່ມາຖ້າຫາກວ່າພວກເຂົາເຈົ້າໄດ້ຖືກພົບເຫັນວ່າຢືນຢູ່ໃນວິທີການຂອງ a
ການປັບປຸງທີ່ສໍາຄັນຕໍ່ຫຼັກ Perl.

ລົບອອກ
ເມື່ອຄຸນສົມບັດ, ການກໍ່ສ້າງ ຫຼືໂມດູນຖືກໝາຍວ່າຖືກຍົກເລີກ, ພວກເຮົາອາດຈະເອົາມັນອອກ
ຈາກຫຼັກ Perl. ບໍ່ແປກໃຈ, ພວກເຮົາເວົ້າວ່າພວກເຮົາໄດ້ ລົບອອກ ສິ່ງ​ເຫລົ່າ​ນີ້. ເມື່ອໂມດູນ
ຖືກໂຍກຍ້າຍ, ມັນຈະບໍ່ສົ່ງກັບ Perl, ແຕ່ຈະສືບຕໍ່ມີຢູ່ໃນ
CPAN.

MAINTENANCE ຊາຍແດນ

ການປ່ອຍໃຫມ່ຂອງສາຂາບໍາລຸງຮັກສາຄວນຈະມີພຽງແຕ່ການປ່ຽນແປງທີ່ຕົກຢູ່ໃນຫນຶ່ງໃນນັ້ນ
ໝວດ "ທີ່ຍອມຮັບໄດ້" ທີ່ກຳນົດໄວ້ຂ້າງລຸ່ມ, ແຕ່ຕ້ອງບໍ່ມີການປ່ຽນແປງທີ່ຕົກຢູ່ໃນອັນດຽວ
ຂອງປະເພດ "ບໍ່ສາມາດຍອມຮັບໄດ້". (ຕົວຢ່າງ, ການແກ້ໄຂສໍາລັບ bug crashing ຈະຕ້ອງບໍ່ແມ່ນ
ລວມ​ເຖິງ​ຖ້າ​ຫາກ​ວ່າ​ມັນ​ທໍາ​ລາຍ​ຄວາມ​ເຂົ້າ​ກັນ​ໄດ້​ສອງ​.)

ມັນບໍ່ຈໍາເປັນທີ່ຈະລວມເອົາທຸກໆການປ່ຽນແປງທີ່ສອດຄ່ອງກັບເງື່ອນໄຂເຫຼົ່ານີ້, ແລະໂດຍທົ່ວໄປແລ້ວ
ຄວນ​ສຸມ​ໃສ່​ແກ້​ໄຂ​ບັນ​ຫາ​ຄວາມ​ປອດ​ໄພ, ບັກ​ທີ່​ເກີດ​ອຸ​ບັດ​ຕິ​ເຫດ, ຖົດ​ຖອຍ​ແລະ​ຮ້າຍ​ແຮງ
ບັນຫາການຕິດຕັ້ງ. ການລໍ້ລວງທີ່ຈະປະກອບມີ plethora ຂອງການປ່ຽນແປງເລັກນ້ອຍທີ່ບໍ່ໄດ້
ສົ່ງ​ຜົນ​ກະ​ທົບ​ການ​ຕິດ​ຕັ້ງ​ຫຼື​ການ​ປະ​ຕິ​ບັດ​ຂອງ perl (ເຊັ່ນ​: ການ​ແກ້​ໄຂ​ການ​ສະ​ກົດ​ຄໍາ​ໃນ​ເອ​ກະ​ສານ​)
ຄວນໄດ້ຮັບການຕ້ານທານເພື່ອຫຼຸດຜ່ອນຄວາມສ່ຽງໂດຍລວມຂອງການມອງຂ້າມບາງສິ່ງບາງຢ່າງ. ໄດ້
ຄວາມຕັ້ງໃຈແມ່ນເພື່ອສ້າງການປ່ອຍການບໍາລຸງຮັກສາທີ່ມີທັງມູນຄ່າແລະຜູ້ໃຊ້ສາມາດເຮັດໄດ້
ມີຄວາມຫມັ້ນໃຈຢ່າງເຕັມທີ່ໃນຄວາມຫມັ້ນຄົງຂອງ. (ຄວາມ​ກັງ​ວົນ​ອັນ​ດັບ​ສອງ​ແມ່ນ​ເພື່ອ​ຫຼີກ​ເວັ້ນ​ການ​ເຜົາ​ໄຫມ້​ອອກ​
maint-pumpking ຫຼື overwhelming committers ອື່ນໆລົງຄະແນນສຽງກ່ຽວກັບການປ່ຽນແປງທີ່ຈະລວມ (ເບິ່ງ
"ໄດ້ຮັບການປ່ຽນແປງເປັນສາຂາຕົ້ນຕໍ" ຂ້າງລຸ່ມນີ້).)

ປະເພດຂອງການປ່ຽນແປງຕໍ່ໄປນີ້ອາດຈະຖືກພິຈາລະນາເປັນທີ່ຍອມຮັບ, ຕາບໃດທີ່ພວກມັນບໍ່ຄືກັນ
ຕົກຢູ່ໃນປະເພດຂອງ "ບໍ່ສາມາດຍອມຮັບໄດ້" ທີ່ກໍານົດໄວ້ຂ້າງລຸ່ມນີ້:

· Patches ທີ່ແກ້ໄຂ CVEs ຫຼືບັນຫາຄວາມປອດໄພ. ການປ່ຽນແປງເຫຼົ່ານີ້ຄວນຈະດໍາເນີນການໂດຍຜ່ານ
perl5-security-report@perl.org ບັນຊີລາຍຊື່ທາງໄປສະນີແທນທີ່ຈະນໍາໃຊ້ໂດຍກົງ.

· Patches ທີ່ແກ້ໄຂຂໍ້ບົກພ່ອງ crashing, ຄວາມລົ້ມເຫຼວຂອງການຢືນຢັນແລະການສໍ້ລາດບັງຫຼວງຂອງຫນ່ວຍຄວາມຈໍາແຕ່ສິ່ງທີ່ເຮັດໄດ້
ຖ້າບໍ່ດັ່ງນັ້ນການປ່ຽນແປງການເຮັດວຽກຂອງ perl ຫຼືຜົນກະທົບທາງລົບຕໍ່ການປະຕິບັດ.

· Patches ທີ່ແກ້ໄຂ regressions ໃນພຶດຕິກໍາຂອງ perl ທີ່ກ່ຽວຂ້ອງກັບການປ່ອຍທີ່ຜ່ານມາ, ບໍ່ມີ
ເລື່ອງການຖົດຖອຍອາຍຸເທົ່າໃດ, ເພາະວ່າບາງຄົນອາດຈະຍົກລະດັບຈາກຮຸ່ນເກົ່າຫຼາຍ
perl ກັບສະບັບຫລ້າສຸດ.

· Patches ທີ່ແກ້ໄຂຂໍ້ບົກຜ່ອງໃນລັກສະນະທີ່ໃຫມ່ໃນ 5.x.0 ທີ່ສອດຄ້ອງກັນ
ການປ່ອຍ.

· Patches ທີ່ແກ້ໄຂສິ່ງໃດແດ່ທີ່ປ້ອງກັນຫຼືມີຜົນກະທົບຢ່າງຮ້າຍແຮງຕໍ່ການກໍ່ສ້າງຫຼື
ການຕິດຕັ້ງ perl.

· ການ​ແກ້​ໄຂ​ການ​ເຄື່ອນ​ໄຫວ​ເຊັ່ນ​ການ​ປ່ຽນ​ແປງ​ການ​ຕັ້ງ​ຄ່າ​ແລະ​ໄຟລ​໌​ໃນ​ຄໍາ​ແນະ​ນໍາ / ໂຟນ​ເດີ​.

· ເພີ້ມຫນ້ອຍທີ່ແກ້ໄຂຄວາມລົ້ມເຫຼວຂອງການທົດສອບສະເພາະເວທີ.

· ການ​ປັບ​ປຸງ​ເອ​ກະ​ສານ​ທີ່​ແກ້​ໄຂ​ຄວາມ​ຜິດ​ພາດ​ຂໍ້​ເທັດ​ຈິງ​, ອະ​ທິ​ບາຍ​ຂໍ້​ບົກ​ພ່ອງ​ທີ່​ສໍາ​ຄັນ​ຫຼື​
ຂໍ້ບົກຜ່ອງໃນການປະຕິບັດໃນປະຈຸບັນ, ຫຼືແກ້ໄຂເຄື່ອງຫມາຍທີ່ແຕກຫັກ.

· ການອັບເດດໂມດູນຄູ່ຊີວິດຄວນປະກອບດ້ວຍການເພີ້ມໜ້ອຍທີ່ສຸດເພື່ອແກ້ໄຂຂໍ້ບົກພ່ອງທີ່ເກີດອຸປະຕິເຫດ ຫຼື
ບັນຫາຄວາມປອດໄພ (ດັ່ງຂ້າງເທິງ). ການປ່ຽນແປງໃດໆທີ່ເກີດຂຶ້ນກັບໂມດູນຊີວິດຄູ່ທີ່ CPAN ແມ່ນ
canonical ຄວນໄດ້ຮັບການປະສານງານກັບຜູ້ຂຽນຕົ້ນສະບັບ.

ປະເພດຂອງການປ່ຽນແປງຕໍ່ໄປນີ້ແມ່ນບໍ່ສາມາດຍອມຮັບໄດ້:

· Patches ທີ່ທໍາລາຍຄວາມເຂົ້າກັນໄດ້ຂອງຄູ່. (ກະລຸນາລົມກັບການສູບ.)

· Patches ທີ່ເພີ່ມຫຼືເອົາຄຸນສົມບັດອອກ.

· Patches ທີ່ເພີ່ມຄໍາເຕືອນໃຫມ່ຫຼືຄວາມຜິດພາດຫຼືປະຕິເສດຄຸນສົມບັດ.

· Ports ຂອງ Perl ກັບແພລະຕະຟອມໃຫມ່, ສະຖາປັດຕະຍະກໍາຫຼືການປ່ອຍ OS ທີ່ກ່ຽວຂ້ອງກັບການປ່ຽນແປງ
ການ​ປະ​ຕິ​ບັດ​.

· ລຸ້ນໃໝ່ຂອງໂມດູນຄູ່ຊີວິດບໍ່ຄວນຖືກນຳເຂົ້າມາໃນລະບົບຫຼັກ. ເຫຼົ່ານັ້ນຢູ່ໃນ
ຊຸດທີ່ຫມັ້ນຄົງຕໍ່ໄປ.

ຖ້າມີຄຳຖາມກ່ຽວກັບວ່າ patch ທີ່ໃຫ້ມານັ້ນອາດຈະເໝາະສົມກັບການລວມຢູ່ໃນຫຼັກຫຼືບໍ່
ປ່ອຍ, ຫຼັງຈາກນັ້ນມັນເກືອບແນ່ນອນວ່າບໍ່ຄວນຈະຖືກລວມເຂົ້າ.

ໄດ້ຮັບ ການປ່ຽນແປງ ເຂົ້າໄປໃນ a ດຽວນີ້ ສາຂາ
ໃນປະຫວັດສາດ, ມີພຽງແຕ່ການປ່ຽນແປງທີ່ເລືອກ cherry ຈາກ bleadperl ເຂົ້າໄປໃນ maintperl. ນີ້
ມີບັນຫາການຂະຫຍາຍ. ໃນເວລາດຽວກັນ, ສາຂາບໍາລຸງຮັກສາຂອງສະບັບທີ່ຫມັ້ນຄົງຂອງ Perl
ຈໍາ​ເປັນ​ຕ້ອງ​ໄດ້​ຮັບ​ການ​ປິ່ນ​ປົວ​ທີ່​ຍິ່ງ​ໃຫຍ່​. ເພື່ອຈຸດນັ້ນ, ເປັນຂອງ Perl 5.12, ພວກເຮົາມີຂະບວນການໃຫມ່
ສໍາລັບສາຂາຕົ້ນຕໍ.

committer ໃດໆສາມາດ cherry ເລືອກຄໍາຫມັ້ນສັນຍາຈາກ blead ກັບສາຂາ maint ຖ້າພວກເຂົາສົ່ງ mail ໄປ.
perl5-porters ປະກາດຄວາມຕັ້ງໃຈຂອງເຂົາເຈົ້າທີ່ຈະ cherry-ເລືອກເອົາຄໍາຫມັ້ນສັນຍາສະເພາະພ້ອມກັບ
ເຫດຜົນສໍາລັບການເຮັດແນວນັ້ນແລະຢ່າງຫນ້ອຍສອງ committers ອື່ນໆຕອບສະຫນອງຕໍ່ບັນຊີລາຍຊື່ທີ່ໃຫ້ຂອງເຂົາເຈົ້າ
ຮັບຮອງ. (ນະໂຍບາຍນີ້ໃຊ້ໄດ້ກັບປັ໊ມປັ໊ມປະຈຸບັນ ແລະອະດີດ, ເຊັ່ນດຽວກັນກັບອື່ນໆ
ກໍາມະການ.)

ກົນໄກການລົງຄະແນນສຽງອື່ນໆອາດຈະຖືກນໍາໃຊ້ແທນ, ຕາບໃດທີ່ຈໍານວນຄະແນນສຽງເທົ່າກັນ
ເຕົ້າໂຮມກັນຢ່າງໂປ່ງໃສ. ໂດຍສະເພາະ, ການສະເຫນີຂອງການປ່ຽນແປງທີ່ຈະເລືອກເອົາ cherry
ທຸກຄົນຕ້ອງເຫັນໄດ້ໃນ perl5-porters ເພື່ອໃຫ້ທັດສະນະຂອງທຸກໆຄົນທີ່ສົນໃຈອາດຈະ
ໄດ້ຍິນ.

ມັນບໍ່ຈໍາເປັນສໍາລັບການລົງຄະແນນທີ່ຈະຈັດຂຶ້ນໃນລາຍການ perldelta ເລືອກ cherry ທີ່ກ່ຽວຂ້ອງ
ກັບການປ່ຽນແປງທີ່ໄດ້ຖືກເລືອກແລ້ວ cherry, ຫຼືສໍາລັບການຕົ້ນຕໍຂອງການສູບໄດ້
ລົງຄະແນນສຽງກ່ຽວກັບການປ່ຽນແປງທີ່ຕ້ອງການໂດຍ Porting/release_managers_guide.pod ບ່ອນທີ່ການປ່ຽນແປງດັ່ງກ່າວສາມາດເຮັດໄດ້
ຖືກນໍາໃຊ້ໂດຍວິທີການເກັບ cherry ຈາກ bleed.

ປະກອບສ່ວນ MODULES

A ສັງຄົມ ສັນຍາ ກ່ຽວກັບ ສິລະປະ ການຄວບຄຸມ
ສິ່ງທີ່ຕໍ່ໄປນີ້ແມ່ນຄໍາຖະແຫຼງກ່ຽວກັບການຄວບຄຸມສິລະປະ, ກໍານົດເປັນຄວາມສາມາດຂອງຜູ້ຂຽນ
packages ເພື່ອນໍາພາອະນາຄົດຂອງລະຫັດຂອງພວກເຂົາແລະຮັກສາການຄວບຄຸມການເຮັດວຽກຂອງພວກເຂົາ. ມັນ​ເປັນ​
ການຮັບຮູ້ວ່າຜູ້ຂຽນຄວນຈະມີການຄວບຄຸມການເຮັດວຽກຂອງເຂົາເຈົ້າ, ແລະວ່າມັນເປັນ
ຄວາມຮັບຜິດຊອບຂອງສ່ວນທີ່ເຫຼືອຂອງຊຸມຊົນ Perl ເພື່ອຮັບປະກັນວ່າພວກເຂົາຮັກສາການຄວບຄຸມນີ້.
ມັນເປັນຄວາມພະຍາຍາມທີ່ຈະບັນທຶກມາດຕະຖານທີ່ພວກເຮົາ, ເປັນນັກພັດທະນາ Perl, ຕັ້ງໃຈຈະຖື
ຕົວເຮົາເອງ. ມັນເປັນຄວາມພະຍາຍາມທີ່ຈະຂຽນບົດແນະນໍາທີ່ຫຍາບຄາຍກ່ຽວກັບການເຄົາລົບທີ່ພວກເຮົາແຕ່ລະຄົນເປັນຫນີ້
ອື່ນໆເປັນນັກພັດທະນາ Perl.

ຖະແຫຼງການນີ້ບໍ່ແມ່ນສັນຍາທາງກົດໝາຍ. ຖະແຫຼງການນີ້ບໍ່ແມ່ນເອກະສານທາງກົດໝາຍໃດໆ
ວິທີການ, ຮູບຮ່າງ, ຫຼືຮູບແບບ. Perl ຖືກແຈກຢາຍພາຍໃຕ້ໃບອະນຸຍາດສາທາລະນະ GNU ແລະພາຍໃຕ້
ໃບອະນຸຍາດສິລະປະ; ເຫຼົ່ານີ້ແມ່ນຂໍ້ກໍານົດທາງດ້ານກົດຫມາຍທີ່ຊັດເຈນ. ຄໍາຖະແຫຼງນີ້ບໍ່ແມ່ນກ່ຽວກັບກົດຫມາຍ
ຫຼືໃບອະນຸຍາດ. ມັນກ່ຽວກັບຊຸມຊົນ, ຄວາມເຄົາລົບເຊິ່ງກັນແລະກັນ, ຄວາມໄວ້ວາງໃຈ, ແລະການຮ່ວມມືທີ່ມີຄວາມເຊື່ອຫມັ້ນ.

ພວກ​ເຮົາ​ຮັບ​ຮູ້​ວ່າ​ຫຼັກ Perl, ກໍາ​ນົດ​ເປັນ​ຊອບ​ແວ​ແຈກ​ຢາຍ​ກັບ​ຫົວ​ໃຈ​ຂອງ
Perl ຕົວຂອງມັນເອງ, ເປັນໂຄງການຮ່ວມກັນຢູ່ໃນສ່ວນຫນຶ່ງຂອງພວກເຮົາທັງຫມົດ. ຈາກບາງຄັ້ງ, script,
ໂມດູນ, ຫຼືຊຸດຂອງໂມດູນ (ຕໍ່ໄປນີ້ເອີ້ນວ່າພຽງແຕ່ "ໂມດູນ") ຈະພິສູດດັ່ງນັ້ນ
ເປັນປະໂຫຍດຢ່າງກວ້າງຂວາງແລະ / ຫຼືຫຼາຍອັນສໍາລັບການເຮັດວຽກທີ່ຖືກຕ້ອງຂອງ Perl ຕົວຂອງມັນເອງທີ່ມັນຄວນຈະ
ຖືກແຈກຢາຍດ້ວຍຫຼັກ Perl. ນີ້ບໍ່ຄວນເຮັດໂດຍບໍ່ມີການຂອງຜູ້ຂຽນ
ການຍິນຍອມເຫັນດີຢ່າງຈະແຈ້ງ, ແລະການຮັບຮູ້ຢ່າງຈະແຈ້ງໃນທຸກພາກສ່ວນທີ່ຫມາຍຄວາມວ່າໂມດູນກໍາລັງເປັນ
ແຈກຢາຍພາຍໃຕ້ເງື່ອນໄຂດຽວກັນກັບ Perl ຕົວຂອງມັນເອງ. ຜູ້ຂຽນໂມດູນຄວນຮັບຮູ້ວ່າ
ການລວມເອົາໂມດູນເຂົ້າໄປໃນຫຼັກ Perl ຈະຕ້ອງຫມາຍເຖິງການສູນເສຍການຄວບຄຸມບາງຢ່າງ
ມັນ, ນັບຕັ້ງແຕ່ການປ່ຽນແປງບາງຄັ້ງອາດຈະຕ້ອງເຮັດໃນແຈ້ງການສັ້ນໆຫຼືເພື່ອໃຫ້ສອດຄ່ອງກັບ
ສ່ວນທີ່ເຫຼືອຂອງ Perl.

ເມື່ອໂມດູນໄດ້ຖືກລວມເຂົ້າໃນຫຼັກ Perl, ແນວໃດກໍ່ຕາມ, ທຸກໆຄົນທີ່ກ່ຽວຂ້ອງ
ການຮັກສາ Perl ຄວນຮູ້ວ່າໂມດູນຍັງຄົງເປັນຊັບສິນຂອງຕົ້ນສະບັບ
ຜູ້ຂຽນເວັ້ນເສຍແຕ່ຜູ້ຂຽນຕົ້ນສະບັບຈະຍອມແພ້ຄວາມເປັນເຈົ້າຂອງຂອງມັນຢ່າງຈະແຈ້ງ. ໃນ
ໂດຍສະເພາະ:

· ຮຸ່ນຂອງໂມດູນໃນຫຼັກ Perl ຄວນຖືວ່າເປັນການເຮັດວຽກຂອງ
ຜູ້ຂຽນຕົ້ນສະບັບ. ແຜ່ນແພັກທັງໝົດ, ລາຍງານຂໍ້ຜິດພາດ ແລະ ອື່ນໆຄວນຖືກສົ່ງຄືນໃຫ້ພວກມັນ.
ທິດທາງການພັດທະນາຂອງເຂົາເຈົ້າຄວນໄດ້ຮັບການເຄົາລົບທຸກຄັ້ງທີ່ເປັນໄປໄດ້.

· ແຜ່ນບາງໆອາດຈະຖືກນຳໃຊ້ໂດຍຜູ້ຖືຜັກໂດຍບໍ່ມີການຮ່ວມມືຢ່າງຈະແຈ້ງ
ຜູ້ຂຽນໂມດູນຖ້າຫາກວ່າແລະພຽງແຕ່ຖ້າຫາກວ່າພວກເຂົາເຈົ້າແມ່ນຫນ້ອຍຫຼາຍ, ທີ່ໃຊ້ເວລາທີ່ສໍາຄັນໃນບາງຄົນອັບເດດ: (ເຊັ່ນ
ເປັນການແກ້ໄຂຄວາມປອດໄພອັນຮີບດ່ວນ), ຫຼືຖ້າຜູ້ຂຽນໂມດູນບໍ່ສາມາດຕິດຕໍ່ໄດ້. ເພີ້ມເຫຼົ່ານັ້ນ
ຍັງຕ້ອງໄດ້ຮັບການມອບຄືນໃຫ້ຜູ້ຂຽນເມື່ອເປັນໄປໄດ້, ແລະຖ້າຜູ້ຂຽນຕັດສິນໃຈກ່ຽວກັບ
ການ​ແກ້​ໄຂ​ສະ​ລັບ​ກັນ​ໃນ​ສະ​ບັບ​ຂອງ​ເຂົາ​ເຈົ້າ​, ການ​ແກ້​ໄຂ​ທີ່​ຄວນ​ຈະ​ເປັນ​ທີ່​ຕ້ອງ​ການ​ຢ່າງ​ແຂງ​ແຮງ​ເວັ້ນ​ເສຍ​ແຕ່​ມີ​
ເປັນບັນຫາຮ້າຍແຮງກັບມັນ. ການປ່ຽນແປງໃດໆທີ່ບໍ່ໄດ້ຮັບການຮັບຮອງໂດຍຜູ້ຂຽນຄວນຈະຖືກຫມາຍເປັນ
ດັ່ງກ່າວ, ແລະຜູ້ປະກອບສ່ວນຂອງການປ່ຽນແປງໄດ້ຮັບຮູ້.

· ສະບັບຂອງໂມດູນທີ່ແຈກຢາຍກັບ Perl ຄວນ, ເມື່ອໃດກໍ່ຕາມທີ່ເປັນໄປໄດ້, ເປັນ
ຮຸ່ນຫຼ້າສຸດຂອງໂມດູນທີ່ແຈກຢາຍໂດຍຜູ້ຂຽນ (ເວີຊັນທີ່ບໍ່ແມ່ນເບຕ້າຫຼ້າສຸດ
ໃນກໍລະນີຂອງການປ່ອຍ Perl ສາທາລະນະ), ເຖິງແມ່ນວ່າຜູ້ຖືຜັກອາດຈະຖືໄປ
ການຍົກລະດັບຮຸ່ນຂອງໂມດູນທີ່ແຈກຢາຍກັບ Perl ເປັນຮຸ່ນຫຼ້າສຸດຈົນກ່ວາ
ສະ​ບັບ​ຫລ້າ​ສຸດ​ໄດ້​ມີ​ການ​ທົດ​ສອບ​ພຽງ​ພໍ​.

ໃນຄໍາສັບຕ່າງໆອື່ນໆ, ຜູ້ຂຽນຂອງໂມດູນຄວນຈະຖືກພິຈາລະນາວ່າມີຄໍາເວົ້າສຸດທ້າຍ
ການດັດແປງໂມດູນຂອງພວກເຂົາທຸກຄັ້ງທີ່ເປັນໄປໄດ້ (ຈົ່ງຈື່ໄວ້ວ່າມັນຄາດວ່າຈະເປັນ
ທຸກ​ຄົນ​ທີ່​ກ່ຽວຂ້ອງ​ຈະ​ເຮັດ​ວຽກ​ຮ່ວມ​ກັນ ​ແລະ ບັນລຸ​ການ​ປະນີປະນອມ​ທີ່​ສົມ​ເຫດ​ສົມ​ຜົນ​ເມື່ອ​ມີ
ຄວາມບໍ່ເຫັນດີ).

ຢ່າງໃດກໍຕາມ, ເປັນທາງເລືອກສຸດທ້າຍ:

ຖ້າຫາກວ່າວິໄສທັດຂອງຜູ້ຂຽນກ່ຽວກັບອະນາຄົດຂອງໂມດູນຂອງເຂົາເຈົ້າແມ່ນພຽງພໍທີ່ແຕກຕ່າງກັນຈາກ
ວິໄສທັດຂອງຜູ້ຖືຜັກແລະ perl5-porters ໂດຍລວມເພື່ອເຮັດໃຫ້ເກີດບັນຫາທີ່ຮ້າຍແຮງ
ສໍາລັບ Perl, ຜູ້ຖືຜັກອາດຈະເລືອກທີ່ຈະ fork ຢ່າງເປັນທາງການສະບັບຂອງໂມດູນໃນ
Perl ຫຼັກຈາກຫນຶ່ງຮັກສາໄວ້ໂດຍຜູ້ຂຽນ. ນີ້ບໍ່ຄວນເຮັດຢ່າງເບົາບາງແລະ
ຄວນ ສະເຫມີໄປ ຖ້າເປັນໄປໄດ້ໃຫ້ເຮັດໄດ້ພຽງແຕ່ຫຼັງຈາກການປ້ອນໂດຍກົງຈາກ Larry. ຖ້ານີ້ແມ່ນ
ເຮັດແລ້ວ, ມັນຕ້ອງໄດ້ເຮັດຢ່າງຈະແຈ້ງໃນໂມດູນທີ່ແຈກຢາຍກັບຫຼັກ Perl ວ່າ
ມັນເປັນສະບັບ forked ແລະວ່າໃນຂະນະທີ່ມັນແມ່ນອີງໃສ່ການເຮັດວຽກຕົ້ນສະບັບຂອງຜູ້ຂຽນ, ມັນບໍ່ແມ່ນ
ຮັກສາໄວ້ດົນກວ່າໂດຍພວກເຂົາ. ນີ້ຕ້ອງໄດ້ຮັບການສັງເກດເຫັນທັງໃນເອກະສານແລະໃນ
ຄໍາເຫັນໃນແຫຼ່ງຂອງໂມດູນ.

ອີກເທື່ອຫນຶ່ງ, ນີ້ຄວນຈະເປັນທາງເລືອກສຸດທ້າຍເທົ່ານັ້ນ. ໂດຍຫລັກການແລ້ວ, ນີ້ບໍ່ຄວນເກີດຂຶ້ນ, ແລະທຸກ
ກ່ອນ​ທີ່​ຈະ​ດຳ​ເນີນ​ການ​ຮ່ວມ​ມື​ແລະ​ການ​ປະ​ນີ​ປະ​ນອມ​ທີ່​ເປັນ​ໄປ​ໄດ້​ຄວນ​ໄດ້​ຮັບ​ຄວາມ​ພະ​ຍາ​ຍາມ. ຖ້າ​ຫາກ​ວ່າ​ມັນ
ພິສູດວ່າມີຄວາມຈໍາເປັນທີ່ຈະຕັດໂມດູນສໍາລັບສຸຂະພາບໂດຍລວມຂອງ Perl, ສິນເຊື່ອທີ່ເຫມາະສົມຕ້ອງ
ຈະຖືກມອບໃຫ້ຜູ້ຂຽນຕົ້ນສະບັບຕະຫຼອດໄປແລະການຕັດສິນໃຈຄວນຈະຖືກທົບທວນຄືນຢ່າງຕໍ່ເນື່ອງ.
ການປະເມີນເພື່ອເບິ່ງວ່າການຟື້ນຕົວຂອງສອງສາຂາແມ່ນເປັນໄປໄດ້ຕາມເສັ້ນທາງ.

ໃນການຈັດການກັບໂມດູນທີ່ປະກອບສ່ວນທັງຫມົດ, ທຸກໆຄົນທີ່ຮັກສາ Perl ຄວນຈື່ໄວ້
ວ່າລະຫັດເປັນຂອງຜູ້ຂຽນຕົ້ນສະບັບ, ວ່າພວກເຂົາອາດຈະບໍ່ຢູ່ໃນ perl5-porters ໃດໆ
ທີ່​ໃຊ້​ເວ​ລາ​, ແລະ​ວ່າ patch ເປັນ​ບໍ່​ເປັນ​ທາງ​ການ​ເວັ້ນ​ເສຍ​ແຕ່​ວ່າ​ມັນ​ໄດ້​ຮັບ​ການ​ລວມ​ເຂົ້າ​ໃນ​
ສໍາເນົາຂອງຜູ້ຂຽນຂອງໂມດູນ. ເພື່ອຊ່ວຍໃນເລື່ອງນີ້, ແລະດ້ວຍຈຸດ #1, #2, ແລະ #3 ຂ້າງເທິງ,
ຂໍ້​ມູນ​ຕິດ​ຕໍ່​ສໍາ​ລັບ​ຜູ້​ຂຽນ​ຂອງ​ໂມ​ດູນ​ປະ​ກອບ​ສ່ວນ​ທັງ​ຫມົດ​ຄວນ​ຈະ​ໄດ້​ຮັບ​ການ​ເກັບ​ຮັກ​ສາ​ໄວ້​ກັບ​
ການແຜ່ກະຈາຍ Perl.

ສຸດທ້າຍ, ຊຸມຊົນ Perl ທັງຫມົດຮັບຮູ້ວ່າເຄົາລົບຄວາມເປັນເຈົ້າຂອງລະຫັດ,
ເຄົາລົບການຄວບຄຸມສິລະປະ, ສິນເຊື່ອທີ່ເຫມາະສົມ, ແລະຄວາມພະຍາຍາມຢ່າງຫ້າວຫັນເພື່ອປ້ອງກັນການບໍ່ຕັ້ງໃຈ
code skew ຫຼືຊ່ອງຫວ່າງການສື່ສານແມ່ນສໍາຄັນຕໍ່ສຸຂະພາບຂອງຊຸມຊົນແລະ Perl ເອງ.
ປົກກະຕິແລ້ວ ສະມາຊິກຂອງຊຸມຊົນບໍ່ຄວນຈຳເປັນຕ້ອງຫັນໄປສູ່ກົດລະບຽບ ແລະກົດໝາຍເພື່ອຈັດການກັບ
ເຊິ່ງກັນແລະກັນ, ແລະເອກະສານນີ້, ເຖິງແມ່ນວ່າມັນມີກົດລະບຽບເພື່ອໃຫ້ຈະແຈ້ງ, ແມ່ນກ່ຽວກັບ
ທັດສະນະຄະຕິ ແລະວິທີການທົ່ວໄປ. ຂັ້ນຕອນທໍາອິດໃນການຂັດແຍ້ງໃດໆຄວນຈະເປີດ
ການ​ສື່​ສານ​, ການ​ເຄົາ​ລົບ​ຕໍ່​ກັບ​ທັດ​ສະ​ນະ​ທີ່​ກົງ​ກັນ​ຂ້າມ​, ແລະ​ຄວາມ​ພະ​ຍາ​ຍາມ​ໃນ​ການ​ປະ​ນີ​ປະ​ນ​ອມ​. ໃນເກືອບ
ທຸກໆສະຖານະການບໍ່ມີຫຍັງຈະມີຄວາມຈໍາເປັນ, ແລະແນ່ນອນວ່າບໍ່ມີມາດຕະການທີ່ຮຸນແຮງອີກຕໍ່ໄປ
ຄວນຈະຖືກນໍາໃຊ້ຈົນກ່ວາທຸກໆເສັ້ນທາງຂອງການສື່ສານແລະການສົນທະນາລົ້ມເຫລວ.

ເອກະສານອ້າງອີງ

ເອກະສານຂອງ Perl ເປັນຊັບພະຍາກອນທີ່ສໍາຄັນສໍາລັບຜູ້ໃຊ້ຂອງພວກເຮົາ. ມັນເປັນສິ່ງສໍາຄັນ incredibly ສໍາລັບ
ເອກະສານຂອງ Perl ເພື່ອໃຫ້ສອດຄ່ອງກັນຢ່າງສົມເຫດສົມຜົນແລະສະທ້ອນເຖິງປະຈຸບັນຢ່າງຖືກຕ້ອງ
ການຈັດຕັ້ງປະຕິບັດ.

ເຊັ່ນດຽວກັບ P5P ຮັກສາພື້ນຖານລະຫັດ, ພວກເຮົາຮັກສາການລວບລວມ
ເອກະສານ. ການຂຽນເອກະສານບາງອັນບໍ່ໄດ້ໃຫ້ການຄວບຄຸມຜູ້ຂຽນ
ອະນາຄົດຂອງເອກະສານດັ່ງກ່າວ. ໃນເວລາດຽວກັນ, ຄືກັນກັບການປ່ຽນແປງລະຫັດແຫຼ່ງຄວນ
ກົງກັບຮູບແບບຂອງທ່ອນໄມ້ອ້ອມຂ້າງ, ດັ່ງນັ້ນເອກະສານຄວນປ່ຽນແປງ.

ຕົວຢ່າງໃນເອກະສານຄວນຈະເປັນຕົວຢ່າງຂອງແນວຄວາມຄິດທີ່ເຂົາເຈົ້າກໍາລັງອະທິບາຍ.
ບາງຄັ້ງ, ວິທີທີ່ດີທີ່ສຸດທີ່ຈະສະແດງໃຫ້ເຫັນວ່າລັກສະນະພາສາເຮັດວຽກກັບໂຄງການຂະຫນາດນ້ອຍ
ຜູ້ອ່ານສາມາດດໍາເນີນການໂດຍບໍ່ມີການດັດແປງ. ເລື້ອຍໆ, ຕົວຢ່າງຈະປະກອບດ້ວຍ snippet ຂອງ
ລະຫັດທີ່ມີພຽງແຕ່ "ທີ່ສໍາຄັນ" ບິດ. ຄໍານິຍາມຂອງ "ສໍາຄັນ" ແຕກຕ່າງກັນຈາກ
snippet ກັບ snippet. ບາງຄັ້ງມັນເປັນສິ່ງສໍາຄັນທີ່ຈະປະກາດ "ໃຊ້ຢ່າງເຂັ້ມງວດ" ແລະ "ໃຊ້ຄໍາເຕືອນ",
ເລີ່ມຕົ້ນຕົວແປທັງໝົດ ແລະຈັບທຸກເງື່ອນໄຂຂໍ້ຜິດພາດ. ເລື້ອຍໆກ່ວາບໍ່,
ເຖິງຢ່າງໃດກໍຕາມ, ສິ່ງເຫຼົ່ານັ້ນເຮັດໃຫ້ບົດຮຽນທີ່ຫຍໍ້ມາຈາກຕົວຢ່າງທີ່ມີຈຸດປະສົງສອນ.

ເນື່ອງຈາກ Perl ຖືກພັດທະນາໂດຍທີມງານອາສາສະຫມັກທົ່ວໂລກ, ເອກະສານຂອງພວກເຮົາມັກຈະປະກອບດ້ວຍ
ການສະກົດຄໍາທີ່ເບິ່ງເປັນເລື່ອງຕະຫລົກ ບາງຄົນ. ທາງເລືອກຂອງອາເມລິກາ / ອັງກິດ / ການສະກົດຄໍາອື່ນໆແມ່ນ
ໄວ້ເປັນບົດຝຶກຫັດສໍາລັບຜູ້ຂຽນຂອງແຕ່ລະເອກະສານ. ເມື່ອ patching
ເອກະສານ, ພະຍາຍາມເຮັດຕາມເອກະສານທີ່ອ້ອມຮອບທ່ານ, ແທນທີ່ຈະປ່ຽນ
prose ທີ່​ມີ​ຢູ່​ແລ້ວ​.

ໂດຍທົ່ວໄປ, ເອກະສານຄວນອະທິບາຍສິ່ງທີ່ Perl ເຮັດ "ໃນປັດຈຸບັນ" ແທນທີ່ຈະເປັນສິ່ງທີ່ມັນເຄີຍເຮັດ
ເຮັດ. ມັນສົມເຫດສົມຜົນຢ່າງສົມບູນທີ່ຈະລວມເອົາບັນທຶກໃນເອກະສານກ່ຽວກັບວິທີການປະພຶດ
ມີການປ່ຽນແປງຈາກການເປີດຕົວທີ່ຜ່ານມາ, ແຕ່ວ່າ, ມີຂໍ້ຍົກເວັ້ນຫນ້ອຍຫຼາຍ, ເອກະສານບໍ່ແມ່ນ "ສອງ-
ຊີວິດ" -- ມັນບໍ່ຈໍາເປັນຕ້ອງອະທິບາຍຢ່າງເຕັມທີ່ວ່າສະບັບເກົ່າທັງຫມົດທີ່ໃຊ້ໃນການເຮັດວຽກ.

ມາດຕະຖານ OF ປຶກສາຫາລື

ເວທີປາໄສຢ່າງເປັນທາງການສໍາລັບການພັດທະນາຂອງ perl ແມ່ນບັນຊີລາຍຊື່ທາງໄປສະນີ perl5-porters,
ທີ່ໄດ້ກ່າວມາຂ້າງເທິງ, ແລະ bugtracker ຂອງມັນຢູ່ທີ່ rt.perl.org. ຜູ້ເຂົ້າຮ່ວມສົນທະນາທັງໝົດຢູ່ທີ່ນັ້ນ
ຄາດວ່າຈະປະຕິບັດຕາມມາດຕະຖານການປະພຶດ.

· ເປັນພົນລະເມືອງສະເໝີ.

· ເອົາໃຈໃສ່ຜູ້ຄວບຄຸມ.

ພົນລະເຮືອນແມ່ນງ່າຍດາຍ: ຍຶດຫມັ້ນກັບຄວາມຈິງໃນຂະນະທີ່ຫຼີກເວັ້ນການຕໍາຫນິຕິຕຽນແລະຄໍາເວົ້າຫຍາບຄາຍ. ມັນ
ບໍ່ພຽງພໍທີ່ຈະເປັນຄວາມຈິງ. ເຈົ້າຍັງຕ້ອງເປັນພົນລະເມືອງ. ຕອບສະຫນອງໃນປະເພດຂອງ incivility ແມ່ນ
ບໍ່ຍອມຮັບ.

ໃນ​ຂະ​ນະ​ທີ່​ຄວາມ​ເປັນ​ພົນ​ລະ​ເມືອງ​ແມ່ນ​ຕ້ອງ​ການ, ຄວາມ​ເມດ​ຕາ​ແມ່ນ​ໄດ້​ຮັບ​ການ​ຊຸກ​ຍູ້; ຖ້າທ່ານມີຄວາມສົງໃສກ່ຽວກັບວ່າ
ເຈົ້າເປັນພົນລະເມືອງ, ພຽງແຕ່ຖາມຕົວເອງວ່າ, "ຂ້ອຍມີຄວາມເມດຕາບໍ?" ແລະປາຖະຫນາທີ່ຈະວ່າ.

ຖ້າຜູ້ຄວບຄຸມລາຍຊື່ບອກເຈົ້າວ່າເຈົ້າບໍ່ໄດ້ເປັນພົນລະເມືອງ, ພິຈາລະນາຢ່າງລະມັດລະວັງວ່າເຈົ້າຈະເຮັດແນວໃດ
ຄໍາສັບຕ່າງໆໄດ້ປາກົດກ່ອນທີ່ຈະຕອບສະຫນອງໃນທາງໃດກໍ່ຕາມ. ພວກເຂົາເຈົ້າມີຄວາມເມດຕາບໍ? ເຈົ້າອາດຈະປະທ້ວງ, ແຕ່
ການ​ປະ​ທ້ວງ​ຊ້ຳ​ແລ້ວ​ຊ້ຳ​ອີກ​ໃນ​ການ​ປະ​ເຊີນ​ໜ້າ​ກັບ​ການ​ຕັດ​ສິນ​ໃຈ​ທີ່​ໄດ້​ຮັບ​ການ​ຢືນ​ຢັນ​ຊ້ຳ​ແລ້ວ​ຊ້ຳ​ແລ້ວ​ຊ້ຳ​ຄືນ​ແມ່ນ​ບໍ່​ຍອມ​ຮັບ.

ພຶດຕິກໍາທີ່ບໍ່ສາມາດຍອມຮັບໄດ້ຈະເຮັດໃຫ້ເກີດການເຕືອນສາທາລະນະແລະຖືກກໍານົດຢ່າງຊັດເຈນ. ຊ້ຳ
ພຶດຕິກໍາທີ່ບໍ່ສາມາດຍອມຮັບໄດ້ຈະສົ່ງຜົນໃຫ້ມີການໂຍກຍ້າຍອອກຈາກບັນຊີລາຍຊື່ທາງໄປສະນີແລະການຖອນຄືນ
ສິດທິໃນການປັບປຸງ rt.perl.org. ການໂຍກຍ້າຍຄັ້ງທໍາອິດແມ່ນເປັນເວລາຫນຶ່ງເດືອນ. ການໂຍກຍ້າຍຕໍ່ມາ
ຈະເພີ່ມຄວາມຍາວສອງເທົ່າ. ຫຼັງຈາກຫົກເດືອນທີ່ບໍ່ມີການເຕືອນ, ໄລຍະເວລາການຫ້າມຂອງຜູ້ໃຊ້ຈະຖືກຕັ້ງຄືນໃຫມ່.
ການລຶບອອກ, ເຊັ່ນ: ການເຕືອນໄພ, ແມ່ນສາທາລະນະ.

ບັນຊີລາຍຊື່ຂອງຜູ້ຄວບຄຸມຈະເປັນຄວາມຮູ້ສາທາລະນະ. ໃນປັດຈຸບັນ, ມັນແມ່ນ: Aaron Crane, Andy
Dougherty, Ricardo Signes, Steffen Mueller.

CREDITS

"ສັນຍາສັງຄົມກ່ຽວກັບໂມດູນປະກອບສ່ວນ" ໃນເບື້ອງຕົ້ນໂດຍ Russ Allberyrra@stanford.edu>
ແລະ perl5-porters.

ໃຊ້ perlpolicy ອອນໄລນ໌ໂດຍໃຊ້ບໍລິການ onworks.net