Front page | perl.perl5.porters |
Postings from June 2011
Re: [PATCH] export store_cop_label
Thread Previous
|
Thread Next
From:
Nicholas Clark
Date:
June 13, 2011 13:30
Subject:
Re: [PATCH] export store_cop_label
Message ID:
20110613203041.GZ23881@plum.flirble.org
On Mon, Jun 13, 2011 at 01:13:38PM -0700, Jan Dubois wrote:
> On Mon, 13 Jun 2011, Jim Cromie wrote:
> > On Mon, Jun 13, 2011 at 1:18 PM, Todd Rinaldo <toddr@cpanel.net> wrote:
> > > I believe your patch to make these public was considered
> > > insufficient because the items were not documented along side
> > > making them public again. As I read it, this is what needs to be
> > > stepped up on.
> > >
> > > We're just talking about some POD here right?
> > >
> >
> > probly some XS-APITest additions too
>
> No need to guess, you could have checked Reini's original submission.
> Tests and docs are all there:
>
> https://github.com/rurban/perl/commit/3691eaa79cc6a196b6a424b4c7abc6c8f5a481e2
>
> 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
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.
If someone else is confident to review whether the API for this is sane faster
than I can, great.
[I can think of 3 or 4 people who've previously done a good job of picking
holes in things I've suggested or already implemented, but I don't want to
dump any of them in it by "volunteering" them.]
But even if someone else does go "yes, it's sane" or "not quite, this would
be better", it still doesn't make 5.16.0 happen any faster.
(And the current release policy, for all its seeming excessive restrictions,
is actually going to deliver 5.16.0 sooner after 5.14.0 than 5.10.1 was after
5.10.0, 5.8.1 was after 5.8.0, or 5.6.1 was after 5.6.0. Evidence is that it's
working better than what we used to have, so I'm wary of trying to fix it)
Nicholas Clark
Thread Previous
|
Thread Next