Noticing Perl stuff along the wire again

Eric Gallager egall at
Fri Apr 4 16:55:57 PDT 2014

How about making a separate "perl5-rewrite" branch in subversion, working
on the draft in that branch, and then merging that once it is ready? That
would still technically meet jmr's "ideally in a single commit" criterion,
as the only commit to trunk would be the merge from the other branch.

On Fri, Apr 4, 2014 at 7:11 PM, Mark Anderson <emer at> wrote:

> I'm with you 100% there. Whatever we do it should be properly planned. Let
> me dig though and put together a draft.
> Mark
> --Mark
> _______________________
> Mark E. Anderson <emer at>
> On Fri, Apr 4, 2014 at 7:08 PM, Joshua Root <jmr at> wrote:
>> On 2014-4-5 07:24 , Daniel J. Luke wrote:
>> > On Apr 4, 2014, at 1:20 PM, Mark Anderson <emer at> wrote:
>> >>
>> >> I know we've argued about this time and time again, but Perl issues
>> are coming back up it seems. I've started work - admittedly not getting
>> very far on the cpan-mp idea. I'm still trying to figure out /base to be
>> honest and brush off my Perl-XS skills.
>> >
>> > do you have anything where someone can look at it?
>> >
>> > I'd be interested in helping make things better...
>> >
>> >> I feel like we have had this argument again and again, and I'm loathe
>> to start this argument again, but at what point are we going to pull the
>> trigger on keeping one perl, deciding to drop old Perls, that kind of
>> thing. I can put together a proposal and drop it on the wiki - if that will
>> make things easier to decide/pick apart.
>> >
>> > A wiki page might be a good idea - it seems like there are a few people
>> who are strongly opposed to that general plan (keeping just one good perl),
>> and that there's been enough inertia to keep things from changing.
>> I don't really care what we do with perl as long as it works. I've done
>> way more work on the perl ports than I ever wanted to, simply because
>> they were broken and stopping other stuff from working.
>> There were some changes to perl begun in late 2008 that apparently
>> weren't completely planned out and never really got finished. A lot of
>> the subsequent work was attempting to fix that mess. So let's not have a
>> repeat of that. Whatever we do, let's figure out where we're going
>> before we start making changes, think through the impact on users and
>> how to minimise it, and make the changes all at once when they're ready
>> (ideally in a single commit).
>> - Josh
> _______________________________________________
> macports-dev mailing list
> macports-dev at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the macports-dev mailing list