Front page | perl.perl5.porters |
Postings from June 2006
Randy W. Sims wrote: > Adam Kennedy wrote: >> Randy W. Sims wrote: >>> Adam Kennedy wrote: >>>> Carp... >>>> >>>> utf8 >>>> >>>> warnings >>>> >>>> A few others, but yes, it should look something like that >>>> >>>> Level 1 - Perl, strict, Carp, warnings, utf8, a few other small things >>>> >>>> Level 2 - Level 1 + whatever is required to have a working CPAN client >>>> >>>> Level 3 - Level 2 plus a large number of other common things... >>> >>> Is the layered approach sensible past "Level 2" as opposed to >>> grouping modules by task? Or should there be anything at all past >>> Level 2? The more sets, the more work to support them. But then, it >>> seems to be much more reassuring to some users, judging from other >>> posts, to have a "supported" set of modules. >> >> Indeed. That's part of the reason for the discussion at the hackfest, >> to come up with some idea of how we handle that. >> >> Certainly 1 and 2 are straight forward. >> >> But there's less clarity on what we might include beyond that. >> >> Something like Task::StrawberryPerl (which I've uploaded in advance of >> Strawberry Perl actually existing) may be one method for achieving that. > > Just to clarify, when I mentioned task oriented bundles, I intended > something along the lines of: > > Task::WebDevelopoment (html, cgi, etc) > Task::Algorithms (Common algorithms and data structures) > Task::Text (Text Processing, incl Regexp) > Task::Protocols (http, ftp, etc; presumably a minimal set > of these would also be incl'd in "Level 2" for CPAN.pm; > this would be the complete package) > ... > > The goal mentioned most often for growing the core is that there are not > enough *officially suppported* modules; some companies have a limited > view of using any module not officially supported (although, I > personally don't see how this is different than evaluating and using > proprietary and commercial solutions: some are good, some suck, it's up > to the developer to make sure as product is suitable for use). The only > way the task oriented groupings would satisfy these users would be to > choose a namespace and close it except to a limited set of "official" > task sets, where presumably some committee would decide which sets to > produce and which modules make up each task set. > > This seems the best middle of the road solution that could potentially > satisfy the minimalist group (me, incl) and the kitchen sink group. Although the only real example of a supported specification is the one I provided, I think we agree on the concept, at least as a starting point. Certainly I don't see any obvious alternatives. I imagine that some sort of more agressive level of QA could be used in order to make sure whatever Task:: setups (or equivalent) we created would be supported properly, and would always be working at whatever times were needed. But this sounds like the right approach in general. Adam K