> On 9 Apr 2016, at 11:34, Alex Harvey <alexharv...@gmail.com> wrote:
> 
> +1
> 
> The deprecation log is a great idea if we resign to the fact that Puppet Labs 
> (um, Puppet...) is never going to stop breaking things in its addiction to 
> change.  Ansible & Salt - at least so far - are not inflicting this 
> particular kind of pain on their users, and Puppet should charge ahead doing 
> things the way it has always done at its own peril.  (I get it that Ansible & 
> Salt get to learn from the early mistakes of Puppet, and that's the burden of 
> being the trail blazer, but people won't choose Puppet just because they're 
> nice people.)
> 
> At a recent debate I attended in Sydney (Puppet vs Chef vs Ansible vs Salt) I 
> noted that even one of Puppet's most loyal defenders was bemoaning the switch 
> to Clojure, as if Puppet wasn't difficult enough already without switching to 
> a functional programming language in parts of the code base.

Not really sure I follow most of this rant. 

In what relation does the switch to clojure even matter? There is no user 
visible clojure code, you don't need to know it to extend puppet etc. It's 
literally internals you never need to poke at

Though from what I can tell puppet4 adoption is indeed pretty bad - unless 
you're counting the many many paying customers who afaik have been on 4 for 
quite some time. And that's quite the very large amount of people now. 


> 
> Of the large sites I'm aware of I'm not aware of any in my city where there 
> are plans to upgrade to Puppet 4 yet.  Sadly, I know of far too many where 
> there are plans to migrate to Ansible or Salt, or even Chef (Chef's never 
> been big in Sydney).  Meanwhile Puppet's saying Puppet 3 is EOL this year.  
> Well I think if Puppet 5 is planned for any time sooner than 5 or 6 years 
> away from now, Puppet must have some kind of death wish.
> 
> Not that anyone will listen to me, but are so many things that could be 
> improved without planning breaking changes and feature deprecations.
> 
> What can be improved?  Well many of the supported Puppet modules.  I recall 
> seeing in a recent OpenStack report, the Firewall module cited as one of 
> Puppet's leading edges.  What wasn't mentioned is all the bugs in it.  How 
> about a major version bump on that one that fixes all the bugs and design 
> issues?
> 
> Gosh, I can only imagine if Puppet would turn its attention away from 
> breaking things in Puppet 5, to filling in all the gaps in the Puppet Forge, 
> Puppet's usability could improve dramatically.
> 
> Beaker version 3 would be nice too.  It needs to be significantly rewritten, 
> documented far better than it is.
> 
> 
> 
>> On Monday, March 21, 2016 at 7:35:09 AM UTC+11, Thomas Gelf wrote:
>> Hi  Rob, 
>> 
>> nice proposal, would definitively help people to deal with the stated 
>> problem. Another approach could be to break and deprecate less things. 
>> 
>> Sure, I'm just kidding ;-) I love moving things forward. But you know, 
>> there's a grain of truth in every joke. We should not forget about the 
>> fact that by the end of the day we are talking about a tool designed to 
>> manage configuration. 
>> 
>> For many people right now the configuration manager is the fastest 
>> moving target in their tool stack. Your proposal is telling me that we 
>> have a cfgmgmt tool struggling with the amount of deprecations it 
>> produces. Sad story. We work for the tool, not the other way round. 
>> 
>> Cheers, 
>> Thomas 
>> 
>> Am 18.03.2016 um 19:12 schrieb Rob Nelson: 
>> > Happy Friday, everyone! This morning I had some semi-intelligible 
>> > thoughts about feature deprecation in Puppet, specifically because I got 
>> > bit with an upgrade issue last night. We do user stories a lot at work, 
>> > so I'm going to frame it that way. I was curious what other opinions 
>> > people have on this problem and how it can best be addressed. Thanks!
> 
> -- 
> 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/2c58aaad-d76b-4bb1-b9d1-7457a119723b%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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/0A6A8FAC-1571-43C3-8B32-5847891A6585%40devco.net.
For more options, visit https://groups.google.com/d/optout.

Reply via email to