This is a prime example of the sort of stupid that people usually encounter when asking about updates. The kind of idiot that assumes just because something is offered free all responsibility goes away. Nobody asked for an accelerated schedule just an occasional update and some more transparency. When you have a ton of people depending on you you have a responsibility to them. They put their trust in you the least you can do is be open with them. Have you seen any other prominent project shirk responsibility like this. Btw, this is NOT directed towards any of the project developers just the last moron. On Tue, Sep 10, 2019 at 7:21 PM Lamar Owen <lowen at pari.edu> wrote: > On 9/10/19 7:10 AM, victor mason wrote: > > What's the hold up on both of these? Are we back to the old days? > ... > <rantmode> > Yep, sounds just like the old days..... where people who are receiving a > valuable product for no cost go ballistic because a product they are > paying nothing for is not out as quickly as they want......if you want > faster, pay RH for a subscription. Yes that is a bit harsh, but so was > the original post, bringing up the 'old days' in that manner. If > anything, I'm being less harsh than the OP. But, then again, my > experience is that paying customers are typically a whole lot less > demanding than those who get it for free. > </rantmode> > > For what it's worth, as far as I can tell there's no real holdup on 7.7 > since all the 7.7 packages are in CR, I've updated several critical C7 > machines to 7.7 myself over the past week or so; there is a period of > time to create new install media and such, and that can sometimes pose > some interesting issues. Full instructions on using CR have been > posted. I myself use the following procedure in general (as I've had > the current rpm and yum versions hiccup once or twice on new content, > and I've had kernel updates over the years silently fail during the > creation of the new initrd in particular with a large-enough updated > package set on occasion, so I've found doing it this way has been more > reliable for me in my use cases): > > yum clean all > yum --enablerepo=cr update rpm yum > yum --enablerepo=cr update kernel > yum --enablerepo=cr update > <reboot, and after a successful reboot with the new kernel> > package-cleanup --enablerepo=cr --oldkernel > > CentOS 8 will be here when it's ready, and I trust the devs to know when > that is (after all, I'm trusting them for my OS, why wouldn't I trust > their release judgment?). Would I like to know more about what's taking > so long? Sure, but I can't really do anything about it, and I'd rather > the team spend their time working on the problems rather than wasting > valuable time merely talking to me about them. YMMV, IMHO, etc. > Karanbir, et al, thanks a bunch for your often thankless work, and > please don't rush the release just because I'd like to get it a few days > sooner; I'm patient. > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > https://lists.centos.org/mailman/listinfo/centos-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20190910/edb3444a/attachment-0008.html>