Updating in-repo version of Pod::Simple

[Aaron Faanes]

On Mon, Aug 15, 2011 at 2:50 PM, Will Coleda <will at coleda.com> wrote:
> On Mon, Aug 15, 2011 at 3:00 PM, Aaron Faanes <dafrito at gmail.com> wrote:
>> Parroteers! I've been working on closing some long-lived documentation
>> bugs [1][2][3], and I've been wondering about the future of Parrot's
>> Pod::Simple module. The version we currently keep is a bit dated, and
>> it's possible some of these bugs would be fixed by upgrading. I've
>> been considering a few ways of doing this, but I'm not sure which
>> would be the best way:
>>
>> 1. Fix any issues in the module, but otherwise leave it alone.
>> 2. Upgrade Pod::Simple in place. This involves removing our version,
>> putting in the one from the official repo [4].
>> 3. Use a submodule that refers to the official repo directly. This
>> involves a small amount of work to get submodules to behave correctly
>> with Parrot's manifest generation script, but I think I've figured
>> that out.
>> 4. Remove Pod::Simple entirely and depend on users to have it available.
>>
>> For my two cents, solutions 2-4 aren't really safe until it's been
>> determined that Parrot's changes are either duplicated or superseded
>> by the official version. So to check that, I've starting doing #2.
>> This lets me diff the changes between our version and upstream.
>> However, it's a pretty huge diff, so to make it more manageable, I've
>> been pulling apart the changes into semi-logical commits. What I
>> should have at the end of this process is a pull request with a
>> manageable series of commits from our version to upstream's latest.
>> Once I've gotten to that point, I think it will be easier to see
>> whether we can replace it with a submodule or remove it entirely.
>>
>> Thoughts, comments welcome!
>>
>> Footnotes:
>>
>> [1] http://trac.parrot.org/parrot/ticket/558
>> [2] http://trac.parrot.org/parrot/ticket/559
>> [3] http://trac.parrot.org/parrot/ticket/674
>> [4] https://github.com/theory/pod-simple/
>>
>> --
>> Aaron Faanes <dafrito at gmail.com>
>> _______________________________________________
>> http://lists.parrot.org/mailman/listinfo/parrot-dev
>>
>
> Also:
>
> http://trac.parrot.org/parrot/ticket/1175
>
> My vote: rip it out, and declare which 'make' targets actually require
> it. (especially if "make html" is the only thing that needs it)
>
> --
> Will "Coke" Coleda

Yeah, I'd also prefer for it to be removed entirely. However, reading
the ticket you linked ( and another
http://trac.parrot.org/parrot/ticket/1878 ) makes it seem like we
should keep it around in some form, to support old versions of Perl
that don't have it in core.

I've completed generating my update branch, as described in #2, and it
looks like there's no significant Parrot-specific deviations. I'll be
issuing pull requests so they can be reviewed. If my claim is
confirmed, we could remove it and use a submodule instead. A submodule
would keep it in-repo, but would make it read-only - it would be tied
to a specific upstream revision and could be imported using git.
Submodule behavior lets us indicate explicitly why we've included it
and how we would like the underlying code changed.

More information on my generated branches will be included in Github
pull requests.

-- 
Aaron Faanes <dafrito at gmail.com>