Re: no deprecation warning for L<section>

On Sun, May 01, 2011 at 10:34:08AM +0100, Nicholas Clark wrote:
> On Sat, Apr 30, 2011 at 05:31:00PM +0100, Michael Stevens wrote:
> > On Fri, Apr 29, 2011 at 08:58:37AM -0600, Karl Williamson wrote:
> > > People on this list might be interested in the extensions to  
> > > Pod::Checker, some of which might be considered for pulling back into  
> > > Pod::Checker.  Attached is the current pod for podcheck.t
> > 
> > I have things I'd like to change in Pod::Checker, but it seems to be
> > considered untouchable until the move to Pod::Simple.
> 
> It somewhat is, as a side effect of the attempt at having a consistent policy
> on what is upstream.
> 
> Pod::Checker is part of the Pod-Parser distribution.
> The core's "who owns what" file, Porting/Maintainers.pl, says that Pod-Parser
> isn't maintained in core, and that upstream is MAREKR.
> MAREKR says that is (well), effectively dead.
> 
> So the core policy works out as "send patches to MAREKR" and MAREKR's policy
> works out as "no thanks". Which isn't exactly ideal.
> 
> 
> At which point, the two obvious routes forward to resolve this are either
> 
> a: move to maintaining Pod-Parser as part of the core
> 
> or
> 
> b: more to eliminating the need for Pod-Parser
> 
> 
> and the consensus seems to be that (b) is far less insane. I think that what's
> then gone "wrong" is that no-one wants to start on it, but given that it is
> the future, everyone thinks that doing anything in the direction of (a) is a
> waste of effort.
> 
> Which stalls.

Assuming I didn't get my branches mixed up,
https://github.com/mstevens/pod-simple/tree/topic/podchecker

is a quick hack in the direction of backending podchecker on
Pod::Simple, which works as far as I tested it on one .pod file.

The bit I found stalls is where you have to work out how to reconcile
the way Pod::Checker behaved and the way Pod::Simple behaves, it's hard
to get people to make decisions.

Michael