On Tuesday, June 24, 2014 4:20:33 PM UTC+2, Felix.Frank wrote: > > Hi guys, > > On 06/24/2014 03:48 PM, jcbollinger wrote: > > > > I understand the point, but at the same time I find it harmful also > > to have hundreds of modules, that are published on the forge but > > work only for a specific case and are practically useless for > others. > > > > > > > > I disagree. It is not at all a problem -- in itself -- to have hundreds > > of narrowly-scoped modules on the forge. More modules means more > > chances to find something that serves my needs, or something I can learn > > from. The concern is presumably about how easy or hard it is to find > > 'the' right module for me, but I don't think the solution is to try to > > ensure that all modules published there meet specific, high API and > > functionality criteria. > > > > Rather, the solution is the same as ever in an open-source community: > > documentation, reputation (both of the code and of the author), > > popularity (mostly of the code), and support and recommendations from > > the community, especially (but not exclusively) from thought leaders. I > > daresay, for example, that many people choose /your/ modules in large > > part just because they are yours. You and your modules have strong > > reputations, which are reinforced when users find that your modules work > > well for them (or undermined in the unlikely event that they find > > otherwise). > > > > Perhaps the Forge platform could be enhanced to make those tools easier > > to apply in its context, but at least some of them are already > > reasonably accessible. > > I have followed this thread with great interest, and although I didn't > take the time to read the blog posts, I have to say that I'm pretty much > 100% with Alessandro on this one. > > My own dives into the Forge have been short-lived so far, but the > current experience is detrimental, I feel. The multitude of solutions > and the fact that there may actually be two or more modules that each > suit *some* specific needs of mine, with no visible impetus towards > merging similar modules into a "one fits all" solution makes me despair > early. It is my fear that many potential users are repelled by the same > experience. > > It would be my hope that each problem that modules solve could culminate > in one module that strikes just the right balance between being generic > enough to serve (most) everyone without being overladen with features > that almost nobody needs. (Such go-to modules would likely be taken > under the umbrella of "supported" modules.) > > That is not to say that there should be no ecosystem, we just cannot > have too many dead leaves and branches scattered everywhere. Those > should be recycled into better core modules by some means. > > If I read him correctly, Alessandro is currently questing for a way to > make just this unification process possible, although that's possibly > just my interpretation. (But a common set of practices *will* make the > merging of functionality much easier.) I support this.
Cool. Any contribution to https://github.com/example42/puppet-tp is welcomed. I'm currently figuring out what's the best way to organise and structure the module data and have to fix the tp_lookup function that is the core of the hiera-like retrieval mechanism. Once these basic parts are fixed I will start to populate aggressively the data directory (with data for different applications) and then take care of the puppet tp face. Anyway , just to make it clearer, the intended usage of tp is to ease and standardise the management of software that can be installed with normal native packages (eventually providing a custom repo via the dependency_class parameter). It's not and will never be a complete replacement of other modules, rather I think of it as a complementary tool, to be used instead of full modules for some cases (where you deal with just packages , services and files resources) or together with an existing module (which might provide some application specific resources (such as mysql::grant) that a generic tp module will never have) in other cases. It's intended to be used in higher abstraction modules where can stay the logic of how different resources are grouped ad configured. Think of it as the tool that can let us define the shape of the single lego pieces, but these pieces have to be assembled together somewhere else. al -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/e855d2fe-e159-4579-96a9-6a3e9dbf9263%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
