On Fri, Jan 10, 2014 at 6:17 AM, Dustin J. Mitchell <[email protected]>wrote:
> 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. > > Perl has a similar approach. This difference release frequencies however, cause the perl core modules to sometimes be "dual-life" ( http://search.cpan.org/dist/perl-5.16.3/pod/perlsource.pod#Core_modules). This works out where they have some modules that are released both in the core and on CPAN, which some being actively developed in the core and others not. > 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. > > If you take a look at the tests that we run ( https://jenkins.puppetlabs.com/view/Puppet%20FOSS/view/Master/) you can see that we test on several flavors of Linux, one version of Solaris, and many different Windows versions. PE covers more platforms than the FOSS tests cover, but it would be completely reasonable for them to get support from those extra platforms by using modules. As far as future concerns, I don't think the PL FOSS maintenance of platforms will substantially increase in the future. I think where we are right now is about where we'll be for a while. We'd keep the modules to support some of the platforms open and on the forge, of course. > 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. > > Ok, let me take a stab at this: Tier-1 types: user, service, file, group, package, host, cron, exec, stage, tidy Tier-1 providers: dpkg, apt, gem, msi, rpm, windows, yum, useradd, windows_adsi, groupadd, crontab everything else is tier-2. > 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. > -- Andrew Parker [email protected] Freenode: zaphod42 Twitter: @aparker42 Software Developer *Join us at PuppetConf 2014, September 23-24 in San Francisco* -- 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/CANhgQXu2rVLzE_rK71sG5jX0aq7ZHO9wNWO-ESXgmqHV26hwzw%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
