For what it's worth, Python at least has struggled with modules being in and out of the Python distribution. Riding Python's trains means stringent compatibility constraints, long support durations (many years), and a long commit-to-ship delay. Puppet certainly moves faster than Python, so maybe that's not so important here.
Another lesson from Python is that, in fact, everything is a module. There are almost no "core Python" things aside from the language itself and some builtins. And a final lesson from Python: if it's one of the batteries that's included, then it follows Python's shipping guidelines as far as testing/vetting, compatibility, code style, and so on. If a module can't make the "Tier 1" cut, it's not shipped with Python. As for the question you want us all to answer, I think that the delineation should be such that it is easy for a user to tell when they cross a line, and should be based on PL's ability to adequately test things as well as committment to support in the future. I think that basically boils down to platforms, which in technical terms will mostly mean Tier-2 providers for Tier-1 types like service, package, file, and so on. As far as committment to support, I think that product-specific support like the nagios_* types should be in Tier 2 only as a way of saying that someday Puppet may ship without them (although presumably they'd be easy to spin off into a forge module at that time). Of course I don't know what PL's plans are, but that's the idea. Dustin -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAJtE5vRyd_vArYMOP1VYXbq-CBvfF4hNOUWUU1TGKLqfTSQ8FQ%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
