> I think the Software Development Kit (SDK) approach has more appeal: > Define a standard bundle of extra modules that people are recommended > to install with Perl. There was an attempt at an defining an SDK > for Perl some time ago but it seemed to flounder.)
Yes, for many reasons. - oftentimes there are several modules that do almost the same: choosing which one leads into lots of nitpicking, choosing some will hurt someone's feelings (either the module authors' or their proponents'), choosing all is bloatware - some people don't like their modules to be included in module collections - different people understand "SDK" differently: for some, a collection of uncoordinated modules with uncoordinated APIs with uncoordinated maintenance is not an SDK - the previous attempts tried to span the all of CPANdom - some application areas have too little experts; some have too many Frankly, I don't think restarting the old SDK discussion has much merit. It has been tried a few times in the past, and look what we have now. What I think could work is one or both of the following: - smaller, more focused "SDK working groups" where, say, the database people make their module bundles - by fiat: some people collect their own favourites and make *their* own module bundles and publish them (If people start to do this, we need a naming convention for "SDK bundles") > [CC'd to perl5-porters to see if there's any life in the SDK concept] -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
