| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Sorry, everybody: I no longer have time to keep up with the list, and it's
therefore unreasonable to claim I can do an adequate job of moderation.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Substantive changes:
Firstly, as promised earlier, we have clarified that, by forwarding a
message to the list, the sender takes responsibility for the content of the
message in question.
Secondly, we have changed the policy regarding ban lengths. Previously,
third or subsequent instances of unacceptable behaviour resulted in a ban
twice the length of the person's previous ban. Under the new policy, a third
instance of unacceptable behaviour results in a further warning, and a
fourth instance results in a ban of indefinite length.
Our rationale is that temporary bans are for the offender: to give them the
opportunity to change their behaviour in a way that aligns with our
community expectations. However, if the person in question fails to take
advantage of that opportunity, our focus must shift to the community: we aim
to protect other list members from having to bear the burden of unacceptable
behaviour.
Finally, we welcome Karen Etheridge and Todd Rinaldo as additional
moderators. I'd like to offer both Karen and Todd my personal thanks for
agreeing to serve.
|
|
|
|
|
|
|
|
| |
The maint-votes branch has been used for some time now to keep track of
which commits should be cherry-picked into maint branches, but this has
never been mentioned in perlpolicy.pod. Document it now to avoid possible
confusion -- especially during long maint branch freeze periods, which
occurred recently.
|
| |
|
| |
|
|
|
|
|
|
| |
Point out that the security-reporting email address now creates an RT
ticket. Also, consolidate this information purely within perlsec.pod, and
make all the other places link to it with L<>.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As (Steve Hay)++ said on-list:
I think it's a shame if users get a 5.X.0 release with some shiny new
features which I hope they're excited about and start making use of,
but then find bugs in those features and have to wait until 5.X+2.0,
rather than 5.X.1, for fixes.
rjbs++ clarified that, although such changes constitute a break in backwards
compatibility, there are two reasons why bugs in new features should be
fixed in maint:
* they delay people from using a feature for a year, because it does
something stupid
* they risk enshrining bad behavior under the usual program of bugward
compatibility
|
|
|
|
|
|
| |
Suggestion that we "aspire to kindness" from the ever-kind Tim Bunce.
Signed-off-by: Ricardo Signes <rjbs@cpan.org>
|
| |
|
|
|
|
|
| |
Again, this is just a statement of the reality that I have experienced in
the course of releasing 5.20.1 and 5.20.2.
|
|
|
|
|
| |
This simply reflects the reality of how 5.20.2's changes were voted on,
namely, by the use of the maint-5.20-votes branch.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This phrase caused much debate during the release of 5.20.2. A literal
interpretation of it would be just a version bump, which was clearly not
its intention. Debate ensued as to what was its real meaning, and the
consensus seemed to be that the list of "acceptable"/"unacceptable" types
of change was about right, but that not every eligible change should be
included. Not many committers are interested in reviewing a long list of
minor spelling corrections etc, causing a lack of interest in voting, and
an attendant risk of something important being missed amongst all the
"noise". The focus should mainly be on security / crash / regression /
installation issues, with the aim being to produce a worthwhile release
without needlessly increasing risk and/or burning people out. I hope the
new wording captures this.
|
|
|
|
|
|
|
|
|
| |
The point was also raised during discussions over whether to include
perlunicook.pod in 5.20.2 that exceptions can be made to the rules under
the terms of "Rule 2" and the fact that the pumpking is acting on Larry's
behalf. However, this is probably best left being implicit, rather than
explicitly stating it. Exceptions should be exceptional; we don't want to
encourage them!
|
| |
|
|
|
|
| |
Also clarify a what kind of build/installation "issue" we are referring to.
|
| |
|
| |
|
| |
|
|
|
|
| |
This commit makes no changes to any of the wording.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
see http://nntp.perl.org/group/perl.perl5.porters/219866
|
|
|
|
|
| |
This new wording states explicitly what has been the de facto under-
standing of this policy of late.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Changes like 31114fe991, which has just been cherry-picked into maint-5.20,
should be allowed.
|
| |
|
| |
|
|
|
|
| |
Update perlpolicy to reflect the current policy,
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Also state explicitly that 5.10.1 and earlier are now out of support.
|