On Thu, Aug 15, 2013 at 6:20 AM, Dustin J. Mitchell <[email protected]>wrote:
> 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. > > No pardon needed. Please, go on :) > 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! > > Yes, some of these came from the idea having fundamental flaws (inheritance, the Ruby DSL as it was designed), others came from bugs leading to misconceptions all around about what the feature actually was (global variables and improper deprecation warnings), and still more came from poor implementations or prototypes made into the release (stored configurations, Hiera 1). > 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. > > This is why I tried to take a strong stance since I started that changes need to be backwards compatible. We've been treading a very fine line here, because sometimes the behavior is itself a bug, but changing it might cause breaks and other times it isn't clear what a consistent behavior across the language (or other APIs) would be. > 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. > > We'll only become better and more open if these vents and pushes and prods happen. So, thank you! We want to get better at this, but need help. As you say, we will release regressions, we will release bugs. I want to avoid that as much as possible, and yet, somehow, also release interesting new features and fixes that users want. One approach has been through the feature flags that have been used for the work on the parser that Henrik did. Another approach has been to release modules instead of new features in core (some of the windows functionality). And the final approach is to just make the change and work through the reasoning about how much of an impact it could have (what is currently happening with the manifest order changes). > 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. > I think we all have. They don't yet fit well into our process. You can see this in the google doc that I sent out with the manifest order changes. That should have been an ARM, maybe specifically about that change, maybe about a larger task of defining the semantics of catalog application. We also don't do the discussions often enough or widely enough. I know that eric tries to do "office hours" to talk about the arms, but I have to admit that I don't know what kind of participation he has gotten on that. > 2. We should resist the urge to admit defeat on (mis)features already > implemented, and look for creative ways to fix their warts. > Yes, this is the way I prefer to work. Throwing things away and admitting defeat can be useful, but also a disruptive way to move forward. Incremental changes, while seemingly slow moving, provide a more stable bed for others to build on. Once again, the balancing act is in play. Some parts of puppet are built on sand, others are on bedrock, but the framing was done wrong. > 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. > > Absolutely. What can we do to do this better? > 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. > > Absolutely. I'm thinking about trying out a weekly hangout (maybe 1 hour) on-the-air to talk about current development topics. In addition my team and I need to find a way to get more information going out on this list about what we are working on. I have stopped sending my weekly update to this list because it was just a bit too much for me to keep on top of :( > Thanks for listening :) > Dustin > Thanks for sharing. > -- > 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. > -- Andrew Parker [email protected] Freenode: zaphod42 Twitter: @aparker42 Software Developer *Join us at PuppetConf 2013, August 22-23 in San Francisco - * http://bit.ly/pupconf13* **Register now and take advantage of the Final Countdown discount - save 15%!* -- 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.
