On Mon, Oct 22, 2012 at 7:51 PM, Todd Zullinger <tmz(a)pobox.com> wrote:
Ken Dreyer wrote:
>
> On Fri, Oct 19, 2012 at 5:35 PM, Matthew Miller <mattdm(a)fedoraproject.org>
> 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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel