Front page | perl.perl5.porters |
Postings from June 2011
Re: [PATCH] export store_cop_label
Thread Previous
|
Thread Next
From:
Reini Urban
Date:
June 18, 2011 04:25
Subject:
Re: [PATCH] export store_cop_label
Message ID:
BANLkTimPRBbWDEJ4goDH_SMAAjjx0KKJ2g@mail.gmail.com
2011/6/13 Jan Dubois <jand@activestate.com>:
> On Mon, 13 Jun 2011, Nicholas Clark wrote:
>> On Mon, Jun 13, 2011 at 01:13:38PM -0700, Jan Dubois wrote:
>> > The issue (as far as I am concerned) is that none of the porters has "blessed"
>> > the now documented API as something they want to support going forward. Instead
>> > I read that Nicholas has a plan to implement a proper API for this kind of
>> > functionality. So I think we are all waiting for this to happen.
>>
>> What I thought I'd written was that
>>
>> a: I got the impression that there were doubts over whether this was a sane
>> API (to support indefinitely)(I know that fetch_cop_label changed about a
>> year ago - it wasn't "right" the first time)
>> b: If no-one else gets there first, I was intending to look at it
>
> Sorry to put words into your mouth (and thereby kind of volunteering
> you, when you were still hoping for someone else to get to it first). I
> guess I need to increase the font size on my browser/email/IRC client.
>
>> but
>>
>> > Exporting the current symbol in maintenance branches is a completely separate
>> > issue. Personally I don't see a big issue with it, as it can't possibly
>> > break other code; it simply exports an additional symbols that is already
>> > exported on most platforms anyways, although technically this may not be covered
>> > by our maintenance policy. The biggest issues is that it will create
>> > the expectation that the symbol will continue to be exported in newer releases.
>> > This should cease to be a problem once the new API materializes.
>>
>> c: because the current maint policy that Jesse is working to is strict about
>> what can go into a maint branch, and because this change is *not* something
>> that the policy permits, then (on the assumption that the policy isn't going
>> to change) there wasn't an urgency for me to look at it "yesterday", as not
>> looking at this month it does not cause a (further) delay.
>>
>> By the current maint policy, this would be for 5.16.0, not for 5.14.anything.
No, I consider it as a regression to be fixed for 5.12 and 5.14.
COP labels could be written until then,
they where written via the public API in the headers,
and they are broken since the public macro was rewritten as private function.
> Absolutely. I was trying to say that when we have a proper solution for 5.16,
> then there is no longer an expectation that the old symbol would be exported
> as well. Therefore it would do little harm in exporting it as-is in older maint
> versions. I'm just saying it is not *obvious* if this would be allowable
> under the current maint policy; it would essentially be a judgement call by Jesse.
Better an unsane API as a removed API at all.
There was only the vague objection from Nick that it is a new API, he
need to think it over.
I saw no other objections, I see no technical arguments why it "could"
be a bad API and I see
no risks exposing it as there are only two experimental modules using
it, and I am the
maintainer of both. So I can adjust to next changes fast.
Two main releases thinking about it and blocking it hereby is
definitely too long.
The compiler can not be used for windows users for 5.12 and 5.14.
The cygwin package has store_cop_label exported (by emulating the linux policy
-Wl,--export-all-symbols), and I recommend that ActiveState and
strawberry flip this
one-char flag also in their subsequent updates for 5.12 an 5.14.
--
Reini
Thread Previous
|
Thread Next