perlpolicy - Интернет в облаке

ПРОГРАММА:

ИМЯ

perlpolicy - различные политики и обязательства, относящиеся к ядру Perl.

ОПИСАНИЕ

Этот документ является основным документом, в котором записаны все письменные политики о том, как Perl
5 Портеров коллективно разрабатывают и поддерживают ядро ​​Perl.

УПРАВЛЕНИЕ

Perl 5 Носильщик
Подписчики на perl5-porters (сами портеры) бывают разных видов. Некоторые
тихие любопытные скрытни, которые редко вмешиваются и вместо этого наблюдают за продолжающимся развитием, чтобы
убедитесь, что они предупреждены о новых изменениях или возможностях Perl. Некоторые из них являются представителями
поставщиков, которые следят за тем, чтобы Perl продолжал компилировать и работать над своими
платформы. Некоторые исправляют любую обнаруженную ошибку, которую знают, как исправить, некоторые активно
исправляя свою домашнюю область (потоки, Win32, механизм регулярных выражений), в то время как другие, похоже, делают
ничего, кроме жалоб. Другими словами, это обычное сочетание технических специалистов.

Этой группой носильщиков руководит Ларри Уолл. За ним последнее слово в том, что делает и
не изменяется ни на одном из языков программирования Perl. В наши дни Ларри тратит больше всего
своего времени на Perl 6, в то время как Perl 5 находится под присмотром «накачивающего», ответственного за носильщика.
для принятия решения о том, что входит в каждый выпуск, и обеспечения того, чтобы выпуски выпускались на регулярной основе
основа.

Ларри видит развитие Perl аналогично правительству США: есть Законодательное собрание.
(носильщики), исполнительная власть (насос) и Верховный суд (Ларри). В
законодательный орган может обсуждать и вносить исправления в исполнительную власть сколько угодно, но
исполнительная власть вправе наложить вето на них. В редких случаях Верховный суд принимает сторону
исполнительная власть над законодательной или законодательная власть над исполнительной.
Однако в большинстве случаев предполагается, что законодательная и исполнительная ветви власти ладят друг с другом и
уладить свои разногласия без импичмента или судебных дел.

Иногда можно встретить ссылку на Правило 1 и Правило 2. Власть Ларри как Верховного Суда
выражено в Правилах:

1. Ларри всегда по определению прав в том, как должен себя вести Perl. Это означает, что у него есть
окончательное право вето на основные функции.

2. Ларри может изменить свое мнение по любому вопросу позднее, независимо от
применял ли он ранее Правило 1.

Понял? Ларри всегда прав, даже когда ошибался. Редко можно увидеть любое правило
упражняются, но на них часто ссылаются.

ОБСЛУЖИВАНИЕ И ПОДДЕРЖКA

Perl 5 разрабатывается сообществом, а не корпорацией. Каждое изменение способствовало
Ядро Perl - это результат пожертвования. Обычно это пожертвования в размере
код или время отдельными членами нашего сообщества. Иногда эти пожертвования поступают
форма корпоративного или организационного спонсорства конкретного человека или проекта.

Как волонтерская организация, наши обязательства во многом зависят от доброй воли.
и упорный труд людей, которые не обязаны вносить свой вклад в Perl.

При этом мы ценим стабильность и безопасность Perl и давно имеем неписаный
договор с более широким сообществом Perl поддерживать и поддерживать выпуски Perl.

Этот документ кодифицирует обязательства по поддержке и обслуживанию, которые сообщество Perl
следует ожидать от разработчиков Perl:

· Мы «официально» поддерживаем две самые последние серии стабильных выпусков. 5.16.x и ранее
сейчас не поддерживаются. С выпуском 5.22.0 мы "официально" прекратим поддержку
для Perl 5.18.x, кроме предоставления обновлений безопасности, как описано ниже.

· В меру наших возможностей мы постараемся исправить критические проблемы в двух самых
последняя стабильная серия релизов 5.x. Исправления для текущей серии релизов принимают
приоритет над исправлениями для предыдущей серии выпусков.

· В меру наших возможностей мы предоставим «критические» исправления / выпуски безопасности для
любая основная версия Perl, выпуск 5.x.0 которой был выпущен в течение последних трех лет. Мы можем
обязуются предоставлять их только для самого последнего выпуска .y в любой серии 5.xy.

· Мы не будем предоставлять обновления безопасности или исправления ошибок для разрабатываемых версий Perl.

· Мы рекомендуем поставщикам поставлять самую последнюю поддерживаемую версию Perl на момент выпуска
их код замораживается.

· Как поставщик, вам может потребоваться выполнить резервное копирование исправлений безопасности по истечении трех лет
поддерживать приверженность. Мы можем предоставить вам ограниченную поддержку и советы по мере того, как вы это делаете.
и, где это возможно, будет пытаться применить эти исправления к соответствующим веткам -maint в
git, хотя мы можем или не можем делать нумерованные выпуски или «официальные» патчи
доступный. Свяжитесь с нами по[электронная почта защищена]> чтобы начать этот процесс.

НАЗАД СОВМЕСТИМОСТЬ И УДАЛЕНИЕ

В нашем сообществе давно существует убеждение, что обратная совместимость - это достоинство, даже если
рассматриваемая функциональность является недостатком дизайна.

Мы все хотели бы исправить некоторые ошибки, которые мы совершили за последние десятилетия. Жить с
каждая ошибка в дизайне, которую мы когда-либо делали, может привести к болезненной стагнации. Разматывая наши ошибки
очень и очень сложно. Сделать это, не причиняя вреда нашим пользователям, почти
невозможно.

В последнее время пришло игнорирование или активное противодействие совместимости с более ранними версиями Perl.
в моду. Иногда предлагается изменение, которое хочет узурпировать синтаксис, который ранее
имел другое значение. Иногда изменение хочет улучшить ранее сумасшедшую семантику.

На этом пути лежит безумие.

Требование от программистов-конечных пользователей изменить всего несколько языковых конструкций, даже язык
конструкции, которые ни один образованный разработчик никогда бы не использовал намеренно, равносильно
говоря, что "вы не должны обновляться до новой версии Perl, если у вас нет 100% тестового покрытия.
и можем провести полный аудит вашей кодовой базы вручную ". Если бы у нас были инструменты, способные
надежное обновление исходного кода Perl с одной версии Perl на другую, эта проблема
можно было значительно уменьшить.

Мы хотим, чтобы Perl продолжал развиваться и процветать в ближайшие годы, и
десятилетиями, но не за счет нашего сообщества пользователей.

Существующий синтаксис и семантика должны быть помечены для уничтожения только в очень ограниченном количестве.
обстоятельства. Если предполагается, что они используются очень редко, встаньте на пути реальных
улучшение языка Perl или интерпретатора Perl, и если затронутый код может быть легко
обновлены для продолжения работы, они могут быть рассмотрены для удаления. Если есть сомнения, осторожность
диктует, что мы будем поддерживать обратную совместимость. Когда функция устарела,
будет размещено изложение аргументации, описывающее процесс принятия решения, и ссылка на него
будут предоставлены в соответствующих документах perldelta.

Использование лексической прагмы для включения или отключения устаревшего поведения следует учитывать, когда
подходящим, и при отсутствии каких-либо прагм должно быть разрешено унаследованное поведение. Который
обратно несовместимые изменения неявно контролируются "использовать v5.xy" - это решение
что должно быть сделано путем прокачки по согласованию с сообществом.

Исторически мы придерживались гораздо более высоких стандартов, чем обратная совместимость -
совместимость с ошибками. Любая случайность внедрения или непреднамеренный побочный эффект
запуск некоторого фрагмента кода считался особенностью языка, который
защищается с таким же рвением, как и любые другие функции или возможности. Не важно как
эти непреднамеренные особенности могут расстроить нас, поскольку мы продолжаем улучшать Perl,
эти непреднамеренные особенности часто заслуживают нашей защиты. Очень важно, чтобы
существующее программное обеспечение, написанное на Perl, продолжает работать правильно. Если у разработчиков конечных пользователей есть
приняли ошибку как функцию, мы должны относиться к ней как к таковой.

Новый синтаксис и семантика, которые не нарушают существующие языковые конструкции и синтаксис, имеют
намного более низкий бар. Им просто нужно доказать, что они полезны, элегантны, хорошо разбираются.
разработан и хорошо протестирован. В большинстве случаев эти дополнения будут отмечены как экспериментальный
на некоторое время. Подробнее об этом см. Ниже.

Терминология
Чтобы убедиться, что мы говорим об одном и том же, когда обсуждаем удаление функций или
функциональность ядра Perl, у нас есть конкретные определения для нескольких слов и
фразы.

экспериментальный
Если что-то в ядре Perl помечено как экспериментальный, мы можем изменить его поведение,
отменить или удалить его без предварительного уведомления. Хотя мы всегда будем делать все возможное, чтобы сгладить
путь перехода для пользователей экспериментальных функций, вам следует связаться с
список рассылки perl5-porters, если вы нашли экспериментальную функцию полезной и хотите помочь
сформировать его будущее.

Экспериментальные функции должны быть экспериментальными в двух стабильных версиях, прежде чем они будут отмечены
не экспериментальный. Экспериментальные функции будут иметь только экспериментальный статус.
отозвано, когда у них больше нет открытых для них ошибок, изменяющих дизайн, и когда
их поведение не изменилось на протяжении всего цикла разработки.
Другими словами, функция, представленная в v5.20.0, может быть помечена как не экспериментальная в
v5.22.0 тогда и только тогда, когда его поведение не меняется на протяжении всего v5.21.

устарела
Если что-то в ядре Perl помечено как устарела, мы можем удалить его из ядра
в будущем, хотя, возможно, и нет. Как правило, обратно несовместимые изменения будут
иметь предупреждения об устаревании за два цикла выпуска перед удалением, но может быть
удаляется после всего лишь одного цикла, если риск кажется довольно низким или польза довольно высока.

Начиная с Perl 5.12 устаревшие функции и модули предупреждают пользователя о том, что они используются. Когда
модуль устарел, он также будет доступен на CPAN. Установка из
CPAN отключит предупреждения об устаревании для этого модуля.

Если вы используете устаревшую функцию или модуль и считаете, что его удаление из Perl
core будет ошибкой, обратитесь в список рассылки perl5-porters и попросите
кейс. Мы не осуждаем вещи без уважительной причины, но иногда
Контраргумент мы не рассмотрели. Исторически мы не делали различия между
"устаревшие" и "нежелательные" функции.

обескураженный
Время от времени мы можем отмечать языковые конструкции и особенности, которые, по нашему мнению,
были ошибки как обескураженный. Не рекомендуемые функции в настоящее время не являются кандидатами
для удаления, но позже мы можем отказаться от них, если окажется, что они стоят на пути
значительное улучшение ядра Perl.

удаленный
Как только функция, конструкция или модуль помечены как устаревшие, мы можем удалить их.
из ядра Perl. Неудивительно, что мы говорим, что удаленный эти вещи. Когда модуль
удален, он больше не будет поставляться с Perl, но будет по-прежнему доступен на
КПАН.

ОБСЛУЖИВАНИЕ ФИЛИАЛЫ

Новые выпуски обслуживаемых веток должны содержать только изменения, попадающие в одну из
"приемлемые" категории изложены ниже, но не должны содержать никаких изменений, которые попадают в одну
из «неприемлемых» категорий. (Например, исправление сбойной ошибки не должно
включается, если это нарушает двоичную совместимость.)

Нет необходимости включать все изменения, отвечающие этим критериям, и в целом
следует сосредоточить внимание на решении проблем безопасности, сбоях в работе, регрессии и серьезных проблемах.
проблемы с установкой. Соблазн включить множество мелких изменений, которые не
влияют на установку или выполнение Perl (например, исправления орфографии в документации)
следует сопротивляться, чтобы снизить общий риск чего-то не заметить. В
намерение состоит в том, чтобы создавать выпуски обслуживания, которые имеют смысл и которые пользователи могут
полностью уверены в стабильности. (Второстепенная задача - избежать выгорания
поддержание поддержки или подавляющее большинство других коммиттеров, голосующих за изменения, которые должны быть включены (см.
«Получение изменений в основной ветке» ниже).)

Следующие типы изменений могут считаться приемлемыми, если они также не
попадают в любую из "неприемлемых" категорий, изложенных ниже:

· Патчи, исправляющие CVE или проблемы с безопасностью. Эти изменения следует выполнить через
[электронная почта защищена] список рассылки, а не применяется напрямую.

· Патчи, которые исправляют сбойные ошибки, сбои утверждений и повреждение памяти, но которые делают
не изменять иным образом функциональность Perl или отрицательно влиять на производительность.

· Патчи, которые исправляют регресс в поведении Perl по сравнению с предыдущими выпусками, нет
независимо от того, сколько лет регрессии, так как некоторые люди могут обновиться с очень старых версий
perl до последней версии.

· Патчи, исправляющие ошибки в функциях, которые были новыми в соответствующей стабильной версии 5.x.0
отпустить.

· Патчи, которые исправляют все, что мешает или серьезно влияет на сборку или
установка perl.

· Исправления переносимости, такие как изменения в Configure и файлах в папке hints /.

· Минимальные патчи, исправляющие сбои тестов для конкретной платформы.

· Обновления документации, которые исправляют фактические ошибки, объясняют существенные ошибки или
недостатки текущей реализации или исправление неработающей разметки.

· Обновления модулей с двойным сроком службы должны состоять из минимальных исправлений для исправления сбоев или ошибок.
проблемы безопасности (как указано выше). Любые изменения, внесенные в модули с двойным сроком службы, для которых CPAN
canonical должен быть согласован с автором апстрима.

НЕ допускаются следующие типы изменений:

· Патчи, нарушающие бинарную совместимость. (Пожалуйста, поговорите с тыквой.)

· Патчи, добавляющие или удаляющие функции.

· Патчи, которые добавляют новые предупреждения или ошибки или отменяют функции.

· Перенос Perl на новую платформу, архитектуру или выпуск ОС, включающий изменения в
реализация.

· Новые версии модулей dual-life НЕ ДОЛЖНЫ быть импортированы в maint. Те принадлежат
следующая стабильная серия.

Если есть какие-либо вопросы о том, заслуживает ли данный патч включения в основной
release, то его почти наверняка не стоит включать.

Получающий изменения в a Т.О. филиал
Исторически сложилось так, что с bleadperl на maintperl переходила только потрясающая вишня. Этот
имеет проблемы с масштабированием. В то же время поддерживающие ветки стабильных версий Perl
нужно относиться с большой осторожностью. Для этого, начиная с Perl 5.12, у нас есть новый процесс
для основных филиалов.

Любой коммиттер может выбрать любую фиксацию из blead в ветку maint, если они отправят почту на
perl5-porters объявляют о своем намерении выбрать конкретный коммит вместе с
обоснование для этого, и по крайней мере два других коммиттера ответили на список, указав свои
согласие. (Эта политика распространяется на нынешних и бывших королей тыкв, а также на других
коммиттеры.)

Вместо этого могут использоваться другие механизмы голосования, если будет подано такое же количество голосов.
собраны прозрачно. В частности, предложения о том, какие изменения в Cherry-Pick
должны быть видны всем пользователям perl5-porters, чтобы мнения всех заинтересованных
быть услышанным.

Нет необходимости проводить голосование по избранным записям perldelta, связанным с
с изменениями, которые уже были тщательно отобраны, ни для получения
голосование по изменениям, требуемым Перенос / release_managers_guide.pod где такие изменения могут
наносить вишневым способом из бледа.

ДОПОЛНИТЕЛЬНО МОДУЛИ

A Социальное сопровождение контракт о Художественный Control
Далее следует утверждение о художественном контроле, определяемом как способность авторов
пакеты, чтобы направлять будущее своего кода и поддерживать контроль над их работой. Это
признание того, что авторы должны контролировать свою работу, и что это
ответственность остальной части сообщества Perl за сохранение этого контроля.
Это попытка задокументировать стандарты, которых мы, как разработчики Perl, намерены придерживаться.
мы сами. Это попытка составить приблизительные инструкции о том, какое уважение мы обязаны каждому.
другие как разработчики Perl.

Это заявление не является юридическим договором. Это заявление не является юридическим документом ни в каком
путь, форма или форма. Perl распространяется под лицензией GNU Public License и под
Художественная лицензия; это точные юридические термины. Это заявление не о законе
или лицензии. Речь идет о сообществе, взаимном уважении, доверии и добросовестном сотрудничестве.

Мы понимаем, что ядро ​​Perl, определяемое как программное обеспечение, распространяемое с сердцем
Сам Perl - это совместный проект всех нас. Время от времени сценарий,
модуль, или набор модулей (далее просто «модуль») докажет, что
широко полезен и / или настолько важен для правильного функционирования самого Perl, что должен
распространяться с ядром Perl. Это никогда не должно происходить без авторской
явное согласие и четкое признание на всех сторонах того, что это означает, что модуль
распространяется на тех же условиях, что и сам Perl. Автор модуля должен понимать, что
включение модуля в ядро ​​Perl обязательно будет означать некоторую потерю контроля над
это, так как изменения могут иногда быть внесены в кратчайшие сроки или для согласования с
остальная часть Perl.

Однако после включения модуля в ядро ​​Perl все участники
при поддержке Perl следует помнить, что модуль по-прежнему является собственностью оригинала.
автор, если первоначальный автор явно не отказывается от своей собственности на него. В
специфический:

· Версия модуля в ядре Perl по-прежнему должна рассматриваться как работа
оригинальный автор. Все исправления, отчеты об ошибках и т. Д. Должны возвращаться им.
По возможности следует соблюдать их направления развития.

· Патчи могут быть наложены держателем тыквы без явного сотрудничества с
автора модуля тогда и только тогда, когда они очень незначительны, в некоторой степени критичны по времени (например,
в качестве срочных исправлений безопасности), или если невозможно связаться с автором модуля. Эти патчи
по-прежнему должны быть возвращены автору, когда это возможно, и если автор решит
альтернативное исправление в их версии, это исправление должно быть настоятельно рекомендовано, если нет
с этим серьезная проблема. Любые изменения, не одобренные автором, должны быть помечены как
такие, и участник изменения признан.

· Версия модуля, распространяемого с Perl, по возможности должна быть
последняя версия модуля, распространяемая автором (последняя не бета-версия
в случае общедоступных релизов Perl), хотя держатель для тыквы может отложить
обновление версии модуля, распространяемого с Perl, до последней версии, пока
последняя версия прошла достаточное тестирование.

Другими словами, следует считать, что последнее слово по поводу
модификации своего модуля, когда это возможно (имея в виду, что ожидается, что
все участники будут работать вместе и прийти к разумным компромиссам, когда есть
разногласия).

Однако в крайнем случае:

Если авторское видение будущего их модуля существенно отличается от
видение подставки для тыквы и perl5-porters в целом, чтобы вызвать серьезные проблемы
для Perl держатель тыквы может решить формально форкнуть версию модуля в
Ядро Perl из того, что поддерживает автор. Это не следует делать легкомысленно и
должен всегда если это вообще возможно, будет сделано только после непосредственного участия Ларри. Если это
сделано, это должно быть явно указано в модуле, распространяемом с ядром Perl, который
это разветвленная версия, и, хотя она основана на оригинальной работе автора, она не
дольше поддерживается ими. Это необходимо отметить как в документации, так и в
комментарии в источнике модуля.

Опять же, это должно быть только последнее средство. В идеале этого никогда не должно происходить, и каждый
возможные усилия по сотрудничеству и компромиссу должны быть предприняты, прежде чем делать это. Если это
оказывается необходимым для форка модуля для общего состояния Perl, надлежащая оценка должна
передаваться первоначальному автору бессрочно, и решение должно постоянно пересматриваться.
оценивается, чтобы увидеть, возможно ли повторное слияние двух ветвей в будущем.

Во всех отношениях с добавленными модулями каждый, кто поддерживает Perl, должен иметь в виду
что код принадлежит первоначальному автору, что они не могут быть на perl5-портерах
данное время, и что патч не является официальным, если он не был интегрирован в
авторская копия модуля. Чтобы помочь в этом, а также с пунктами №1, №2 и №3 выше,
контактная информация авторов всех добавленных модулей должна храниться в
Распространение Perl.

Наконец, сообщество Perl в целом признает это уважение к владению кодом,
уважение к художественному контролю, должное признание и активные усилия по предотвращению непреднамеренных
перекос кода или пробелы в коммуникации жизненно важны для здоровья сообщества и самого Perl.
Члены сообщества обычно не должны прибегать к правилам и законам, чтобы иметь дело с
друг друга, и этот документ, хотя и содержит правила для ясности, посвящен
отношение и общий подход. Первый шаг в любом споре должен быть открытым
общение, уважение противоположных взглядов и попытка достижения компромисса. Почти в
при любых обстоятельствах больше ничего не потребуется, и уж тем более решительных мер
следует использовать до тех пор, пока не потерпят неудачу все способы общения и обсуждения.

ДОКУМЕНТАЦИЯ

Документация Perl - важный ресурс для наших пользователей. Это невероятно важно для
Документация Perl должна быть достаточно последовательной и точно отражать текущую
реализации.

Подобно тому, как P5P коллективно поддерживает кодовую базу, мы коллективно поддерживаем
документация. Написание определенного фрагмента документации не дает права автора
будущего этой документации. В то же время, как и изменения исходного кода,
соответствуют стилю окружающих их блоков, поэтому следует вносить изменения в документацию.

Примеры в документации должны иллюстрировать концепцию, которую они объясняют.
Иногда лучший способ показать, как работает языковая функция, - это небольшая программа,
Читатель может работать без изменений. Чаще всего примеры будут состоять из фрагментов
код, содержащий только «важные» биты. Определение «важного» варьируется от
сниппет в сниппет. Иногда важно объявить "использовать строго" и "использовать предупреждения",
инициализировать все переменные и полностью уловить каждое состояние ошибки. Чаще да, чем нет,
однако эти вещи затемняют урок, который должен был преподать пример.

Поскольку Perl разрабатывается глобальной командой добровольцев, наша документация часто содержит
варианты написания, которые выглядят смешно для кто-то. Выбор американского / британского / другого написания
оставлено как упражнение для автора каждой части документации. При исправлении
документации, попробуйте подражать документации вокруг вас, а не менять
существующая проза.

В общем, документация должна описывать то, что Perl делает «сейчас», а не то, что раньше.
делать. Вполне разумно включить в документацию примечания о том, как поведение
изменилось по сравнению с предыдущими выпусками, но, за очень немногими исключениями, документация не "двойная"
жизнь »- не нужно полностью описывать, как работали все старые версии.

СТАНДАРТЫ OF ПОВЕДЕНИЕ

Официальный форум для разработки perl - это список рассылки perl5-porters,
упомянутого выше, и его багтрекера на rt.perl.org. Все участники обсуждения есть
ожидается, что они будут придерживаться стандарта поведения.

· Всегда будьте вежливы.

· Прислушивайтесь к модераторам.

Вежливость проста: придерживайтесь фактов, избегая при этом унизительных замечаний и сарказма. Это
недостаточно, чтобы быть фактическим. Вы также должны быть вежливыми. Реагировать на невежливость - это
недопустимо.

Вежливость требуется, но поощряется доброта; если у вас есть сомнения относительно того,
вы ведете себя вежливо, просто спросите себя: «Я добр?» и стремимся к этому.

Если модераторы списка говорят вам, что вы не ведете себя вежливо, внимательно подумайте, как
слова появились прежде, чем ответить каким-либо образом. Были ли они добрыми? Вы можете протестовать, но
Повторный протест против неоднократно подтвержденного решения не допускается.

Неприемлемое поведение приведет к публичному и четко обозначенному предупреждению. Повторяется
неприемлемое поведение приведет к удалению из списка рассылки и отзыву
права на обновление rt.perl.org. Первое удаление рассчитано на один месяц. Последующие удаления
увеличится вдвое. По истечении шести месяцев без предупреждения срок бана пользователя сбрасывается.
Удаление, как и предупреждения, является публичным.

Список модераторов будет достоянием общественности. В настоящее время это: Аарон Крейн, Энди.
Догерти, Рикардо Синьес, Штеффен Мюллер.

CREDITS

"Общественный договор о распределенных модулях" первоначально Расс Олбери[электронная почта защищена]>
и perl5-портеры.

Используйте perlpolicy онлайн с помощью сервисов onworks.net