During today's PR triage we spent a long time going over PRs 2227, 2226, 2225, 2034, and 2130. These are all related together and are the combination of two different issues. One is that the package provider needs some way of passing through arbitrary, unmodelled parameters to the provider (so that you can have modifications specific to a provider that don't have any meaning for other providers). The other part was to update the freebsd package provider support for a new packaging system that apparently came out in FreeBSD 10. The first change we want to get into the core. The second change pushes to the forefront a problem that has been plaguing us for a long time: there are a lot of systems that puppet can run on, has providers for, but we can't maintain inside the core very well (we don't have the expertise, time, or, sometimes, desire), and there are other things that we care about quite a lot and can try to take an active role in maintaining.
So here is the proposal: let's split things into 2 tiers: * Tier 1: these are things that the core team will work to make sure are working well, maintain compatibility between puppet releases, and give a critical eye to changes * Tier 2: things that are shipped as part of the standard puppet system, but are more of a "contrib" status. Those won't be required to abide by the same versioning semantics, there is a defined maintainer (or clearly unmaintained) by someone. The exact details of how contrib is structured and shipped needs to be worked out, however. So why have a Tier 2 and not just shove everything into modules? One reason would be to have things that are "core", but not maintained by the core developers still be visible and close at hand. I would give us a little more visibility into what is happening without being a bottleneck. Another would be if the maintainer doesn't want to deal with releasing the changes, thinking about version numbers, etc. They would all just be rolled into the next puppet release and go along for the ride. So the next questions to answer on this are: * What would be tier 1 and tier 2? * How should the separation be made evident? * How should contrib be structured? * Process for gaining or losing a maintainer? * Who should be the initial maintainers? I think we already have some people who might want to step up for some things (ptomulik for FreeBSD perhaps?) I know that this has been talked about for a long time and that we already have a lot of projects in flight (and have dropped the ball on so many), but if we get some consensus on this, I think we can make some good progress toward getting this all in place. -- Andrew Parker a...@puppetlabs.com 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 puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CANhgQXv_2_nDG1JTd3t79QaphjwuC9pJ4DaLk4tQmE3EnNGWog%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
