Front page | perl.perl5.porters |
Postings from January 2009
January 5, 2009 06:09
Message ID: email@example.com
2009/1/5 Sam Vilain <firstname.lastname@example.org>:
> Andreas J. Koenig wrote:
>> > I'm going to take over the Git.pm module; the module that comes with
>> git. I > welcome all input from my fellow perl developers.
>> Upload to CPAN?
> Posting a patch to Git.pm via the git mailing list is a far superior process
> to making a CPAN release; it allows the code to be reviewed in far greater
> detail by a larger number of eyeballs.
> I suggest that playing along with the Git community and sending all changes
> to the Git list for inclusion rather than arbitrarily insisting it live on
> CPAN would be the best approach. Of course it can be "dual lifed" as
> happens with core modules, except the "Core" in this case is actually
I agree that dual lifing the module would be fine. And i agree that
patches to Git.pm should go to the git list.
Whats not so clear to me is whether a new git framework should be
staged out of git.git.
And I personally feel there is a good case for writing a complete new
framework, especially if the new framework can be a) git version
independent (a good reason not to put in git.git), and b) capable of
being used to reimplement Git.pm as a wrapper.
Git.pm as it lives in git.git has the problem as far as i can tell of
being bound to the installed version of git, which means that you
can't use it to implement a workaround layer to make tools version
independent. You essentially have to mandate a dependency on a version
of git that you may not be able to change, where you would be able to
upgrade the perl framework.
Perhaps this is really a case for two layers, that abstract things
from either end. On one end you have the git.git controlled stuff,
which allows them to do what they want, and on the other you have a
CPAN based abstraction layer that makes it possible to work with any
(reasonable) version of git.
perl -Mre=debug -e "/just|another|perl|hacker/"