<div dir="ltr">I'm with you 100% there. Whatever we do it should be properly planned. Let me dig though and put together a draft.<div><br></div><div>Mark</div></div><div class="gmail_extra"><br clear="all"><div>—Mark<br>
_______________________<br>Mark E. Anderson <<a href="mailto:emer@emer.net" target="_blank">emer@emer.net</a>><br></div>
<br><br><div class="gmail_quote">On Fri, Apr 4, 2014 at 7:08 PM, Joshua Root <span dir="ltr"><<a href="mailto:jmr@macports.org" target="_blank">jmr@macports.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">On 2014-4-5 07:24 , Daniel J. Luke wrote:<br>
> On Apr 4, 2014, at 1:20 PM, Mark Anderson <<a href="mailto:emer@emer.net">emer@emer.net</a>> wrote:<br>
>><br>
>> 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.<br>
><br>
> do you have anything where someone can look at it?<br>
><br>
> I'd be interested in helping make things better...<br>
><br>
>> 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.<br>
><br>
> 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.<br>
<br>
</div>I don't really care what we do with perl as long as it works. I've done<br>
way more work on the perl ports than I ever wanted to, simply because<br>
they were broken and stopping other stuff from working.<br>
<br>
There were some changes to perl begun in late 2008 that apparently<br>
weren't completely planned out and never really got finished. A lot of<br>
the subsequent work was attempting to fix that mess. So let's not have a<br>
repeat of that. Whatever we do, let's figure out where we're going<br>
before we start making changes, think through the impact on users and<br>
how to minimise it, and make the changes all at once when they're ready<br>
(ideally in a single commit).<br>
<br>
- Josh<br>
</blockquote></div><br></div>