This is regarding ticket 5517. Briefly, that ticket identifies a corner case of parameterized classes and inheritance that behaves unexpectedly with no warnings or error messages. The ticket has evolved from "please fix" to "please warn or treat as an error" to "parameterized classes were never a good idea anyway, let's kill them".
Pardon me while I vent a little. Puppet has a long history of introducing new features that reference some conceptual underpinning, then uncovering major flaws and failures to completely implement the conceptual model, deciding they don't work at all, and deprecating them. To name just a few: inheritance, parameterized classes, stored configurations, global variables (or depending on who you ask, variables in general), Ruby DSL, ENCs, extlookup, Hiera 1. Some of these technologies died within months of being introduced! This is incredibly abusive to Puppet's users, who must either constantly rewrite their manifests to suit the latest hotness before it gets cold, or not upgrade to versions of puppet that no longer support features they use. Now, I know software development is hard, and that the core Puppet development team pushes pretty relentlessly forward, and that a lot of development comes from community members submitting patches with subtle bugs or model mismatches that get past review and QA. Nobody's perfect. I know that semantic versioning helps users to make compatibility predictions based on version numbers. I know that the new parser - and a lot of Henrik's other work - builds a base for real, formally defined behaviors that can be supported long-term. I know that ARMs are meant to open a space for careful thought and discussion of new features and their implications for the future. Basically, I'm venting, but I realize that improvement is already occurring and I'm grateful for it. What I've been missing is an explicit conversation about what I see to be a substantial problem, and the ways we can all help fix it. I'll give a start to the latter: 1. We should all read ARMs early and critically. I've certainly failed on this count. 2. We should resist the urge to admit defeat on (mis)features already implemented, and look for creative ways to fix their warts. 3. When we do admit defeat, surrender completely and spend a *lot* of effort making sure the new way is the right way - the cost to users is huge, so make it count. As another +1 to the dev team, the recent work on implicit ordering for resources has been a great example of #2. Looping back to #5517, IMHO it's not time to give up on parameterized classes, so let's fix the wart. Thanks for listening :) 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 post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-dev. For more options, visit https://groups.google.com/groups/opt_out.
