Skip Menu |
 
rt.cpan.org will be shut down on March 1st, 2021.

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the Perl-Critic CPAN distribution.

Report information
The Basics
Id: 69546
Status: resolved
Priority: 0/
Queue: Perl-Critic

People
Owner: Nobody in particular
Requestors: mschwern [...] cpan.org
SREZIC [...] cpan.org
Cc: srezic [...] iconmobile.com
AdminCc:

Bug Information
Severity: (no value)
Broken in: 1.116
Fixed in: (no value)



Subject: Remove Perl::Critic::Policy::Miscellanea::RequireRcsKeywords
Download (untitled) / with headers
text/plain 298b
This policy is not applicable when using modern version control systems like git. As less people are using outdated version control systems like RCS, CVS, or subversion, I think it's best to remove this policy completely, or at least do not activate it in any perlcritic mode. Regards, Slaven
Subject: Re: [rt.cpan.org #69546] Remove Perl::Critic::Policy::Miscellanea::RequireRcsKeywords
Date: Mon, 18 Jul 2011 09:29:26 -0500
To: bug-Perl-Critic [...] rt.cpan.org
From: Elliot Shank <perl [...] galumph.com>
Download (untitled) / with headers
text/plain 560b
On 7/18/11 8:25 AM, Slaven_Rezic via RT wrote: Show quoted text
> This policy is not applicable when using modern version control systems > like git. As less people are using outdated version control systems like > RCS, CVS, or subversion, I think it's best to remove this policy > completely, or at least do not activate it in any perlcritic mode.
Completely wrong. The fact that git does not support RCS keywords is a missing feature: it can at least support the standard $AUTHOR$ and something like a $GIT-CHECKSUM$ so that you can identify the commit the file came from.
Download (untitled) / with headers
text/plain 969b
On 2011-07-18 10:29:41, clonezone wrote: Show quoted text
> On 7/18/11 8:25 AM, Slaven_Rezic via RT wrote:
> > This policy is not applicable when using modern version control
> systems
> > like git. As less people are using outdated version control systems
> like
> > RCS, CVS, or subversion, I think it's best to remove this policy > > completely, or at least do not activate it in any perlcritic mode.
> > Completely wrong. The fact that git does not support RCS keywords is > a missing feature: it can at least support the standard $AUTHOR$ > and something like a $GIT-CHECKSUM$ so that you can identify the > commit the file came from.
The latter is not possible: the same file contests could be the same in different branches, but in this case the $GIT-CHECKSUM$ would need to change if the user switches between branches. But it's an important feature of git that switching branches is fast, and unchanged files shouldn't be touched at all. Regards, Slaven
Download (untitled) / with headers
text/plain 241b
[...] Hmm, I just looked into PBP p.441, and my copy just tells something about using revision control systems, but not anything about using RCS keywords. So maybe at least the reference to PBP should be removed here. Regards, Slaven
Subject: Re: [rt.cpan.org #69546] Remove Perl::Critic::Policy::Miscellanea::RequireRcsKeywords
Date: Mon, 18 Jul 2011 11:10:09 -0700
To: bug-Perl-Critic [...] rt.cpan.org
From: "Thalhammer, Jeffrey" <jeff [...] imaginative-software.com>
Download (untitled) / with headers
text/plain 781b
On Mon, Jul 18, 2011 at 9:03 AM, Slaven_Rezic via RT < bug-Perl-Critic@rt.cpan.org> wrote: Hmm, I just looked into PBP p.441, and my copy just tells something Show quoted text
> about using revision control systems, but not anything about using RCS > keywords. So maybe at least the reference to PBP should be removed here. >
True, PBP doesn't say anything about *which* revision control system you should use. I conceived this policy as a proxy, just to encourage folks to use *a* revision control system. But I agree that we should consider revising the language to clarify the difference between this policy and the intention of Conway's guideline. If RCS keywords are not applicable in your world, then feel free to disable the policy. We don't expect everyone to adhere to every policy.
Download (untitled) / with headers
text/plain 2.2k
I would vote again for removing this policy and starting fresh. While the policy of requiring a version control system is a good one, the implementation doesn't work well. Furthermore, it mixes up the far more contentious issue of requiring commit IDs in every source file. * It's poorly named. The policy is about making sure the user is using a version control system. That it's checking for RCS keywords is just the mechanism, and not a very good one. The name should reflect the policy, not the mechanism. * It conflates two policies. 1. Use a version control system 2. Have a way to map the file back to a particular commit. These should be separate. 2 is difficult in many version control systems, if not impossible, and is far less important than having a version control system. * The mechanism of detection is invasive. There are far better ways of detecting if a project is under version control than requiring the author to pepper every document with keywords. If you want the author to use keywords, make it a separate policy. * It generates a very high rate of false negatives. If you're using anything but CVS or Subversion you're out of luck or have to turn on emulation just to satisfy the policy. It will only get worse. While perlcritic is primarily a file-based beast, and only deals with reading the code, for this one to work it must look outside the file. Either for... * a `.blah` directory in the cwd or above This covers SVN, git and most of the rest of the version control systems introduced in the last five/ten years. * a corresponding `,v` file RCS * run a command CVS and SVK As an alternative, rather than Perl::Critic trying to guess what VCS the project is using, the new RequireVCS policy would warn unless .perlcritic has been configured with what VCS is in use. Then it could choose an appropriate method of checking. It could also be configured with the path to the proper program to run, rather than grovelling up the directory tree looking for .blah directories. A resurrected RequireVcsKeywords would also key off this information (rather than having it told redundantly). It would then check for VCS keywords appropriately, which includes not requiring them at all if your VCS doesn't support them. RequireVCS could be given a higher priority and RequireVcsKeywords a lower one.
Download (untitled) / with headers
text/plain 141b
I have begun work on Miscellanea::RequireVcs. Help and comments very welcome! https://github.com/schwern/Perl-Critic/tree/feature/RequireVcs
Subject: Re: [rt.cpan.org #69546] Remove Perl::Critic::Policy::Miscellanea::RequireRcsKeywords
Date: Wed, 22 Feb 2012 20:44:58 -0800
To: bug-Perl-Critic [...] rt.cpan.org
From: Jeffrey Thalhammer <jeff [...] imaginative-software.com>
Download (untitled) / with headers
text/plain 2.8k
On Feb 22, 2012, at 1:03 PM, Michael G Schwern via RT wrote: Show quoted text
> Queue: Perl-Critic > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=69546 > > > I would vote again for removing this policy and starting fresh... > > * It's poorly named. > * It conflates two policies.
Well, I don't entirely agree with those statements. But I do agree that the Policy doesn't actually enforce the best-practice that Conway is espousing. And yes, I think we can do better here. Show quoted text
> While perlcritic is primarily a file-based beast, and only deals with > reading the code, for this one to work it must look outside the file. > Either for...
Looking for artifacts of a VCS system is good. But I think actually checking if the file is under version control is even better. Basically, do the moral equivalent of "svn stat $file" using the appropriate VCS tool. Either way, it implies that this Policy will only be applied to files that came directly from a VCS. This will throw a false violation if you run the Policy on the stuff in the blib/ directory (as Test::Perl::Critic does). I'm not sure how to get around that. Show quoted text
> As an alternative, rather than Perl::Critic trying to guess what VCS the > project is using, the new RequireVCS policy would warn unless > .perlcritic has been configured with what VCS is in use. Then it could > choose an appropriate method of checking. It could also be configured > with the path to the proper program to run, rather than grovelling up > the directory tree looking for .blah directories.
Yes, this seems like the right thing to do. But it leads me to feel that such a Policy does not belong in the core. Presently, all the core policies are zero-conf. They all do something useful right out of the box (even if you don't agree with the default config). I would like to keep it that way. Requiring configuration for some Policies is fine. But from a usability perspective, I feel it automatically relegates them to a non-core distribution, so novice users will typically not have access to this Policy. Unfortunate, but necessary I think. Show quoted text
> A resurrected RequireVcsKeywords would also key off this information > (rather than having it told redundantly). It would then check for VCS > keywords appropriately, which includes not requiring them at all if your > VCS doesn't support them.
In the current architecture, each Policy is isolated and independent. They don't talk to each other and they don't share configuration information. So tying these Policies together directly will either be a hack, or we'll have to re-architect quite a bit. Another approach would be to combine the Policies together. This obviously makes the Policy more complex, and again, it conflates multiple issues. But it might be a more natural solution, given the current architecture. There might be other approaches. I'll have to think about it a bit. -Jeff
Subject: Re: [rt.cpan.org #69546] Remove Perl::Critic::Policy::Miscellanea::RequireRcsKeywords
Date: Wed, 22 Feb 2012 20:50:56 -0800
To: bug-Perl-Critic [...] rt.cpan.org
From: Jeffrey Thalhammer <jeff [...] imaginative-software.com>
Download (untitled) / with headers
text/plain 507b
On Feb 22, 2012, at 7:23 PM, Michael G Schwern via RT wrote: Show quoted text
> I have begun work on Miscellanea::RequireVcs. Help and comments very welcome!
Excellent! I'll check it out this weekend. Just curious why you're scratching this particular itch right now... Are you tired of disabling this Policy in all your P::C configs? Are you working with some developers that neglect to put files in a VCS? Are you getting lots of annoying questions about this Policy from your colleagues? Something else? -Jeff
Download (untitled) / with headers
text/plain 6.7k
Something I realized while writing up this reply: this is NOT because I think P::C needs a policy to detect a VCS. This is really about quieting the annoying RequireRcsKeywords policy by eliminating the excuse that it's a proxy for detecting a vcs. If RequireRcsKeywords was turned off by default (or just stopped bothering people not using CVS/SVN) I'd say P::C doesn't need RequireVcs. Nobody needs a policy to tell them a project is not using a vcs, it's painfully obvious. Nobody who is failing to use a vcs is likely to be using perlcritic nor at medium severity nor be swayed by a policy. Therefore, a simple solution presents itself. 1. Junk the idea of a policy to check if you're using a VCS. It doesn't detect anything which isn't already obvious. It doesn't help the people who need help. 2. Change RequireRcsKeywords to ONLY be about RCS keywords. 3. Move the VCS detection code into VCS::Detect. 4. Have RequireRcsKeywords use VCS::Detect to check for an applicable VCS. Non-applicable VCS get an automatic pass. 5. Reduce RequireRcsKeywords to the lowest severity. RCS keywords just aren't that important and the cost of satisfying the policy is high. (Not strictly necessary) 5b. If VCS::Detect detects no vcs, RequireRcsKeywords is satisfied. This lets RequireRcsKeywords work on distributed code. I like that idea. What do you think? Here's my detailed reply I wrote up before realizing the above. It's largely irrelevant if we take the above path. ---------------------------------------------------------------------- The implementation has changed since I wrote it up. It's now zero-conf (giving it an explicit type is optional) and now works just by looking for VCS files and directories. It only detects if the file is in a version controlled tree, not that the file is actually under version control. This is preferred behavior and I'll explain later. It works for RCS, CVS, SVN, Mercurial, Git, Bazaar and Perforce. Others can be added later. SVK cannot be detected in this manner so you get an automatic pass if you tell it you're using SVK (I doubt there's many users left). Now that the policy is zero-conf and eshews external programs, it works like any other policy except in one major respect: it doesn't look at the code but the surrounding environment. The largest consequence is the policy will not work on shipped code. Perl::Critic should be an author only test, but this may cause complications. If anything argues against inclusion in the core, it's this. Separating RequireVcs from RequireRcsKeywords has the benefit that the severity of RequireVcs can be raised to medium. Not having a version control system is fairly severe and it won't generate so many false negatives. It's also been moved to the "maintenance" theme. RequireRcsKeywords is now at lowest severity reflecting both its high cost making the policy happy, narrow scope of use (ie. only RCS, CVS and SVN users) and low impact. It's also been removed from the PBP category. This makes the "low" severity more useful out of the box by removing a common false negative. I'm considering moving the VCS detection code into its own module, VCS::Detect. RequireRcsKeywords could then make use of that to determine if an appropriate version control system is in use and give other version control systems a pass. Show quoted text
> Just curious why you're scratching this particular itch right now... > > Are you tired of disabling this Policy in all your P::C configs?
Yes. I have developed a common .perlcritic for my projects which bends it to my will, so I have a solution, but bad defaults effect everyone. Show quoted text
> Are you working with some developers that neglect to put files in a VCS?
I really doubt this policy will have any real impact. A missing VCS is dead obvious, I don't need perlcritic to tell me there isn't one in use. Anyone who isn't using version control is A) unlikely to be using perlcritic B) unlikely to be using it at medium severity and C) swayed by a policy to start using version control. This is about eliminating the annoying RcsKeywords policy. If RequireRcsKeywords was turned off by default (or just stopped bothering people not using CVS/SVN) I'd say P::C doesn't need RequireVcs. Show quoted text
> Are you getting lots of annoying questions about this Policy > from your colleagues?
Yes. This latest one came up from a discussion on Stack Overflow about ProhibitReverseSortBlock. http://stackoverflow.com/questions/9398789/how-can-i-sort-one-key-ascending-another-descending-without-using-b-compariso It lead to a number of people commenting they don't use perlcritic, or avoid anything but the highest severity, because the default policies get a little rediculous: the policy itself is too picky (ex. RcsKeywords), or the implementation is insufficient to properly judge the code (ex. ProhibitReverseSortBlock), or the default config is unrealistic (ex. rejection of 36129 to fix ProhibitReverseSortBlock). So I decided to fix one. tl;dr discussion of why it's a Good Thing to not check each individual file follows... I rejected the command-based implemenation for several reasons. The first broad category is "technical problems with grovelling around for executables". * The policy has to guess that an external executable is what it thinks it is. This could lead to unwanted side effects. * The executable my be under a different name or outside the PATH. This would require the user to configure a path for each VCS type they might work with, annoying. Worse, the configuration is *per user* not per project. There is currently no way to have both per user and per project perlcritic configuration. * The executable may not exist at all. For example, if a Windows user is using TortoseSVN they don't have a command line executable. The more damning problem appears when you examine a perlcritic workflow. 1. Write a new file. 2. Run perlcritic on it. 3. Test it (which might run Test::Perl::Critic). 4. Add and commit it. If the policy is "this individual file is under version control" then the above workflow does not work. Each file must be added BEFORE critic is run otherwise you get false negatives. This is undesirable. Detecting an added but never committed file is a bit more complicated even if you have commands, and impossible otherwise. There's also reasons why you'd want to run perlcritic over files which will never be checked in. You mentioned blib/ and other generated files. One could put a "## no critic" in each generated file, but that's trouble particularly for blib. In the end, the policy is about making sure you're using a version control system, not telling you how to use it in detail. Version control systems are already straying outside Perl::Critic's scope and the policy's qualifications are best left broad. As every file is checked, individual false positives are not important.
Subject: Re: [rt.cpan.org #69546] Remove Perl::Critic::Policy::Miscellanea::RequireRcsKeywords
Date: Sat, 25 Feb 2012 16:10:22 -0800
To: bug-Perl-Critic [...] rt.cpan.org
From: Jeffrey Thalhammer <jeff [...] imaginative-software.com>
Download (untitled) / with headers
text/plain 726b
On Feb 25, 2012, at 11:04 AM, Michael G Schwern via RT wrote: Show quoted text
> I like that idea. What do you think?
I think we can go even further. Let's just take RequireRcsKeywords out of the core and put it Perl-Critic-More (or a completely separate dist). Then we don't even have to bother with trying to detect the VCS. Rationale: 1) As you said, checking for VCS usage is really outside of Perl::Critic scope. 2) RequireRcsKeywords does have other merits, but it is only relevant to SVN or CVS users. 3) By installing external Policies, the user implicitly acknowledges they are going outside the defaults of Perl::Critic. Therefore it is reasonable to expect them to configure and disable those Policies accordingly. -Jeff
Subject: Re: [rt.cpan.org #69546] Remove Perl::Critic::Policy::Miscellanea::RequireRcsKeywords
Date: Sat, 25 Feb 2012 22:40:19 -0800
To: bug-Perl-Critic [...] rt.cpan.org
From: Michael G Schwern <schwern [...] pobox.com>
Download (untitled) / with headers
text/plain 437b
On 2012.2.25 4:10 PM, Jeffrey Thalhammer via RT wrote: Show quoted text
> I think we can go even further. Let's just take RequireRcsKeywords out of the core > and put it Perl-Critic-More (or a completely separate dist). Then we don't
even have Show quoted text
> to bother with trying to detect the VCS.
+581 FWIW I'm still writing VCS::Detector. I've already done all the work writing the RequireVcs policy and others have expressed interest in the functionality.
RT-Send-CC: schwern [...] pobox.com, jeff [...] imaginative-software.com
Download (untitled) / with headers
text/plain 1.4k
Le 2012-02-26 01:10:32, jeff@imaginative-software.com a écrit : Show quoted text
> > On Feb 25, 2012, at 11:04 AM, Michael G Schwern via RT wrote: >
> > I like that idea. What do you think?
> > I think we can go even further. Let's just take RequireRcsKeywords > out of the core and put it Perl-Critic-More (or a completely > separate dist). Then we don't even have to bother with trying to > detect the VCS. Rationale: > > 1) As you said, checking for VCS usage is really outside of > Perl::Critic scope.
I agree. And the solution that schwern is building (detecting a VCS) would be bad anyway. Because P::C policies should be about Perl code quality, not about development practices in general. P::C policies should stay VCS-agnostic and still work outside the VCS. For example, I think that a good practice is to make a distribution release ("./Build dist" / "make dist") only from a export of the repository ("svn export") rather than from a working directory ("svn checkout") that may not be clean. In this context there is no .svn directories to detect. But P::C policies should work either from the VCS or not. I already see too many Dist::Zilla-built distributions that enforce using a Git repository hosted on GitHub (I admit to use this on my own projects because it is convenient *for me as the original author*). And I don't want this (VCS dependency) in Perl::Critic. -- Olivier Mengué - http://perlresume.org/DOLMEN
CC: schwern [...] pobox.com
Subject: Re: [rt.cpan.org #69546] Remove Perl::Critic::Policy::Miscellanea::RequireRcsKeywords
Date: Mon, 27 Feb 2012 13:07:23 -0800
To: bug-Perl-Critic [...] rt.cpan.org
From: Jeffrey Thalhammer <jeff [...] imaginative-software.com>
Download (untitled) / with headers
text/plain 780b
On Feb 27, 2012, at 2:12 AM, Olivier Mengué via RT wrote: Show quoted text
> I already see too many Dist::Zilla-built distributions that enforce > using a Git repository hosted on GitHub (I admit to use this on my own > projects because it is convenient *for me as the original author*).
I think that's a separate issue, more closely related to the MANIFEST debate (https://rt.cpan.org/Ticket/Display.html?id=43908). As the development process gets more sophisticated, the code that ships in a distribution may be very far removed from what is actually authored. So the old mode of collaboration by patching the dists is becoming less and less feasible. These days, I think the VCS repository is where collaboration happens, because that's where the hand-written code actually lives. -Jeff
Download (untitled) / with headers
text/plain 105b
Sending the previous mail has failed. Please contact your admin, they can find more details in the logs.
Download (untitled) / with headers
text/plain 105b
Sending the previous mail has failed. Please contact your admin, they can find more details in the logs.
RT-Send-CC: jeff [...] imaginative-software.com
Download (untitled) / with headers
text/plain 1.2k
Le 2012-02-27 22:07:34, jeff@imaginative-software.com a écrit : Show quoted text
> As the development process gets more sophisticated, the code that > ships in a distribution may be very far removed from what is > actually authored. So the old mode of collaboration by patching > the dists is becoming less and less feasible. These days, I think > the VCS repository is where collaboration happens, because that's > where the hand-written code actually lives.
I fear through your words that you may be tempted to not distribute in the CPAN distribution some code that is used to generate Perl::Critic (I'm not talking about dependencies available on the CPAN). I insist that all the "hand-written" code used to generate the live code of a CPAN distribution must be in the distribution itself. Beside my personal opinion on that matter, it is also the opinion of the Debian project. See the Debian Free Software Guidelines http://www.debian.org/social_contract.en.html So even if patching from the CPAN dist is not anymore the common practice, it should stay doable. Breaking that would break one of the unwritten rules of the CPAN, and would also break distributions of the project on free software platforms. -- Olivier Mengué - http://perlresume.org/DOLMEN
Subject: Re: [rt.cpan.org #69546] Remove Perl::Critic::Policy::Miscellanea::RequireRcsKeywords
Date: Tue, 28 Feb 2012 13:41:32 -0600
To: bug-Perl-Critic [...] rt.cpan.org
From: Elliot Shank <perl [...] galumph.com>
Download (untitled) / with headers
text/plain 199b
On 2/25/12 6:10 PM, Jeffrey Thalhammer via RT wrote: Show quoted text
> 2) RequireRcsKeywords does have other merits, but it is only relevant > to SVN or CVS users.
Wrong, for reasons stated earlier in this ticket.
Subject: Re: [rt.cpan.org #69546] Remove Perl::Critic::Policy::Miscellanea::RequireRcsKeywords
Date: Tue, 28 Feb 2012 14:51:07 -0800
To: bug-Perl-Critic [...] rt.cpan.org
From: Jeffrey Thalhammer <jeff [...] imaginative-software.com>
Download (untitled) / with headers
text/plain 699b
On Feb 28, 2012, at 8:05 AM, Olivier Mengué via RT wrote: Show quoted text
> I fear through your words that you may be tempted to not distribute in > the CPAN distribution some code that is used to generate Perl::Critic > (I'm not talking about dependencies available on the CPAN).
I see where you are going. No, I won't go out of my way to make it impossible to repackage my code. Everything required will either be in the distribution or available through some other open source outlet (CPAN, Apache Foundation, GNU, etc.). So I think we are in violent agreement. But I can't ship the *entire* development stack within the distribution, so I have to draw the line somewhere -- that's all I'm saying. -Jeff
Subject: Re: [rt.cpan.org #69546] Remove Perl::Critic::Policy::Miscellanea::RequireRcsKeywords
Date: Tue, 28 Feb 2012 18:18:30 -0800
To: bug-Perl-Critic [...] rt.cpan.org
From: Jeffrey Thalhammer <jeff [...] imaginative-software.com>
Download (untitled) / with headers
text/plain 696b
On Feb 28, 2012, at 11:41 AM, Elliot Shank via RT wrote: Show quoted text
> Queue: Perl-Critic > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=69546 > > > On 2/25/12 6:10 PM, Jeffrey Thalhammer via RT wrote:
>> 2) RequireRcsKeywords does have other merits, but it is only relevant >> to SVN or CVS users.
> > Wrong, for reasons stated earlier in this ticket.
If you are referring to the comment that git *ought* to have keywords, that isn't very compelling. Afflicting git users with this Policy doesn't do anything to help them. If we feel that git needs keywords, then we should take that up with the git authors, not beat users over the head about something they can't do anyway. -Jeff
Download (untitled) / with headers
text/plain 1019b
This seems to have drifted well off-topic into version control practices well out of the purview of Perl::Critic. In the interest of getting something concrete out of this, I'd like to try and wrap it up. On the topic of what to do about RequireRcsKeywords it seems there's broad consensus that we should remove it... except for Elliot who will have to carry on knowing people can use git and Perl::Critic won't spit at them for it. On the topic of RequireVcs it also seems there's broad consensus that Perl::Critic shouldn't be in the game of detecting version control nor the author's environment in general. Also the discussion shows there's many different ideas about good version control practice, and some are not very compatible with RequireVcs. So it should be canned. So... I will... * Delete RequireRcsKeywords * If the Perl::Critic::More folks want to adopt it, they can. * Drop RequireVcs * I'll move the guts into VCS::Detector And then we can close this ticket and stop expending energy on it.
Subject: Re: [rt.cpan.org #69546] Remove Perl::Critic::Policy::Miscellanea::RequireRcsKeywords
Date: Tue, 28 Feb 2012 23:26:29 -0800
To: bug-Perl-Critic [...] rt.cpan.org
From: Jeffrey Thalhammer <jeff [...] imaginative-software.com>
Download (untitled) / with headers
text/plain 210b
On Feb 28, 2012, at 6:36 PM, Michael G Schwern via RT wrote: Show quoted text
> So... I will...
Great. Make it so. Thanks for helping us think this through. For me anyway, it was a long but enlightening excursion. -Jeff
RT-Send-CC: schwern [...] pobox.com, perl [...] galumph.com
Download (untitled) / with headers
text/plain 320b
RequireRcsKeywords has been removed from the core Perl-Critic distribution in version 1.118. It will now ship with Perl-Critic-More at some point in the future. Right now, that distribution needs some clean-up work before I can ship it. -- Jeffrey Thalhammer Imaginative Software Systems www.imaginative-software.com


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.