Re: Should DSLIP codes be updated?
* Robert Rothenberg [EMAIL PROTECTED] [2005-03-29T18:03:09] On 29/03/2005 22:14 Andy Lester wrote: Or thrown away entirely, along with the rest of the archaic idea of module registration. I'm sympathetic to the idea, but some of the information in DSLIP is useful and shouldn't be thrown away (such as how supported, alpha/beta/mature, and license). What isn't in META.yml should go there. I assume you mean What isn't in META.yml should go in DSLIP. Why not What isn't in META.yml should go in META.yml? No reason every module that wants to provide this information can't. -- rjbs pgpsQatgjrGuz.pgp Description: PGP signature
Re: Should DSLIP codes be updated?
Ricardo SIGNES writes: I assume you mean What isn't in META.yml should go in DSLIP. Why not What isn't in META.yml should go in META.yml? META.yml sounds much more sensible to me. It wasn't around when DSLIP was created, but it is now. Of course, even if we change _where_ this metadata is stored, we still have to address Robert's original points about the data itself. Smylers
Re: Should DSLIP codes be updated?
* Robert Rothenberg [EMAIL PROTECTED] [2005-03-29T14:16:11] Some food for thought and debate. I'm wondering if the DSLIP codes [1] be updated, if revamped altogether. Note the following issues: I vote for eliminated. -- rjbs pgpxUKHHyPWvh.pgp Description: PGP signature
Re: Should DSLIP codes be updated?
On Tue, Mar 29, 2005 at 03:06:33PM -0600, Andy Lester wrote: On Tue, Mar 29, 2005 at 07:16:11PM +, Robert Rothenberg ([EMAIL PROTECTED]) wrote: Some food for thought and debate. I'm wondering if the DSLIP codes [1] be updated, if revamped altogether. Note the following issues: Or thrown away entirely, along with the rest of the the archaic idea of a module list. The Module List is dead. Module Registration is different. Tim.
Re: Should DSLIP codes be updated?
On Tue, Mar 29, 2005 at 11:06:37PM +0100, Tim Bunce ([EMAIL PROTECTED]) wrote: Or thrown away entirely, along with the rest of the the archaic idea of a module list. The Module List is dead. Module Registration is different. Mea culpa. I'll rephrase. Or thrown away entirely, along with the rest of the archaic idea of module registration. The time has come to recognize that CPAN is an unregulated free-for-all, and that the existing way of trying to wrap our heads around its contents hasn't scaled and needs to go away. The good parts (knowing who is authoritative for a module) need to get pulled out, and put into a new system. xoa -- Andy Lester = [EMAIL PROTECTED] = www.petdance.com = AIM:petdance
Re: Should DSLIP codes be updated?
On Tue, Mar 29, 2005 at 04:14:46PM -0600, Andy Lester wrote: On Tue, Mar 29, 2005 at 11:06:37PM +0100, Tim Bunce ([EMAIL PROTECTED]) wrote: Or thrown away entirely, along with the rest of the the archaic idea of a module list. The Module List is dead. Module Registration is different. Mea culpa. I'll rephrase. Or thrown away entirely, along with the rest of the archaic idea of module registration. :-) The time has come to recognize that CPAN is an unregulated free-for-all, and that the existing way of trying to wrap our heads around its contents hasn't scaled and needs to go away. The good parts (knowing who is authoritative for a module) need to get pulled out, and put into a new system. I don't mind if the current system gets fixed (which could be done, per my previous emails) or something new gets implemented. Ultimately what matters most is that something gets done by someone. Personally I've done my time, all ten years of it, as a please give your modules a sensible name advocate. I'm letting others do that now, to whatever extent they want. Tim.
Re: Should DSLIP codes be updated?
On 29/03/2005 22:14 Andy Lester wrote: Mea culpa. I'll rephrase. Or thrown away entirely, along with the rest of the archaic idea of module registration. The time has come to recognize that CPAN is an unregulated free-for-all, and that the existing way of trying to wrap our heads around its contents hasn't scaled and needs to go away. The good parts (knowing who is authoritative for a module) need to get pulled out, and put into a new system. I'm sympathetic to the idea, but some of the information in DSLIP is useful and shouldn't be thrown away (such as how supported, alpha/beta/mature, and license). What isn't in META.yml should go there. Other things such as interface style could be determined automatically, though it may take hints from developers. I'm not sure if it really matters if a module uses embedded Java, Perl6, Lisp, or whatever so long as it works. What's more important is how to indicate what external programs or libraries a module uses. (As a CPAN Tester this is the biggest bugbear!) Support information is a little more nuanced, and I'm not sure how that should be handled. Rob
Re: Should DSLIP codes be updated?
On Tue, Mar 29, 2005 at 11:03:09PM +, Robert Rothenberg wrote: I'm sympathetic to the idea, but some of the information in DSLIP is useful and shouldn't be thrown away (such as how supported, alpha/beta/mature, and license). What isn't in META.yml should go there. I'm much less interested in whether the author thinks the work is mature, than what the users thinks. We already have a mechanism to create version numbers that indicate a developer release. For me, having a development/stable indicator than an alpha/beta/mature label. How many times have you found a module with a version less than '0.10' that was actually stable mature? On the other hand, sometimes 'mature' modules get overhauled, abandoned or forked and aren't really 'stable'. Mark -- http://mark.stosberg.com/
