New fields for META.yml

2007-10-29 Thread Andy Lester
I'm moving my bug queue for WWW::Mechanize and Test::WWW::Mechanize over to Google Code, which is also where I host the source code. I think it'd be a good idea if META.yml had fields that say where the bug queue is, and where the source code lives. That way search.cpan.org, and any

Re: New fields for META.yml

2007-10-29 Thread David Cantrell
On Mon, Oct 29, 2007 at 11:43:30AM -0500, Andy Lester wrote: I think it'd be a good idea if META.yml had fields that say where the bug queue is ... I'm far more likely to submit a bug report once I've got your stuff installed and am using it (or trying to use it) than I am while trying to

Re: New fields for META.yml

2007-10-29 Thread Eric Wilhelm
# from David Cantrell # on Monday 29 October 2007 10:00: By that time, CPAN.pm will have cleared up the build directory and I won't have a copy of your META.yml handy. Maybe CPAN.pm should keep them handy? Of course, they can be systematically fetched from your friendly CPAN mirror.

Re: New fields for META.yml

2007-10-29 Thread Eric Wilhelm
# from Andy Lester # on Monday 29 October 2007 09:43: I think it'd be a good idea if META.yml had fields that say where the   bug queue is, and where the source code lives. It already does.   Also, a project home page would be swell as well. In the 'resources' hash, the 'bugtracker',

Re: New fields for META.yml

2007-10-29 Thread Andy Lester
automated tools are, umm, not very likely to submit bug reports. Consequently, having it in a machine-readable META.yml file doesn't seem very useful. Put it in the docs instead. Please do me the courtesy of reading the entire message. Repeating the part that it seems you missed: That way

Re: New fields for META.yml

2007-10-29 Thread Andy Lester
On Oct 29, 2007, at 12:10 PM, Eric Wilhelm wrote: It already does. Also, a project home page would be swell as well. In the 'resources' hash, the 'bugtracker', 'repository', and 'homepage' keys are defined in the spec. Ah, thank you. I'd assumed they didn't exist. Mea culpa. Now

Re: New fields for META.yml

2007-10-29 Thread Andy Lester
On Oct 29, 2007, at 5:11 PM, A. Pagaltzis wrote: • The META.yml files in older versions of your distro can’t change even though the info in them would no longer be correct. • Doing this via META.yml means the only way to update this info is to push out a new release. Clearly this info

Re: New fields for META.yml

2007-10-29 Thread A. Pagaltzis
* Andy Lester [EMAIL PROTECTED] [2007-10-29 17:45]: I think it'd be a good idea if META.yml had fields that say where the bug queue is, and where the source code lives. That way search.cpan.org, and any others, could refer to the proper URLs • The META.yml files in older versions of your

Re: New fields for META.yml

2007-10-29 Thread A. Pagaltzis
* Andy Lester [EMAIL PROTECTED] [2007-10-29 23:15]: Best is the enemy of the good. And next time this will be handy, it will also be too big a change vs. an incremental suboptimal solution, and the overnext time as well, and ever on. YAGNI does not apply either: this *is already* the overnext

Re: best is better than not best

2007-10-29 Thread Eric Wilhelm
# from A. Pagaltzis # on Monday 29 October 2007 15:25: * Andy Lester [EMAIL PROTECTED] [2007-10-29 23:15]: Best is the enemy of the good. No. Best is what the good should aim to be. If best is better than good, why choose the worst of the two? And next time this will be handy, it will also

Re: New fields for META.yml

2007-10-29 Thread Andy Lester
On Mon, Oct 29, 2007 at 11:25:34PM +0100, A. Pagaltzis ([EMAIL PROTECTED]) wrote: * Andy Lester [EMAIL PROTECTED] [2007-10-29 23:15]: Best is the enemy of the good. And next time this will be handy, it will also be too big a change vs. an incremental suboptimal solution, and the overnext

Re: New fields for META.yml

2007-10-29 Thread A. Pagaltzis
* Andy Lester [EMAIL PROTECTED] [2007-10-29 23:30]: On Mon, Oct 29, 2007 at 11:25:34PM +0100, A. Pagaltzis ([EMAIL PROTECTED]) wrote: * Andy Lester [EMAIL PROTECTED] [2007-10-29 23:15]: Best is the enemy of the good. And next time this will be handy, it will also be too big a change

Re: New fields for META.yml

2007-10-29 Thread Andy Armstrong
On 29 Oct 2007, at 22:25, A. Pagaltzis wrote: YAGNI does not apply either: this *is already* the overnext time. The gravatar spat would’ve been solved by something like that I missed that... Got a link? -- Andy Armstrong, Hexten

Re: New fields for META.yml

2007-10-29 Thread Andy Lester
I thought about it for a bit and found there are some faintly tricky questions. Nothing too serious, but I’m not entirely sure of all the answers, so I don’t have a proposal on hand. Let me know when you get one then. In the mean time, I'm moving forward. Mostly the questions are things

Re: New fields for META.yml

2007-10-29 Thread Andy Armstrong
On 29 Oct 2007, at 23:33, Andy Armstrong wrote: I missed that... Got a link? Have now - thanks. -- Andy Armstrong, Hexten

Re: distributed/centralized META.yml data

2007-10-29 Thread Eric Wilhelm
# from A. Pagaltzis # on Monday 29 October 2007 15:11: Clearly this info should live somewhere and search.cpan should use it, but META.yml is the wrong place. It belongs somewhere unversioned. +1, and see-also: some kind of common API between all of the meta-ish foo.perl.org sites.