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

[David Evans]

On 8/12/14 7:56 AM, Mojca Miklavec wrote:
> On Tue, Aug 12, 2014 at 4:43 PM, David Evans wrote:
>> I'd be happy to help with this.  It's true that many ports are outdated
>> version-wise (even ones that have already been ported to p5.20)
>> and my recent experience suggests that many need updated
>> dependencies as well.
>>
>> To make things manageable, I would suggest limiting your initial changes in
>> a test branch to just your patches to the perl ports themselves
> Those are trivial.
>
>> and the
>> required rev bumps.
> That's all the > 300 ports. For all of those 300 (except for those
> added in the last few days) I actually checked for updates and already
> updated them instead of doing a revbump.
>
>> Getting everything up to date, 5.18, 5.20, etc can
>> then be handled as a separate process.
> Yes, I would do that later. But if people add 5.18 now, all those
> ports need to be revbumped as well.
>
> 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.
>
>> When testing has been completed and everyone is happy then you just
>> need to merge the then content of trunk to test and update your rev bumps
>> as necessary.  A tool to compare trunk versions to test versions would help
>> at this point. Then merge back to trunk, make a final check and commit.
>> No need to freeze trunk until you are ready to take these final steps.
>>
>> Again, I'd be glad to work with you to share the load both in merging and
>> testing and I'm sure there are others interested in perl who could help
>> as well.
> I will upload something today and/or create a branch.
>
> (But I really hate doing the merging.)
>
> Mojca
>
Given Daniel's input along with your comments,  looks like we need to stand
back for a second, see what's been done already, where we are going and
decide the steps to get there as a group.

The problems with people making changes behind your back can be minimized
by publishing what you are doing and asking people that want to make updates
to make them to trunk and to the test branch as well. 

But for the moment, I suggest that you commit all your proposed changes to
a new test branch so that it is more apparent where things stand.

As Daniel has said, no point in changing things that are going to go away so
we need to get a consensus on where we want to go with this.  My input here
would be this:

*  make the necessary changes to perl5.18 to work as perl5.20 does
*  leave perl5.16 and lower alone for now
*  update ports to support p5.18 & 5.20 unless there is strong sentiment
to go to 5.20 ASAP.
   not much difference in adding one or two new branches
*  then decided which branches to remove, go to single perl (which has
other consequences), etc.