On Sunday, December 14, 2014 4:25:51 PM UTC-6, Eric Shamow wrote: > > I think it’s worth asking the question of whether you want PL to spend > their time building good CM software or dealing with and QA’ing the myriad > combinations of Rubies and gems that they are currently forced to support > due to the sloppiness and inconsistency of distro packaging and the gem > ecosystem. >
I'm not asking PL to QA my particular combination of supporting components, nor any particular set at all. Rather, I am asking that Puppet itself be a proper component, that I can integrate into my systems in a manner I choose, subject to reasonable constraints. That is in no way incompatible with PL offering AIO packages, by the way -- in fact, it should simplify that process. Moreover, it is my firm belief that maintaining Puppet's position as an independent component will be better for Puppet's intermediate- to long-term health as a software project, as well as better for PL as a business. PL seems to disagree, which of course is its prerogative. > Personally, I’d rather allow PL to vendor the Ruby and gems required to > keep Puppet itself working properly so that I can rely on it to perform > basic system tasks. Since the vendored Ruby and gems are far away from > system Ruby, I view this as a *freedom* in my ability to manage a system. I > now don’t have to worry about keeping my custom or third-party Ruby tool > code at the same version and gemset as a single tool across the system. > You can always install current Puppet in its own Ruby if you wish. I am completely in favor of supporting that alternative going forward. It's about to switch from being the harder path to being the easier path (provided that you don't care which particular Ruby hosts Puppet). That in itself will be inconvenient for me, but no more than that. On the other hand, I am asking and hoping some particular implementation of that alternative not become the *only* viable path. That is, I don't want *your* freedom to come at the expense mine. > > This then switches the burden to them to keep up with security and bugfix > issues in the Rubies and gems they bundle, but frankly I have a greater > belief that PL will manage to do this successfully - in aggregate - than > the distributions and hand-rolled gemsets that people are using now. > > And that's a large reason why I don't think it's a particularly wise business decision to provide AIO packages: the fewer CVEs have Puppet's name on them, the better. But that's really beside the point, which is not so much about PL offering AIO packages as about future Puppet being *dependent* on AIO form, and on a particular AIO form at that. I don't have to use PL's packages, but I do have to deal with Puppet's built-in requirements and limitations, and to reconcile those with my system management policies and practices. As an armchair IP quarterback, I'd also be concerned that if Puppet works *only* in AIO form then it will be the AIO form that must then be considered "Puppet". The AIO will incorporate a great deal of IP that does not belong to PL. In the past, PL has preferred a conservative approach to IP, so I'll suppose that either this isn't an issue of genuine concern or that PL has not considered it. John -- 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/8636a079-d7cb-4766-a850-1316703a871d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
