On Wed, Jan 15, 2014 at 2:20 PM, Andy Parker <a...@puppetlabs.com> wrote:
> Ok, let me try to summarize the discussion so far: > > * Tier1/Tier2 as a basic premise seems to be accepted as a good idea. > * Tier2 code ideally won't live inside the puppet repo at all > * Tier2 code should be packaged up as modules > * Make the separation based on what we (PL) actually test > * OR make *everything* Tier2 (no such thing as core providers) > * the puppet packages should pull in a select set of modules (and > specific versions) and ship those in a vendor modulepath > > I think I can be on board with this as an end goal. And I lean toward > making everything Tier2. My only concern is the overhead of managing all of > those dependencies, it seems like it could quickly lead to a place where we > are spending a huge amount of our time just dealing with version numbers. > > Now for a proposal on how to get there (order might be a little wrong): > > 1. create a "modules" directory that is a peer of "lib" in the puppet > repo > 2. select a section of functionality to pull out (nagios might be the > first good candidate since we've already tried it once) > 3. create a puppet module in the modules directory and move the code and > tests to the module > 4. Update the rake tasks to run all of the spec tests as well as the > spec tests of each module > 5. Plumb in a "build" rake task (right now we don't have one). This will > be a step that merges the module back into the lib code as part of > packaging. > 6. Extend puppet's support for modulepath to include a static vendored > modules section > 7. Change the build/packaging/install scripts to move the modules into > the vendored directory instead of merging it into the puppet code > 8. Repeat steps 2 and 3 until happy > > After that is all in place (or just after the first one plumbs in all of > the functionality) I think we can then start moving things off to the forge > and pulling them in a different way. > This is a great thread. So as I've been reading through this and talking with people on #puppet-dev, I've come around to thinking about it this way: * there's code for which Puppet Labs is the maintainer along with the community * there's code for which there are only community maintainers * there's code that's effectively unmaintained * there's code that's currently in core, but probably shouldn't be (like the nagios stuff) For things where it was a mistake to really be in core in the first place, I think we should just move that stuff out. I'm really just thinking about the nagios types here, but maybe there are others. For things that are effectively unmaintained, like platforms that nobody is willing to step up and own...I think we should put those on a path to be moved out. We're not doing anyone any favors by having that stuff in core and bit-rotting. The other two buckets are the most important ones in my mind. This isn't really about tiers, but instead about maintained/unmaintained code. As long as code is maintained, it should be a first-class citizen regardless of whether or not it's maintained by the community or by puppet labs. The community is not second-class, which is what I think the word "tier" implies. Unmaintained code, though, is definitely second-class. :) So really what I'm talking about is actively seeking out community maintainers for certain platforms, and giving them commit access. They handle pull requests for that part of the tree, and generally act as good stewards (tests pass, obey semver, packaging works, etc). I think in order to get there, we need to do a few things: 1. Inventory what we've got in terms of platforms/types/providers 2. Figure out what subset of those are things Puppet Labs helps maintain (see Kylo's link) 3. Figure out what subset of those are like the nagios types in that they really make sense as external modules 4. For the rest, begin looking for community maintainers. We can look at people who have made commits, we can ask on this list, IRC, etc. I think once we do that exercise, we can start thinking about the mechanics of reorganizing the source tree accordingly. I'd suggest that we reorganize things so that maintainers manage a subtree. -- Deepak Giridharagopal / Puppet Labs -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAOjOXY0D5ZsAeBE87r3kWFvW5YytRBUqc-VtirzC7w-WN1WR5g%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
