On Mon, Oct 22, 2012 at 7:51 PM, Todd Zullinger <tmz@xxxxxxxxx> wrote: > Ken Dreyer wrote: >> >> On Fri, Oct 19, 2012 at 5:35 PM, Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> >> wrote: >>> >>> I'm not opposed to putting puppet 3 in, but it'd really be helpful if it >>> went in as "puppet3" or something, and left the stable version as is, >>> happily getting security-only updates. >> >> >> My biggest concern is that 2.6 will not get security updates for the >> lifetime of EPEL 5 and 6. To me it seems better to bite the bullet now, get >> version 3 into updates-testing, set the karma requirement very high just as >> the maintainers did for the 0.25 -> 2.6 transition. > > > I'm sure that 2.6 won't last for the life of EL5, let alone EL6. At the > same time, I didn't push to get 2.7 in EPEL because it isn't a completely > compatible update. And 3.0 was coming so I figured we could wait to see > what things looked like when it did. The alternative would have been more > updates and more potential to break things and annoy the users who were > perfectly happy with how 2.6 was working. (Those that needed the newest > shiny or were supporting Fedora 17 could get newer bits from > yum.puppetlabs.com.) 2.6.x will be maintained (security) roughly until end of Q1 next year. That's the only real commitment we can make. It's not that we'd completely leave everybody in the dark after that, but some fixes/issues just don't port well to older versions. So this is well short of EPEL5/6 lifetimes. > > >> This is the main problem I see with parallel-installable packages, >> particularly in EPEL - it seems to give users an assumption that the old >> packages are fine. I too have always thought this. > > > Yeah, that's always bugged me too. If you're not paying close attention, > you can easily assume that since yum update returns nothing that you are > good to go. In that case, I'd much prefer that an update comes along and > gets your attention, even if it breaks things. Obviously, neither option is > all that great. > > As a user, I think compatibility is the biggest downside to puppet at this > point. I love the tool, but having to always run the master on the latest > version bugs me. At the least, I think a version N client should work fine > with an N-1 master. Back in the pre-1.0 days it was acceptable to not have > this, but as the versions have been increased to show product maturity, I > think it's hard to justify not maintaining more compatibility. This is an ongoing discussion internally on compatibility. Thoughts and opinions and real-world use cases from system admins are MORE than welcome about this topic on our puppet-users list. > > I'm happy to see options here and get a feel for what the least painful way > forward is for everyone. > > I'm not terribly fond of a puppet3 package myself. It would be confusing to > have it parallel installable and use different paths than the upstream > defaults, as documenation would either be wrong or require a lot of > conditional statements regarding where and how you installed puppet. That > and it's more work to maintain, regardless of who's maintaining it. > > Thanks to Michael for bringing this topic up for discussion (and for being > an all around good guy as well). cheers. > > -- > Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Abandon the search for Truth; settle for a good fantasy. > > > -- > devel mailing list > devel@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
