Perl changes (+ please wait a bit with commits in perl modules if possible)

[Craig Treleaven]

At 8:32 AM -0700 8/12/14, David Evans wrote:
>On 8/12/14 8:23 AM, Ryan Schmidt wrote:
>>>  On Aug 12, 2014, at 10:20 AM, David Evans <devans at macports.org> wrote:
>>>
>>>  On 8/12/14 8:06 AM, Ryan Schmidt wrote:
>>>>  On Aug 12, 2014, at 9:56 AM, Mojca Miklavec <mojca at macports.org> wrote:
>>>>>  Now about 5.8-5.16: my idea was to initially set the INC path for
>>>>>  those versions in such a way that it would include
>>>>>  "5.16.3/darwin-thread-multi-2level 5.16.3
>>>>>  5.16.1/darwin-thread-multi-2level 5.16.1
>>>>>  5.16.0/darwin-thread-multi-2level 5.16.0" as well as the "plain"
>>>>>  <something>/5.16/<something> without the subrelease. That means that
>>>>>  there would initially be no urgent need to revbump all the > 1000
>>>>>  ports. (On the contrary 5.20 doesn't need any change and for 5.18 I
>>>>>  would make sure to revbump all p5.18-foo ports.)
>>>>>
>>>>>  But I'm unable to figure out how to patch Perl to do that. The INC
>>>>>  path additions seem to be ignored.
>>>>  Why handle <= 5.16 differently than >= 5.18?
>>>>
>>>>
>>>  Because we want them to go away? Or is the effort to do them all
>>>  relatively trivial?
>>>
>>>
>>  My assumption was that since a patch is already in place for 
>>perl5.20 and perl5.18 it could be backported to earlier versions 
>>with minimal effort, and that since Mojca plans a revbump of all 
>>perl modules anyway, before that mass revbumping would be the ideal 
>>time to do that.
>>
>>
>Agreed.  If the effort is trivial it doesn't make much difference.  But
>if we want to drop some branches then why bother with them?  For
>instance, IMO we could drop 5.8 and 5.10.  And 5.12 as soon as the
>remaining ports that depend on it are fixed.  Then 5.14.  I don't think
>we can get rid of 5.16 until either 5.18 5.20 or both have the same
>coverage and we're ready to switch to a new default.
>
>But again this depends on where we are going?
>
>Ryan, as a member of the executive branch ;-), do you have a method to
>come up with a final decision on the direction for perl?  I think it's
>all been discussed more than enough.

Is there data coming in through mpstats that could help with this 
decision?  What is the distribution of perl installs by version?

Craig