On Wed, Jan 8, 2014 at 3:20 PM, Daniel Pittman <[email protected]>wrote:
> On Wed, Jan 8, 2014 at 1:09 PM, Andy Parker <[email protected]> wrote: > > 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? > > I think the best thing would be that tier 1 types and providers are > part of the Puppet core, and tier two are modules that are bundled > into the core and shipped with it. > > I agree that more of what is in core needs to be moved out into modules. I think having a tier 2 inside the main repo would provide the path to do that. We can first move some parts into the tier 2 area and then over time it might just move entirely to a separate module. But the question here was actually more of "What actual parts of the system should be classified as tier 1 and what parts are tier 2?" > > * How should the separation be made evident? > > By putting tier 2 code into modules -- and, optimally, making it > sensible to upgrade them separately -- the division is very clear. > Core code is core, and non-core code is in modules. > > Users who want it to "just work" get a set of modules vetted, tested, > and shipped that work out of the box. Transparently, no less, because > we do support types and providers in modules fairly well. > > "vetted" and "tested" are the key things here. These parts of the system aren't really vetted, nor are they tested. We don't check that the FreeBSD package providers work, for instance. > It makes it clear looking at the code, too: core things are in core, > and non-core things get pulled in from a different source when the > product ships. > > > * How should contrib be structured? > > * Process for gaining or losing a maintainer? > > Like any module: put it on the forge, have someone own it. Those > people could very well be... > > > * 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?) > > ...the Puppet Labs paid staff, who work on "Puppet", and now also work > on things that Puppet ships. If you take the approach of ensuring > that your team can ship new versions of those modules, you resolve the > problem of control. > > It also means that, eg, ptomulik can ship improvements for the FreeBSD > tooling ahead of Puppet, and the newer versions will get rolled back > into core when they are tested, vetted, and ready to be used without > effort by folks who don't want the complexity of learning our module > ecosystem -- they just want to get things done. > > > 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. > > I suspect your first reaction to this will be "no", or perhaps even > "hell, no!"; overall, I think that shipping modules with the core is > actually a good step forward. Many languages -- Ruby, Perl, Python, > Java, Clojure -- have found this an effective way to manage their core > and library separation. > > I think that aiming for it is a noble goal, but not where we are right now. There was one experiment with pulling some things into a module (nagios, I believe) but that backfired. Wouldn't first putting into place a clear delineation inside the existing codebase be a good first step in that direction? > I think there is substantial evidence that this is a good, supportable > and effective approach to solving exactly this problem, as well as to > reducing the coupling between "core" and "non-core" modules, and their > release. > > -- > Daniel Pittman > ⎋ Puppet Labs Developer – http://puppetlabs.com > ♲ Made with 100 percent post-consumer electrons > > -- > 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/CAFAW1H%3DHyzVnUaLeBu8ZHbMEKtRq2bW3b_avZzGGT0BLoSOd6Q%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/CANhgQXtu_WemuzVgL6Cz%3D8JArdn6XF7NuEOB9AkYz2bTejFZpA%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
