I'm a newbie to the toolserver world. Who do I contact to get perl's Time::ParseDate installed on a toolserver (specifically, nightshade)?
-tedder
On 9/12/2010 7:41 PM, Ted Timmons wrote:
I'm a newbie to the toolserver world. Who do I contact to get perl's Time::ParseDate installed on a toolserver (specifically, nightshade)?
-tedder
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 9/12/2010 6:41 PM, Ted Timmons wrote:
I'm a newbie to the toolserver world. Who do I contact to get perl's Time::ParseDate installed on a toolserver (specifically, nightshade)?
-tedder
File a ticket in jira or install it locally
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10-09-12 08:42 PM, Q wrote:
File a ticket in jira or install it locally
Any chance you'd write up a tutorial on installing Perl modules in one's $HOME? I think it'd be helpful, as this isn't the first time it has cropped up.
- -Mike
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Mike.lifeguard:
Any chance you'd write up a tutorial on installing Perl modules in one's $HOME? I think it'd be helpful, as this isn't the first time it has cropped up.
It's already described here: https://wiki.toolserver.org/view/Perl but it's not something I think we want to encourage. (I'm not really sure why people do it; is it just the time it takes for JIRA tickets to be resolved?)
- river.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10-09-12 10:00 PM, River Tarnell wrote:
(I'm not really sure why people do it; is it just the time it takes for JIRA tickets to be resolved?)
Yes, I think so.
- -Mike
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 9/12/2010 8:00 PM, River Tarnell wrote:
It's already described here: https://wiki.toolserver.org/view/Perl but it's not something I think we want to encourage. (I'm not really sure why people do it; is it just the time it takes for JIRA tickets to be resolved?)
So I dont have to file another ticket every time the module is upgraded to fix a bug.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Q:
So I dont have to file another ticket every time the module is upgraded to fix a bug.
We currently do Perl module upgrades the same way as other software -- infrequently, and all at once. Would it be more useful if they were done more regularly, e.g. immediately upon a new module version being released?
- river.
I want to advise on this topic. Overall, module upgrades are beneficial, additional to the usual improvements to code and API, they include bug, performance and security fixes (not every vulnerability in a CPAN distribution is assigned a CVE). Living with CPAN means to always be on the bleeding edge because the CPAN clients install the newest version of a module (unless it is marked as a trial release), the same is true for the resolved dependencies which are typical plentiful, and the older version is then just gone.
This is usually a recipe for disaster, but Perl programmers write their software in a CPAN-ready fashion to take advantage of the existing toolchain and include tests which are run against an upgraded dependency⁰, so this is nicely mitigated. However, if the sysadmins upgrade right on release they would torpedo this; the authors need a respite for testing.
Toolserver authors, on average, are not good Perl programmers¹, and lack these basic community best practices pointed out above, thus I propose that a moderate approach should be taken if you decide that the advantages of a steady upgrade cycle outweigh the risks of breakage through introduced incompatibilities. This is similar to what you have been already doing for other toolserver software:
⒈ Determine the cycle length after which a collective update is run; I'd judge 3 months to be on the very conservative side. ⒉ Collect the update candidates with `perl -MCPAN -e'CPAN::Shell->r'` or App::cpanoutdated. ⒊ Make an announcement and include permalinks to the changelogs, e.g. http://search.cpan.org/dist/Crypt-SSLeay/Changes goes to the appropriate version. ⒋ Wait out the time-frame from the announcement. ⒌ Upgrade the candidates except those who had another stable release during the wait.
⁰ http://www.modernperlbooks.com/mt/2009/02/the-darkpan-dependency-management- and-support-problem.html ¹ If you are, this is your chance to unlurk, say hi!
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Ted Timmons:
I'm a newbie to the toolserver world. Who do I contact to get perl's Time::ParseDate installed on a toolserver (specifically, nightshade)?
All software installation requests should go to JIRA (https://jira.toolserver.org), in the TS project.
While you can install Perl modules locally, it's not something I would recommend doing; it's much more likely to cause issues with system Perl modules or upgrades.
- river.
On 9/12/2010 5:00 PM, River Tarnell wrote:
Ted Timmons:
I'm a newbie to the toolserver world. Who do I contact to get perl's Time::ParseDate installed on a toolserver (specifically, nightshade)?
All software installation requests should go to JIRA (https://jira.toolserver.org), in the TS project.
Done and done: https://jira.toolserver.org/browse/TS-754
While you can install Perl modules locally, it's not something I would recommend doing; it's much more likely to cause issues with system
Perl modules
or upgrades.
I agree. It's an easy way to get stuck in CPAN hell.
-ted
toolserver-l@lists.wikimedia.org