>> Adopting this module would be a good project for an ambitious person or >> group, as the ecological niche is still open for vigorous growth.
> Do you really see there being growth with such a module? Not in that sense, sorry for confusion > As it is a well > established concept, shouldn't it be rather static, aside from the > occasional bug fix? yes. > If there is growth potential, what do you see on the roadmap? The growth I was seeing was more 'mindshare' growth than creeping featurism. The module concept is minimal with round-trip capability the one apparent concession to value-add feature; doing that simply is actually the breakthru. I would expect 'growth' as increased use and 'Buzz' if it were obviously actively maintained and promoted a little in the tweets/blogs. Achieving stability and and appearance of stability would be priority 1. Currently the version number has a scary number of leading zeros. The RT queue looks even worse than it is: things marked fixed in 0.04 in RT or in Changes in 0.05 .. 0.07 are still listed as OPEN in RT, which makes it hard to tell how many actual bugs are pending. So it looks even more under-supported than it is, which may (should) be scaring folks off from using it. There *are* some interesting ideas in the RT wish-list, some of which will be useful. But any that would increase the runtime cost when NOT used should be subclasses (as Damian notes in an RT reply). I am *guessing* custom separators (one wishlist item which seems plausible) can be added by careful startup recompilation of named qr//s and minimal refactoring, so that a low startup cost paid only if import or constructor requests it. This is based on a very fuzzy remembrance of module source-code deep-dive at the Arlington masterclass (in which we blew Mac video dongle with winter static in the rented sweatshop). >> Would Boston.PM be interested in doing perhaps twice yearly workshop / >> coding sprints to validate test implement test enhancements to >> Config::Std, if Damian would have us ? > Bug triage a couple times a year, plus test enhancements could work. right > This kind of broad audience, yet relatively simple module is probably an > ideal candidate for a group project. Exactly. A good practicum in module care and feeding. > We'd probably need someone in the group to volunteer as technical lead > to review the patches and upload the final package. Otherwise if we just > submitted patches, Damian would still be stuck with a fair bit of > maintenance overhead. Right, at least one (preferably more for backup) for both PAUSE up-loader and RT queue maintenance. We might want a github repo to merge/stage patches, too. Sounds like Tom is in favor. Who else has comments ? Federico, if we promise to fix it, will you use it? -- Bill [email protected] [email protected] _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
