From @jkeenan

Created by @jkeenan

Once perl-5.26.0 has been released (May 2017), consider removing
B​::Debug from the
core distribution. It is strictly a development tool and a better
alternative, B​::Concise, is already available in core.

Per suggestion by Reini Urban in​:

https://rt.cpan.org/Ticket/Display.html?id=118391#txn-1676817

And per discussion in​:

https://rt-archive.perl.org/perl5/Ticket/Display.html?id=129821#txn-1438864

https://rt-archive.perl.org/perl5/Ticket/Display.html?id=129821#txn-1439103

Flags:
     category=library
     severity=wishlist
     module=B::Debug

Site configuration information for perl 5.24.0:

Configured by jkeenan at Mon May  9 18:37:23 EDT 2016.

Summary of my perl5 (revision 5 version 24 subversion 0) configuration:

[snip: not relevant]

From @jkeenan

On Mon, 26 Dec 2016 19​:17​:40 GMT, jkeen@​verizon.net wrote​:

This is a bug report for perl from jkeenan@​cpan.org,
generated with the help of perlbug 1.40 running under perl 5.24.0.

-----------------------------------------------------------------
[Please describe your issue here]

Once perl-5.26.0 has been released (May 2017), consider removing
B​::Debug from the
core distribution. It is strictly a development tool and a better
alternative, B​::Concise, is already available in core.

Per suggestion by Reini Urban in​:

https://rt.cpan.org/Ticket/Display.html?id=118391#txn-1676817

And per discussion in​:

https://rt-archive.perl.org/perl5/Ticket/Display.html?id=129821#txn-1438864

https://rt-archive.perl.org/perl5/Ticket/Display.html?id=129821#txn-1439103

With the release of perl-5.26.0, this ticket is now open for discussion.

--
James E Keenan (jkeenan@​cpan.org)

The RT System itself - Status changed from 'new' to 'open'

From @jkeenan

On Thu, 01 Jun 2017 14​:14​:11 GMT, jkeenan wrote​:

On Mon, 26 Dec 2016 19​:17​:40 GMT, jkeen@​verizon.net wrote​:

This is a bug report for perl from jkeenan@​cpan.org,
generated with the help of perlbug 1.40 running under perl 5.24.0.

-----------------------------------------------------------------
[Please describe your issue here]

Once perl-5.26.0 has been released (May 2017), consider removing
B​::Debug from the
core distribution. It is strictly a development tool and a better
alternative, B​::Concise, is already available in core.

Per suggestion by Reini Urban in​:

https://rt.cpan.org/Ticket/Display.html?id=118391#txn-1676817

And per discussion in​:

https://rt-archive.perl.org/perl5/Ticket/Display.html?id=129821#txn-1438864

https://rt-archive.perl.org/perl5/Ticket/Display.html?id=129821#txn-1439103

With the release of perl-5.26.0, this ticket is now open for discussion.

Shall we remove B​::Debug from core per discussion in other tickets? Please discuss. Thanks.

--
James E Keenan (jkeenan@​cpan.org)

From @iabyn

On Sun, Jul 23, 2017 at 01​:16​:04PM -0700, James E Keenan via RT wrote​:

On Thu, 01 Jun 2017 14​:14​:11 GMT, jkeenan wrote​:

On Mon, 26 Dec 2016 19​:17​:40 GMT, jkeen@​verizon.net wrote​:

This is a bug report for perl from jkeenan@​cpan.org,
generated with the help of perlbug 1.40 running under perl 5.24.0.

-----------------------------------------------------------------
[Please describe your issue here]

Once perl-5.26.0 has been released (May 2017), consider removing
B​::Debug from the
core distribution. It is strictly a development tool and a better
alternative, B​::Concise, is already available in core.

Per suggestion by Reini Urban in​:

https://rt.cpan.org/Ticket/Display.html?id=118391#txn-1676817

And per discussion in​:

https://rt-archive.perl.org/perl5/Ticket/Display.html?id=129821#txn-1438864

https://rt-archive.perl.org/perl5/Ticket/Display.html?id=129821#txn-1439103

With the release of perl-5.26.0, this ticket is now open for discussion.

Shall we remove B​::Debug from core per discussion in other tickets?

Yes.

--
Please note that ash-trays are provided for the use of smokers,
whereas the floor is provided for the use of all patrons.
  -- Bill Royston

From @karenetheridge

On Sun, 23 Jul 2017 13​:16​:03 -0700, jkeenan wrote​:

Shall we remove B​::Debug from core per discussion in other tickets?
Please discuss. Thanks.

+1 from me.

From @xsawyerx

On 07/24/2017 06​:57 PM, Karen Etheridge via RT wrote​:

On Sun, 23 Jul 2017 13​:16​:03 -0700, jkeenan wrote​:

Shall we remove B​::Debug from core per discussion in other tickets?
Please discuss. Thanks.
+1 from me.

+2.

From @jkeenan

Removed in commit ecfa068

CommitDate​: Tue Jul 25 07​:18​:22 2017

--
James E Keenan (jkeenan@​cpan.org)

@jkeenan - Status changed from 'open' to 'resolved'

From @ilmari

"James E Keenan via RT" <perlbug-followup@​perl.org> writes​:

Removed in commit ecfa068

CommitDate​: Tue Jul 25 07​:18​:22 this

This is not how perlpolicy says to remove modules​: they need a
deprecation period of at least one stable relase​:

  If something in the Perl core is marked as deprecated, we may
  remove it from the core in the future, though we might
  not. Generally, backward incompatible changes will have
  deprecation warnings for two release cycles before being
  removed, but may be removed after just one cycle if the risk
  seems quite low or the benefits quite high.

  As of Perl 5.12, deprecated features and modules warn the user
  as they're used. When a module is deprecated, it will also be
  made available on CPAN. Installing it from CPAN will silence
  deprecation warnings for that module.

So this should be reverted, and the module changed upstream to include

  use if "$]" >= 5.027003 deprecate.pm;

and that version should be imported into core.

- ilmari
--
"I use RMS as a guide in the same way that a boat captain would use
a lighthouse. It's good to know where it is, but you generally
don't want to find yourself in the same spot." - Tollef Fog Heen

From @ilmari

ilmari@​ilmari.org (Dagfinn Ilmari Mannsåker) writes​:

So this should be reverted, and the module changed upstream to include

use if "$\]" >= 5\.027003 deprecate\.pm;

Or, the actually valid variant​:

  use if "$]" >= 5.025003, 'deprecate';

- ilmari
--
"A disappointingly low fraction of the human race is,
at any given time, on fire." - Stig Sandbeck Mathisen

@jkeenan - Status changed from 'resolved' to 'open'

From @xsawyerx

On 07/25/2017 02​:02 PM, Dagfinn Ilmari Mannsåker wrote​:

"James E Keenan via RT" <perlbug-followup@​perl.org> writes​:

Removed in commit ecfa068

CommitDate​: Tue Jul 25 07​:18​:22 this
This is not how perlpolicy says to remove modules​: they need a
deprecation period of at least one stable relase​:

If something in the Perl core is marked as deprecated\, we may
remove it from the core in the future\, though we might
not\. Generally\, backward incompatible changes will have
deprecation warnings for two release cycles before being
removed\, but may be removed after just one cycle if the risk
seems quite low or the benefits quite high\.

As of Perl 5\.12\, deprecated features and modules warn the user
as they're used\. When a module is deprecated\, it will also be
made available on CPAN\. Installing it from CPAN will silence
deprecation warnings for that module\.

This is correct. We cannot simply delete it. We will need to deprecate
it for at least one cycle. I'm in favor of removing in 5.30, which also
seems to match Reini's decision.

I think the word "remove" was ambiguous in this thread and implied
deleting. Sorry about that, Jim.

From @jkeenan

On Wed, 26 Jul 2017 08​:58​:04 GMT, xsawyerx@​gmail.com wrote​:

On 07/25/2017 02​:02 PM, Dagfinn Ilmari Mannsåker wrote​:

"James E Keenan via RT" <perlbug-followup@​perl.org> writes​:

Removed in commit ecfa068

CommitDate​: Tue Jul 25 07​:18​:22 this
This is not how perlpolicy says to remove modules​: they need a
deprecation period of at least one stable relase​:

If something in the Perl core is marked as deprecated\, we may
remove it from the core in the future\, though we might
not\. Generally\, backward incompatible changes will have
deprecation warnings for two release cycles before being
removed\, but may be removed after just one cycle if the risk
seems quite low or the benefits quite high\.

As of Perl 5\.12\, deprecated features and modules warn the user
as they're used\. When a module is deprecated\, it will also be
made available on CPAN\. Installing it from CPAN will silence
deprecation warnings for that module\.

This is correct. We cannot simply delete it. We will need to deprecate
it for at least one cycle. I'm in favor of removing in 5.30, which also
seems to match Reini's decision.

I think the word "remove" was ambiguous in this thread and implied
deleting. Sorry about that, Jim.

Okay, can you let us know when it is *officially* deprecated? At that point we'll change this ticket's subject and links to reflect scheduled removal in 5.30 (spring 2019).

Thank you very much.

--
James E Keenan (jkeenan@​cpan.org)

From @xsawyerx

On 07/27/2017 12​:57 AM, James E Keenan via RT wrote​:

On Wed, 26 Jul 2017 08​:58​:04 GMT, xsawyerx@​gmail.com wrote​:

On 07/25/2017 02​:02 PM, Dagfinn Ilmari Mannsåker wrote​:

"James E Keenan via RT" <perlbug-followup@​perl.org> writes​:

Removed in commit ecfa068

CommitDate​: Tue Jul 25 07​:18​:22 this
This is not how perlpolicy says to remove modules​: they need a
deprecation period of at least one stable relase​:

If something in the Perl core is marked as deprecated\, we may
remove it from the core in the future\, though we might
not\. Generally\, backward incompatible changes will have
deprecation warnings for two release cycles before being
removed\, but may be removed after just one cycle if the risk
seems quite low or the benefits quite high\.

As of Perl 5\.12\, deprecated features and modules warn the user
as they're used\. When a module is deprecated\, it will also be
made available on CPAN\. Installing it from CPAN will silence
deprecation warnings for that module\.

This is correct. We cannot simply delete it. We will need to deprecate
it for at least one cycle. I'm in favor of removing in 5.30, which also
seems to match Reini's decision.

I think the word "remove" was ambiguous in this thread and implied
deleting. Sorry about that, Jim.
Okay, can you let us know when it is *officially* deprecated?

It is now officially deprecated.

At that point we'll change this ticket's subject and links to reflect scheduled removal in 5.30 (spring 2019).

Yes, please.

From @ilmari

Sawyer X <xsawyerx@​gmail.com> writes​:

On 07/27/2017 12​:57 AM, James E Keenan via RT wrote​:

On Wed, 26 Jul 2017 08​:58​:04 GMT, xsawyerx@​gmail.com wrote​:

I think the word "remove" was ambiguous in this thread and implied
deleting. Sorry about that, Jim.

Okay, can you let us know when it is *officially* deprecated?

It is now officially deprecated.

And I've now pulled in version 1.25 from CPAN (commit 0283ad9), which
issues the deprecation warning.

At that point we'll change this ticket's subject and links to reflect
scheduled removal in 5.30 (spring 2019).

Yes, please.

Go ahead.

--
- Twitter seems more influential [than blogs] in the 'gets reported in
  the mainstream press' sense at least. - Matt McLeod
- That'd be because the content of a tweet is easier to condense down
  to a mainstream media article. - Calle Dybedahl

From @jkeenan

On Thu, 27 Jul 2017 08​:06​:04 GMT, xsawyerx@​gmail.com wrote​:

On 07/27/2017 12​:57 AM, James E Keenan via RT wrote​:

On Wed, 26 Jul 2017 08​:58​:04 GMT, xsawyerx@​gmail.com wrote​:

On 07/25/2017 02​:02 PM, Dagfinn Ilmari Mannsåker wrote​:

"James E Keenan via RT" <perlbug-followup@​perl.org> writes​:

Removed in commit ecfa068

CommitDate​: Tue Jul 25 07​:18​:22 this
This is not how perlpolicy says to remove modules​: they need a
deprecation period of at least one stable relase​:

If something in the Perl core is marked as deprecated, we may
remove it from the core in the future, though we might
not. Generally, backward incompatible changes will have
deprecation warnings for two release cycles before being
removed, but may be removed after just one cycle if the risk
seems quite low or the benefits quite high.

As of Perl 5.12, deprecated features and modules warn the user
as they're used. When a module is deprecated, it will also be
made available on CPAN. Installing it from CPAN will silence
deprecation warnings for that module.

This is correct. We cannot simply delete it. We will need to
deprecate
it for at least one cycle. I'm in favor of removing in 5.30, which
also
seems to match Reini's decision.

I think the word "remove" was ambiguous in this thread and implied
deleting. Sorry about that, Jim.
Okay, can you let us know when it is *officially* deprecated?

It is now officially deprecated.

At that point we'll change this ticket's subject and links to reflect
scheduled removal in 5.30 (spring 2019).

Yes, please.

I have re-implemented the removal of B​::Debug from the Perl 5 core distribution. This work is currently in this branch​:

smoke-me/jkeenan/130410-remove-b-debug

Since this is one of the items on our list of blockers for perl-5.30 (https://rt-archive.perl.org/perl5/Ticket/Display.html?id=131806), unless we hear objections I will merge this into blead as soon as the smoke testers have processed it, i.e., in a week or sooner.

Thank you very much.

--
James E Keenan (jkeenan@​cpan.org)

From @jkeenan

On Sun, 23 Sep 2018 21​:35​:05 GMT, jkeenan wrote​:

On Thu, 27 Jul 2017 08​:06​:04 GMT, xsawyerx@​gmail.com wrote​:

On 07/27/2017 12​:57 AM, James E Keenan via RT wrote​:

On Wed, 26 Jul 2017 08​:58​:04 GMT, xsawyerx@​gmail.com wrote​:

On 07/25/2017 02​:02 PM, Dagfinn Ilmari Mannsåker wrote​:

"James E Keenan via RT" <perlbug-followup@​perl.org> writes​:

Removed in commit ecfa068

CommitDate​: Tue Jul 25 07​:18​:22 this
This is not how perlpolicy says to remove modules​: they need a
deprecation period of at least one stable relase​:

If something in the Perl core is marked as deprecated, we may
remove it from the core in the future, though we might
not. Generally, backward incompatible changes will have
deprecation warnings for two release cycles before being
removed, but may be removed after just one cycle if the risk
seems quite low or the benefits quite high.

As of Perl 5.12, deprecated features and modules warn the user
as they're used. When a module is deprecated, it will also be
made available on CPAN. Installing it from CPAN will silence
deprecation warnings for that module.

This is correct. We cannot simply delete it. We will need to
deprecate
it for at least one cycle. I'm in favor of removing in 5.30, which
also
seems to match Reini's decision.

I think the word "remove" was ambiguous in this thread and implied
deleting. Sorry about that, Jim.
Okay, can you let us know when it is *officially* deprecated?

It is now officially deprecated.

At that point we'll change this ticket's subject and links to
reflect
scheduled removal in 5.30 (spring 2019).

Yes, please.

I have re-implemented the removal of B​::Debug from the Perl 5 core
distribution. This work is currently in this branch​:

smoke-me/jkeenan/130410-remove-b-debug

Since this is one of the items on our list of blockers for perl-5.30
(https://rt-archive.perl.org/perl5/Ticket/Display.html?id=131806), unless we hear
objections I will merge this into blead as soon as the smoke testers
have processed it, i.e., in a week or sooner.

Thank you very much.

Smoke reports on this branch at http​://perl.develop-help.com/?b=smoke-me%2Fjkeenan%2F130410-remove-b-debug are looking fine. The only failures are on rigs which are also reporting failures on blead.

Merged into blead in commit 903b110 and resolving ticket.

Thank you very much.

--
James E Keenan (jkeenan@​cpan.org)

@jkeenan - Status changed from 'open' to 'resolved'