develooper Front page | perl.perl5.porters | Postings from June 2006

Re: Its time we set the score straight on Perl 5 and Perl 6 and debunkour own self-generated FUD.

Adam Kennedy
June 23, 2006 17:49
Re: Its time we set the score straight on Perl 5 and Perl 6 and debunkour own self-generated FUD.
Message ID:
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;
>    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 Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About