Re: OK, so we've decided that the right modules are too hard to find.
Sam Vilain [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] - encourage curators to step forward, or groups of curators, for each category; possibly even create mailing lists for people with a general interest in the technology in that category; to field questions about naming for new modules to fit into each category. These curators must have the power to update the contents of the relevant portions of the www.cpan.org site. Hi all, Everything that was said in this thread was very interresting and I, too, belive things should get better and I encourage those that want to do things _now_. I see few problems with CPAN, you might find them directly related to the need for curators: - Any one can start whatever hierarchy - Anyone can load whatever piece of code to CPAN, good or bad - Documentation level is a catastrophy, check how many readme are those generated by h2xs - The document about how to use CPAN is not clear enough or I haven't found the right one yet - 25 versions of the same module do no make it easy to look around in CPAN - Authors don't answer or have given up on maintaining there modules - The same day, the same module can be uploaded to CPAN multiple times I mirror CPAN at home and I check for new modules everyday. Guess how many times I think what the Hell is this for??? Far from me the idea to refuse uploading of modules to CPAN but 3 years from now, we'll have a useless module heap. If there is a need for curators, I believe it does, then those should be given a mandat and power to apply it or it will be useless. They must be able to say to a module author: Sorry but this is not the quality level we expect, write some documentation and come back later for your upload. This is exactly what is done for moderated mailling lists. The net result would be (IMO): - No half baked idea, modules on CPAN (could be a good idea to go through what we have today in CPAN and throw away things) - Better quality in the documentation and test (hmm, I'd have to work on my own modules too) - More people involved in this mailling list (which has less than 20 active users) since it would be the way in to CPAN Around 15 new, or updates, modules are uploaded to CPAN everyday. This might sound drastic but it is not as bad as it sounds, I would have appreciated if someone said 'No' to something I write and that is not good enough for the community. This is not for discouraging module authors but, on the contrary, make them feel that their work is appreciated and that they must commit themselves to generate something good enough. Moderators rights should be: - Create new hierarchy roots - Refuse a module name - Refuse a module because its quality is too low - Refuse a module because of lack of documentation or tests or examples (or VERSION!!!) - Give maintenance rights - Try to merge modules by asking module authors to co-operate - Write public review or accept public reviews - Coordinate with module testers - etc ... I am whilling to have my modules filtered, I hope other do too. I'll also help if I can. Cheers, Nadim. PS: PPM modules vs plain module problems should be fixed too.
Re: OK, so we've decided that the right modules are too hard to find.
[EMAIL PROTECTED] (Khemir Nadim) writes: Everything that was said in this thread was very interresting and I, too, belive things should get better and I encourage those that want to do things _now_. None of these ideas are new. - Any one can start whatever hierarchy This is not a problem, now we have search.cpan.org. - Anyone can load whatever piece of code to CPAN, good or bad I don't agree that this is a problem. - Documentation level is a catastrophy, check how many readme are those generated by h2xs But the generation was added to h2xs because people weren't putting in READMEs, and so an autogenerated one is better than nothing! - The document about how to use CPAN is not clear enough or I haven't found the right one yet You haven't found the right one yet. - 25 versions of the same module do no make it easy to look around in CPAN This is not a problem now we have search.cpan.org. - Authors don't answer or have given up on maintaining there modules THEY ARE VOLUNTEERS. - The same day, the same module can be uploaded to CPAN multiple times Yes, module authors can fix bugs quickly. How terrible! Far from me the idea to refuse uploading of modules to CPAN but 3 years from now, we'll have a useless module heap. If there is a need for curators, I believe it does, then those should be given a mandat and power to apply it or it will be useless. *We have been through this*. Innumerable times. Still nothing happened. The people most likely to act as curators got together (as they do periodically) and decided that better metadata would be the best short-term goal. I'll try and get some of them to write up the latest set of proposals. -- The best index to a person's character is a) how he treats people who can't do him any good and b) how he treats people who can't fight back. -- Abigail Van Buren
Re: OK, so we've decided that the right modules are too hard to find.
Simon, Can you please give us serious answers. Writting to this list take valuable time from me and from those reading the mails. - Authors don't answer or have given up on maintaining there modules THEY ARE VOLUNTEERS. Please don't shout if it's note to show you're happy. Check the discussion we had about Roman.pm a few weeks ago. My point is not to force anyone to develop anything but that when a module is released and the author can't maintain it, the curators job would be to design a new maintainer. Period. Now, surf to: http://search.cpan.org/recent and check: Haver-Server-0.02 -- Perl extension for blah blah blah You might think it's OK but I don't. Here is an example of what changed from version 0.07 to 0.08 for a module (loaded 10 mn after 0.07) 0.08Sun Feb 16 16:21:00 2004 Fixed MANIFEST for test.pl Everybody makes mistakes. I just would like to help people not do this kind of mistakes. Since I have missed the document, you might be able to point to it instead for telling me that I have missed it. And no, sear.cpan.org isn't a silver bullet though I use it more than cpan.org. Cheers, Nadim. Simon Cozens [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] [EMAIL PROTECTED] (Khemir Nadim) writes: Everything that was said in this thread was very interresting and I, too, belive things should get better and I encourage those that want to do things _now_. None of these ideas are new. - Any one can start whatever hierarchy This is not a problem, now we have search.cpan.org. - Anyone can load whatever piece of code to CPAN, good or bad I don't agree that this is a problem. - Documentation level is a catastrophy, check how many readme are those generated by h2xs But the generation was added to h2xs because people weren't putting in READMEs, and so an autogenerated one is better than nothing! - The document about how to use CPAN is not clear enough or I haven't found the right one yet You haven't found the right one yet. - 25 versions of the same module do no make it easy to look around in CPAN This is not a problem now we have search.cpan.org. - Authors don't answer or have given up on maintaining there modules THEY ARE VOLUNTEERS. - The same day, the same module can be uploaded to CPAN multiple times Yes, module authors can fix bugs quickly. How terrible! Far from me the idea to refuse uploading of modules to CPAN but 3 years from now, we'll have a useless module heap. If there is a need for curators, I believe it does, then those should be given a mandat and power to apply it or it will be useless. *We have been through this*. Innumerable times. Still nothing happened. The people most likely to act as curators got together (as they do periodically) and decided that better metadata would be the best short-term goal. I'll try and get some of them to write up the latest set of proposals. -- The best index to a person's character is a) how he treats people who can't do him any good and b) how he treats people who can't fight back. -- Abigail Van Buren
Re: OK, so we've decided that the right modules are too hard to find.
On Mon, 16 Feb 2004, khemir nadim wrote: Please don't shout if it's note to show you're happy. Check the discussion we had about Roman.pm a few weeks ago. My point is not to force anyone to develop anything but that when a module is released and the author can't maintain it, the curators job would be to design a new maintainer. Period. Going back to Roman.pm (I was on vacation when you first posted, hence no answer at the time), if a PAUSE admin wants the email of the original creator, (he seems a bit paranoiac about letting it displayed in the wwwild), I have it, so he can gain the rights to maintain his own module ;--) -- Michel Rodriguez Perl amp; XML http://www.xmltwig.com
Re: OK, so we've decided that the right modules are too hard to find.
On Sun, Feb 15, 2004 at 03:56:39PM +1300, Sam Vilain wrote: ___ / _ \ | | | |_ _ | |_| ||\ | ||___ \___/ | \| |___ |___ upon a time, the Perl 5 modules list was an excellent resource for those seeking to do anything non-core with Perl. However, it has not kept pace adequately with the needs of the community. I'd like to see a summary of what those needs of the community are. (Maybe I missed it as I've not been following as closely as I'd have liked. In which case a link to an archived summary would be great.) It's very important to be clear about what the problems actually are. I propose, what we do about this situation is : - expand the modules list into a new section of the www.cpan.org site, by; - deciding if the current categories are good enough 'in this day and age'; using the current list as a starting point, go through each category and decide whether it is a useful grouping any more. This will ideally also involve individuals with experience with other languages trawling over the appropriate CPAN equivalents, ie PEAR, RAA, etc, and providing nice, *brief*, informative reports on their structure. We will then hopefully have a half-decent list of categories. This process should be quick, perhaps reporting back its progress to the list every few days until there is a general consensus. Okay. - encourage curators to step forward, or groups of curators, for each category; possibly even create mailing lists for people with a general interest in the technology in that category; to field questions about naming for new modules to fit into each category. These curators must have the power to update the contents of the relevant portions of the www.cpan.org site. The idea would be to have each category something like the http://poop.sourceforge.net/ site - but on a standard template to lend it more credibility. Ideally with space for user feedback. I would hesitate to seed the listing of actual modules on the current long Perl 5 modules list. Factors such as the usage that the module has seen, whether long standing bugs were ever fixed, whether a better module has come along since and gained widespread acceptance, etc need to be taken into consideration. I disagree. You're mixing different goals that ought to be kept separate. Originally the Module List had two goals: 1: to help people find perl modules for a particular task. 2: to provide a second-tier of modules above the 'anarchy' of people uploading half-baked ideas with half-baked names. You could argue that Goal 1 is now largely addressed by searching search.cpan.org (although that's certainly not without problems). However the limited integration with the Module List's hierarchical categories and other metadata is unfortunate. I think that's partly due to Graham Barr's view (as I remember it, I might be wrong here) that the Module List was too incomplete relative to the whole of CPAN to be useful and he's right. So let's fix that - see below. Goal 2 is still important - as you can see from archives of [EMAIL PROTECTED] when there have been discussions leading to a better choice of module name. But [EMAIL PROTECTED] has it's own set of problems (that I hope will be addressed when it's integrated with RT so requests don't fall between the cracks). Many popular modules are missing from the list altogether. The text file is out of date. The underlying database isn't: http://www.cpan.org/modules/03modlist.data.gz (Though it is incomplete because not enough authors take the steps to get listed, but that's a different set of issues.) Please work with the PAUSE system, and Andreas and myself, to enhance what already exists (which includes a UI for module authors to pick which category they want the module in). Here's what I'd suggest: 0. Don't underestimate how difficult and subtle naming issues can be. 1. Split and extend the list of categories aiming for about 2 to 3 times the number to keep it managable, perhaps grouping the categories into a two-level hierarchy (but the top level is just for human use, the 2nd level names should be self-descriptive without the 2st level names). 2. Map modules from the old categories to the new ones This needs to end up as a sequence of SQL statements that can be run on the PAUSE mysql db to update the category number for each module that has one. 3. Write a script to generate http://www.cpan.org/modules/00modlist.long.html from http://www.cpan.org/modules/03modlist.data.gz or ideally from the underlying mysql database (with simpler formatting and focussing on just the modules) and give it to Andreas for PAUSE to use automatically. 4. http://www.cpan.org/modules/03modlist.data.gz is actually a perl module called CPAN::Modulelist but
Re: OK, so we've decided that the right modules are too hard to find.
Tim Bunce [EMAIL PROTECTED] writes: For those modules that are not on the Module List, (i.e., not in http://www.cpan.org/modules/03modlist.data.gz) and which have a 'significant' existing user base, develop a Fast Track process to get them added to the Module List. Good idea, but don't we need to solve the current module registry problems as well? Many module authors issue submission requests and never get a reply. -- Johan
Re: OK, so we've decided that the right modules are too hard to find.
At 13:57 +0100 2/15/04, Johan Vromans wrote: Tim Bunce [EMAIL PROTECTED] writes: For those modules that are not on the Module List, (i.e., not in http://www.cpan.org/modules/03modlist.data.gz) and which have a 'significant' existing user base, develop a Fast Track process to get them added to the Module List. Good idea, but don't we need to solve the current module registry problems as well? Many module authors issue submission requests and never get a reply. I've released about 30 modules in the past 1.5 years. I _never_ bothered to try to register. I guess that means something. Liz
Re: OK, so we've decided that the right modules are too hard to find.
[EMAIL PROTECTED] (Johan Vromans) writes: Good idea, but don't we need to solve the current module registry problems as well? Many module authors issue submission requests and never get a reply. Tim also wrote: But [EMAIL PROTECTED] has it's own set of problems (that I hope will be addressed when it's integrated with RT so requests don't fall between the cracks) -- Oh dear. I've just realised that my fvwm config lasted longer than my marriage, in that case. - Anonymous
Re: OK, so we've decided that the right modules are too hard to find.
[EMAIL PROTECTED] (Elizabeth Mattijsen) writes: I've released about 30 modules in the past 1.5 years. I _never_ bothered to try to register. I guess that means something. Likewise. (although slightly more than 30 ;) I just don't see the point of the modules list, especially now we have search.cpan.org. -- When Simon Cozens writes code, I always think twice about whether something is a bug or an esoteric implementation. - Daniel Packer