Had a bunch more thoughts on this topic, and I feel I agree with Brian: a forge with one module for every purpose, supported maybe by library modules (like linux) would be the best. It would mean consolidating the 17 ssh modules that exist now into one all encompassing ssh module. In the case of SSH that is totally doable, but consider the 300 gazillion different use cases of apache and things get interesting. I think this would mean we'd have appointed maintainers for each module, and if possible a puppetlabs provided jenkins install (with community provided jenkins slaves?) that would do the CI testing every night. That would then make it possible to have an auto-updated overview for each module of the latest supported OS's for puppet, and wether that module passes tests for that OS.
This seems like a massive undertaking from where we are now, but it would in the end make all of our lives a ton easier (one trusted source for good high quality modules) and reduce the 'problem' of inter-module dependencies to a minimum. Of course it still exists for in-house applications that are being puppetised, but it would already mean the world if they would be able to depend on what the public trusted modules define. I personally like the way the drupal module projects work: anyone can start a project, but they are all hosted on the drupal.org site within drupal.org version control, and they have teams of code reviewers maintaining integrity of the module base that lives on drupal.org. cheers, Walter On Mon, Jan 30, 2012 at 10:51, Felix Frank <felix.fr...@alumni.tu-berlin.de> wrote: > Hi, > > On 01/28/2012 04:35 PM, Trevor Vaughan wrote: >> Drawbacks: >> >> * Requires the user to have an explicit working knowledge of all > modules and namespaces >> * Adds a lot of random logic to the code (unless it becomes a > metaparam of some sort) > > You skipped the most important drawback: Commitment to parameterized > classes. The fact that there can be only one place that includes those > classes, and that this singular place must have the whole picture of > what requirements are met, is conceivably a show stopper from my point > of view. > > This will work for people that have a functional ENC, I guess, but > should that be a requirement for using Forge modules? > > Furthermore, how can modules hope to ever interoperate like this? If all > module classes get parameterized, it will be outright impossible for one > module to ever include another module's classes. > Say module A includes class B::C. As soon as a user installs module A in > addition to B, they have to clean their manifests of inclusions of B::C. > > On 01/29/2012 07:39 AM, Brian Gupta wrote: >> It frightens me a bit that I think the "correct" solution, will be to >> replicate what the distros are doing in Puppetforge. Basically turning >> puppetforge into a massive cross distro metadata repo, with very strict >> contribution standards and rules. This would involve strong rules for >> curated modules that would require manpower to vet (and to >> contribute the modules). > > I honestly don't see the problem. Imagine CPAN was limited to downloads > of tarballs from the website (or even souce control checkouts). I > disbelieve it would be as significant today as it has become. > The same goes for Ruby Gems and all such systems. > > As this seems to be a recurring theme: Am I wrong to compare these to > the Forge? > > Sincerely, > Felix > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > -- Walter Heck -- follow @walterheck on twitter to see what I'm up to! -- Check out my new startup: Server Monitoring as a Service @ http://tribily.com Follow @tribily on Twitter and/or 'Like' our Facebook page at http://www.facebook.com/tribily -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
